MDM misses the developer attack surface that now matters most

At a glance

What this is: This is an analysis of where MDM stops protecting developer machines and why the modern developer attack surface now extends into package registries, browser extensions, IDE plugins, and AI tooling.

Why it matters: It matters because identity, secrets, and source-code access increasingly sit on developer endpoints that MDM and even EDR can miss, forcing IAM and security teams to govern the software actions that occur outside managed install paths.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Aikido's analysis of what MDM cannot protect on developer machines

Context

MDM was designed to control the managed device, not the full developer workflow. That distinction matters because modern developer risk now sits in user-space tools, signed-in browser sessions, package managers, and AI-assisted workflows that operate outside OS-level deployment channels. For IAM and NHI teams, the real issue is not whether the laptop is enrolled, but whether credentials, tokens, and code-moving tools are visible at the point they are actually used.

The article’s central argument is that developer machines have become a separate security class with a supply chain-shaped attack surface. That is an identity problem as much as an endpoint problem because the compromise path often ends in stolen OAuth tokens, API keys, session cookies, or compromised non-human identities. For practitioners, this is a familiar blind spot: the device is managed, but the identities and secrets moving through it are not.

NHIMG’s own NHI lifecycle guidance is relevant here because the controls that matter most are visibility, rotation, and offboarding. When developer tools can install packages, extensions, or MCP servers without central oversight, lifecycle control has to extend beyond the secrets vault and into the places where identities are consumed.

Key questions

Q: What breaks when MDM is the main control for developer machines?

A: MDM breaks down when the risky activity happens in user space rather than through sanctioned OS deployment paths. Package installs, IDE extensions, browser plugins, and AI tools can all introduce code or permissions without a visible MDM event. That leaves credentials, source code, and cloud sessions exposed even though the device itself appears managed.

Q: Why do developer endpoints create such high identity risk?

A: Developer endpoints often hold browser sessions, API tokens, cloud keys, and wallet material in one place. Those assets behave like identities because they can authenticate actions without a human present, so compromise can lead to account takeover, pipeline access, or financial theft. The governance gap is treating them as local files instead of governed credentials.

Q: What do security teams get wrong about package and extension management?

A: They often treat packages and extensions as software inventory issues instead of execution and access issues. A malicious package can run install-time code, and a browser or IDE extension can observe authenticated sessions or source code. The control failure is assuming that approved installation means approved trust.

Q: How should organisations govern developer tools that install packages or use AI agents?

A: They should govern them as part of access management, not only as endpoint software. That means approving sources, limiting permissions, blocking risky install behaviour, and revoking access when the tool, extension, or token is no longer required. If the tool can act on data or credentials, it belongs in the identity control model.

Technical breakdown

Why MDM stops at user-space developer activity

MDM operates where the operating system and sanctioned application deployment meet. It can enforce encryption, password policy, certificates, inventory, and remote wipe, but it does not govern actions inside a developer shell, package manager, browser session, or IDE marketplace. That is why npm installs, extension updates, and AI tool actions can happen without any MDM-visible event. The key architectural gap is that the install path is controlled by the user, not by the device manager, so the security control plane never sees the software before it executes.

Practical implication: Treat MDM as a compliance layer, not a control for developer software provenance.

How package registries and postinstall hooks bypass endpoint controls

Package managers fetch code directly from registries and can execute lifecycle hooks at install time. A malicious package can therefore run before traditional detection has a meaningful chance to inspect behaviour, and credentials stored in the developer environment may already be exposed. AI-assisted dependency selection adds a slopsquatting risk, where a hallucinated package name is registered by an attacker before the developer installs it. This is not just supply chain risk in the abstract, it is executable code arriving through a channel that endpoint management does not broker.

Practical implication: Block or delay new packages and disable install scripts where the risk of arbitrary code execution is unacceptable.

Why extensions, AI tools, and MCP servers create a new identity exposure layer

Browser extensions and IDE plugins sit close to authenticated sessions, source code, and internal portals, while AI coding tools and MCP servers can act on behalf of the developer with access to external services. That creates a governance problem around delegated trust: the human user may approve access once, but the tool can continue operating with broad permissions. If the extension, token, or MCP server is compromised, the real loss is not just malware on the endpoint, but credential reuse and identity misuse across cloud and code systems.

Practical implication: Inventory extensions and AI-connected tools as identity-bearing assets, not just software add-ons.

Threat narrative

Attacker objective: The attacker wants to turn a developer endpoint into a trusted credential-harvesting point that unlocks source code, package publishing, and internal system access.

1. Entry occurred when attackers reached developer machines through malicious packages, compromised extensions, or AI-connected tooling that bypassed MDM visibility.
2. Credential access followed when postinstall hooks, browser session access, or extension permissions exposed OAuth tokens, API keys, and other secrets from the developer environment.
3. Impact came when those stolen identities were reused to publish malicious packages, access internal repositories, or move into connected cloud and source-code systems.

