Developer devices are now the control plane for code and risk

At a glance

What this is: This is an analysis of how coding work is moving off the traditional desktop editor and into Slack, AI agents, and MCP-linked workflows, expanding the developer attack surface.

Why it matters: It matters because IAM, PAM, and endpoint teams now have to govern identities, tokens, and approvals that may be exercised from interfaces security tooling was never built to observe.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Aikido's analysis of how developer devices became the control plane for code and risk

Context

Developer coding workflows are no longer anchored to a single editor, and that matters for identity and access governance because the approval point, the execution point, and the observability point are starting to diverge. In practice, code changes can now move through Slack, AI assistants, browser plugins, MCP servers, and background agents before a security team has a clear record of what identity exercised which privilege.

The security gap is not simply that more tools exist. It is that the developer device has become the convergence point for secrets, source access, package installs, and delegated approvals, while conventional controls still assume a human in an editor with a visible change trail. For identity teams, that creates a governance problem around ephemeral approvals, delegated actions, and privileged tooling that may never pass through the normal review path.

Key questions

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. The key is to preserve who approved what, from which device, and with which credentials, so delegated actions remain attributable and auditable across the full workflow.

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. Once a package, extension, or agent reaches that machine, it can inherit the developer’s trust and move laterally across the software delivery chain without needing to break a traditional perimeter.

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. Security teams may still detect a malicious process, but they lose context about whether the action came from a sanctioned Slack approval, an agentic task, or a harmful install, which makes containment and investigation much slower.

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.

Technical breakdown

Why fragmented coding interfaces weaken endpoint visibility

When coding moves across chat apps, browser extensions, and agent back ends, the endpoint becomes the only place where those workflows reliably meet. EDR can see processes and files, but it often cannot understand the intent behind a Slack approval, a package install from a marketplace, or an MCP call that triggers downstream actions. That gap matters because the risky event is not always malware execution. It can be the legitimate-looking handoff that lets a malicious dependency or agent perform privileged work on behalf of a developer.

Practical implication: security teams should map every non-editor coding interface to the endpoint and identity controls that can actually observe it.

How AI agents and MCP servers change the trust model for developers

AI coding agents and MCP servers extend the developer workflow by delegating tasks to software that can fetch data, invoke tools, and complete actions outside direct human supervision. MCP is especially important because it standardises how agents connect to tools and data sources, which increases interoperability but also broadens the blast radius of a compromised connector. If the agent, the connector, or the package behind it is malicious, the workflow can appear normal while silently exfiltrating data, inserting code, or reusing credentials.

Practical implication: treat agent connectors and MCP endpoints as governed access paths, not as harmless productivity layers.

Why package and extension supply chains remain the easiest route in

Developer environments are crowded with npm packages, IDE extensions, browser plugins, and automation helpers, and each one can become a delivery path. Attackers do not need a code vulnerability if they can get a maintainer account, publish a malicious update, or compromise an extension marketplace. Once the install runs on a trusted device, the package inherits the developer’s reach into source code, cloud credentials, and production tooling. That is why the real control boundary is shifting from the repository to the device itself.

Practical implication: enforce install-time inspection and device-level allowlisting for every developer-facing package and extension.

Threat narrative

Attacker objective: The attacker wants to turn a trusted developer workflow into a silent path to source code, credentials, and downstream production access.

1. Entry occurs when a developer accepts a seemingly routine approval in Slack, installs a package, or trusts an extension or MCP connector that has already entered the workflow.
2. Credential access follows when the malicious component reaches cloud credentials, SSH keys, publish tokens, or source control access stored or accessible on the device.
3. Impact occurs when the attacker uses that trust to alter code, backdoor the supply chain, or reach production systems before traditional monitoring understands what happened.

NHI Mgmt Group analysis

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.

