Notifications
Clear all
Topic starter
02/08/2026 11:28 am
TL;DR: Developers are increasingly writing code through Slack, AI agents, MCP servers, and other dispersed interfaces, while attackers are abusing developer endpoints with stolen credentials, malicious packages, and compromised extensions, according to Aikido. The security problem is no longer just code review latency; it is whether endpoint, identity, and supply chain controls can still see and constrain work that now happens outside the editor.
NHIMG editorial — based on content published by Aikido: Code Is Written Everywhere and the Device Is the Only Constant
Questions worth separating out
Q: How should security teams govern developer workflows that move through Slack and AI agents?
A: Security teams should treat non-editor workflows as privileged development channels and bind them to the same identity, approval, and logging controls used for source control.
Q: Why do developer devices create such a large supply chain risk?
A: Developer devices hold the credentials and access paths that connect source code, package registries, cloud environments, and production tools.
Q: What breaks when EDR cannot see coding activity outside the editor?
A: What breaks is the control link between approved work and observable execution.
Practitioner guidance
- Tie Slack, agents, and IDE activity to a single identity trail Correlate approvals, package installs, and source-control actions so security teams can see which identity approved which change and which device executed it.
- Treat developer endpoints as privileged supply chain assets Apply stricter device posture checks, package inspection, and extension allowlisting on machines that can publish code, access cloud credentials, or merge pull requests.
- Scope tokens and publish keys to the narrowest viable task Reduce the lifetime and reach of cloud credentials, SSH keys, npm tokens, and automation secrets used on developer machines.
What's in the full article
Aikido's full article covers the operational detail this post intentionally leaves for the source:
- Device-level protection logic for npm packages, IDE extensions, browser plugins, and AI tools
- Threat-feed matching and install-time blocking workflow for suspicious developer-side software
- Operational examples showing how malicious installs reach developer machines before EDR has useful context
- The product-specific approach to centralising visibility across developer endpoints
👉 Read Aikido's analysis of how developer devices became the control plane for code and risk →
Developer devices and AI coding flows: are your controls keeping up?
Explore further
02/08/2026 12:44 pm
Developer devices are becoming the control plane for non-human and human-assisted coding. The shift from a single IDE to Slack, AI agents, and MCP-linked workflows means access decisions are now happening across more runtime surfaces than most IAM programmes track. That creates a governance gap between who is authorised and which interface actually executed the action. Practitioners should treat the device as the enforcement point for identity, privilege, and supply chain risk.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: Developer devices are now the control plane for code and risk