NHI Mgmt Group analysis

MDM blind spots have become identity blind spots. The practical failure here is not only endpoint coverage, but the absence of governance over identities moving through developer tools. When a package install or extension update can expose tokens before IT sees it, device management no longer maps to identity control. The practitioner conclusion is that endpoint policy and identity policy now need to be designed together.

Developer tooling now behaves like an identity-bearing supply chain. Browser extensions, IDE plugins, package managers, and AI coding tools can all carry privileged access to code and sessions. That creates a governance layer where NHI controls such as secret visibility, rotation, and offboarding must extend beyond vaults into development workflows. The practitioner conclusion is that unmanaged tooling should be treated as an access pathway, not a convenience layer.

Shadow AI is also shadow identity expansion. AI tools that install packages or interact with MCP servers create a new form of delegated access that existing IAM and MDM processes do not fully inventory. That is a specific version of identity sprawl, and it is more dangerous because the activity looks like normal developer work. The practitioner conclusion is that AI-connected development tools need the same scrutiny as any other non-human identity.

Package provenance is now a control boundary, not a hygiene issue. Minimum package age, script blocking, and extension auditing are all responses to the same governance problem: code arrives faster than most control planes can inspect it. This shifts the security conversation from detection after execution to trust before execution. The practitioner conclusion is that provenance checks should be part of NHI and software supply chain governance, not a separate developer preference.

Dedicated developer endpoint controls fill a real governance gap, but they do not replace lifecycle discipline. The article’s core point is that blind spots exist because MDM was never built to manage user-installed code paths. The broader lesson for identity programmes is that visibility, revocation, and approval processes must follow the identity wherever it is consumed. The practitioner conclusion is that lifecycle governance has to reach endpoints, not stop at the vault.

What this signals

Developer machine security is increasingly an identity governance problem because the most damaging failures are happening in trusted developer workflows rather than on the OS itself. Teams that still scope endpoint protection around enrolled devices will miss the places where tokens, sessions, and non-human identities are actually consumed.

developer trust boundary drift: the point at which a developer approves a package, extension, or AI connector has become a security control boundary in its own right. That means security programmes need to align package provenance, secret lifecycle, and tool approval with the same discipline they apply to privileged access. The most useful next step is to connect endpoint policy with the Top 10 NHI Issues and the NIST SP 800-53 Rev 5 Security and Privacy Controls families that govern access, audit, and configuration.

If AI coding tools and MCP-connected workflows continue to spread, the real operational question will be whether organisations can still tell the difference between approved developer behaviour and delegated machine action. That is where NHI governance, software supply chain controls, and access review processes now intersect.

For practitioners

• Inventory developer-installed software paths Map every channel that can introduce code or permissions onto developer machines, including npm, pip, browser extensions, IDE plugins, and AI tools. Use that inventory to define which sources are allowed to run without review and which must be blocked or delayed.
• Disable install-time code execution by default Apply ignore-scripts or equivalent controls on local and build environments so postinstall hooks cannot execute automatically. Pair that with allow-listing for packages that are explicitly required and reviewed.
• Treat extensions and AI connectors as identity assets Require approval for browser extensions, IDE plugins, and MCP servers that can access sessions, code, or cloud services. Revoke access when the tool is no longer needed and review permissions whenever the extension updates.
• Add package provenance controls at the point of install Use minimum package age policies to slow down same-day typosquatting and rapid malware drops, and make installs fail closed when the requested version is too new. That creates a pause where security review can happen before code reaches the machine.
• Extend NHI governance to developer workflows Track tokens, service credentials, and session-based access that appear on developer endpoints, then align them to lifecycle controls from the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs. This closes the gap between managed devices and unmanaged identity use.

Key takeaways

• MDM still matters, but it does not control the software paths where developer compromise increasingly starts.
• The meaningful risk is identity exposure through packages, extensions, sessions, and AI tooling, not just malware on the endpoint.
• Security teams need to extend lifecycle and provenance controls into developer workflows or accept invisible credential and source-code loss.

Key terms

• Trust Boundary Drift: Trust boundary drift is the gradual shift of where users and systems decide something is legitimate. In fraud and identity environments, that boundary can move from checkout to search, ads, or account recovery, which creates new opportunities for impersonation and abuse.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.

What's in the full article

Aikido's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how MDM visibility ends at the OS boundary while package managers, extensions, and AI tools continue to execute outside it.
• The exact controls Aikido recommends for blocking postinstall scripts, limiting package age, and auditing browser and IDE extensions across developer fleets.
• How Aikido Device Protection is deployed through existing MDM while covering the developer-specific attack surface in more detail than this analysis.
• The article’s discussion of Aikido Intel and Safe Chain for teams that want a vendor-specific implementation path.

👉 Aikido's full post covers developer endpoint blind spots, control gaps, and the proposed remediation approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical enterprise terms. It helps security practitioners connect lifecycle control to the broader identity programme they run.