Interface fragmentation creates a visibility gap that endpoint security alone cannot close. EDR can detect suspicious execution, but it is not designed to explain whether a Slack-approved diff, a bot-triggered install, or an MCP call was an authorised development action. That is a classic policy-to-observation mismatch. Interface trust gap: when the approval surface and the execution surface split apart, security teams lose the evidence needed to prove that access remained within policy. Practitioners should build telemetry that ties identity, approval, and install events together.

Supply chain control is now inseparable from developer identity governance. Package trust, extension trust, and delegated automation trust are all expressed through the same device. That means NHI governance matters here too, because tokens, publish keys, and automation credentials are often the bridge between code creation and code deployment. OWASP-NHI and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the need to manage authenticator lifecycle, auditability, and least privilege across that bridge. Practitioners should review developer-access pathways as a unified identity problem, not as separate tooling decisions.

Malicious install paths exploit the assumption that developer productivity tools are neutral. Once a tool becomes part of the workflow, it inherits trust by convenience rather than by assurance. That is why supply chain attackers focus on extensions, plugins, and helpers rather than on the editor itself. The governance lesson is straightforward: anything that can execute code, touch credentials, or broker approvals must be controlled like privileged infrastructure. Practitioners should align install policy, code provenance checks, and credential scope.

Identity teams should expect AI-assisted development to increase standing access pressure. When code is written through chat, the temptation is to widen permissions so the workflow stays frictionless. That is exactly the wrong trade-off. The right response is to reduce standing privilege, narrow token scope, and require stronger attestation around high-risk actions. Practitioners should re-evaluate where their approval boundaries sit before agent-assisted coding becomes the default operating model.

What this signals

Interface trust gap: as development shifts into chat and agent workflows, security programmes need telemetry that connects identity, approval, and execution across more than one interface. That means endpoint, IAM, and supply chain teams have to work from the same event model, not three separate ones, if they want to prove that privileged action stayed inside policy.

For identity teams, the practical signal is not just more tooling. It is whether standing privilege is shrinking fast enough to offset the growth in delegated development paths. If approvals can happen in Slack, code can be installed by a bot, and tokens can reach production from the same device, then access governance must follow the workflow rather than the other way around.

The most resilient programmes will treat developer devices as governed trust anchors, pairing device posture, package provenance, and identity-aware approvals. That is where NHI governance and human identity governance finally meet in practice, because the same workstation may now be used by a person, an agent, and an integration in one continuous chain.

For practitioners

• 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. This is the minimum control needed when coding work leaves the editor and moves into chat-driven workflows.
• 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. The developer device is no longer a generic endpoint.
• 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. If a malicious package or extension lands, blast radius depends on how much standing access the device carries.
• Inspect MCP and agent connectors as governed integrations Review every MCP server, agent plugin, and workflow connector as if it were an external access path into code and data. Require inventory, owner assignment, and removal of unused connectors before they become persistent trust anchors.

Key takeaways

• Developer workflows are fragmenting into chat, agents, and connectors, which means the device has become the enforcement point for identity and supply chain risk.
• Hardcoded secrets, delayed remediation, and low adherence to secrets hygiene show that the exposure window remains wide even before a malicious package lands.
• Teams should connect approval, install, and credential telemetry now, because device-level visibility is the only way to govern AI-assisted development at scale.

Key terms

• Developer Device: The developer device is the workstation or laptop where code is written, reviewed, tested, and increasingly approved through chat or automated assistants. It is also where credentials, tokens, extensions, and package installs converge, making it a critical enforcement point for identity and supply chain governance.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Visibility Fragmentation: Visibility fragmentation is the condition where security telemetry exists, but only inside separate provider consoles or tools. In multi-cloud estates, it prevents teams from correlating one provider’s event with another’s and leaves lateral movement or drift hidden in plain sight.
• Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.

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

👉 The full Aikido post covers the developer-device attack chain, interface fragmentation, and device-level protection approach

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader access and lifecycle decisions that modern security programmes depend on.