Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: MDM still helps with device compliance and OS-level control, but it cannot see package installs, IDE extensions, browser plugins, or AI tooling on developer machines, according to Aikido. That gap leaves modern developer endpoints exposed to supply chain and credential theft paths that traditional device management was never built to govern.
NHIMG editorial — based on content published by Aikido: What MDM can't protect on developer machines (and what to do about it)
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Disable install-time code execution by default Apply ignore-scripts or equivalent controls on local and build environments so postinstall hooks cannot execute automatically.
- 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.
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.
👉 Read Aikido's analysis of what MDM cannot protect on developer machines →
Developer endpoints and MDM blind spots: are your controls keeping up?
Explore further
02/08/2026 12:47 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: MDM misses the developer attack surface that now matters most
