Security teams should scan the developer tooling layer directly, because traditional EDR does not understand AI agents, MCP server configurations, IDE extensions, or project-scoped package ecosystems. The practical goal is a repeatable inventory of tools, privileges, and connections, so teams can identify hidden trust paths, exposed credentials, and risky endpoints before a compromise spreads across the fleet.
Why This Matters for Security Teams
Developer laptops are no longer just endpoints with source code. They now host autonomous AI agents, MCP servers, IDE extensions, and local token stores that can create, chain, and reuse trust in ways traditional endpoint inventories miss. That makes the developer tooling layer part of the non-human identity attack surface, not just a productivity layer. Guidance from the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both point toward runtime context, provenance, and governance, but inventory is the prerequisite.
Without a current inventory, teams cannot tell which agents can call which tools, which extensions can read project files, or where credentials are being cached on disk. NHIMG research on the AI agents attack surface shows why this matters: 80% of organisations report agents have already acted beyond intended scope, and 23% have revealed access credentials. In practice, many security teams discover the risky extension, MCP connector, or local secret only after the agent has already used it.
How It Works in Practice
A useful inventory starts at the developer tooling layer, not at the EDR console. Security teams should enumerate the software that can execute agent logic or expose tool access: IDE extensions, local agent runtimes, MCP servers, model connectors, package managers, browser plugins, and project-scoped configuration files. The goal is to map three things together: what is installed, what it can access, and what identity or secret it uses.
In practice, that means combining host telemetry, software inventory, and file-system inspection with policy checks for known agent frameworks and MCP endpoints. A mature inventory should capture extension identifiers, versioning, command permissions, network destinations, workspace bindings, and any embedded secrets or tokens. When possible, correlate the developer machine to workload identity or approved service accounts so teams can distinguish legitimate automation from shadow tooling. The Analysis of Claude Code Security and the OWASP NHI Top 10 both reinforce the same operational point: autonomous tooling should be treated as an identity-bearing workload, not a harmless editor add-on.
- Inventory installed extensions and agent runtimes by hash, version, and publisher.
- Extract MCP server definitions, local endpoints, and transport settings.
- Flag hardcoded tokens, cached API keys, and credential helper usage.
- Record tool scopes, workspace reach, and external network destinations.
- Reconcile each tool to an owner, a business purpose, and an approval path.
Security teams should then classify findings by trust path: benign productivity tool, privileged automation, or unapproved autonomous access path. These controls tend to break down on unmanaged developer workstations and ephemeral sandbox environments because the tooling changes faster than central inventory and approval systems can keep up.
Common Variations and Edge Cases
Tighter inventory often increases developer friction, requiring organisations to balance visibility against speed and local autonomy. That tradeoff is especially sharp in AI-assisted development, where tooling changes weekly and some extensions are installed ad hoc for a single project. Current guidance suggests treating that churn as a reason for more automation, not less, but there is no universal standard for how deep developer-tool inventory must go.
Edge cases matter. Offline workstations may hide agent activity until the device reconnects. Containerised dev environments can move the real risk into image layers and mounted volumes. MCP servers may run locally but call remote services with long-lived tokens, making the machine itself only one part of the trust chain. In those cases, inventory should extend to repository manifests, dotfiles, secret stores, and container definitions, then be refreshed on every significant workspace change.
NHIMG’s State of Secrets in AppSec report is a useful reminder that hidden credential sprawl is common, and remediation is slow. That is why inventory must be paired with secret discovery and revocation workflows, not treated as a static asset register. For implementation detail, CSA MAESTRO agentic AI threat modeling framework is a strong companion reference for mapping these trust paths. The model fails when teams assume the IDE boundary is the security boundary, because the agent, its tools, and its tokens often live outside that boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Inventory reveals unmanaged non-human identities on developer machines. |
| OWASP Agentic AI Top 10 | A2 | Agentic tools expand the attack surface through autonomous tool use. |
| CSA MAESTRO | T1 | MAESTRO models the trust paths between agents, tools, and runtime access. |
| NIST AI RMF | GOVERN | AI governance requires accountability for deployed agentic tooling. |
| NIST CSF 2.0 | ID.AM | Asset management is the base control for discovering developer tooling. |
Enumerate every agent, token, and tool identity attached to developer endpoints.
Related resources from NHI Mgmt Group
- How should security teams govern local AI agents that run on developer endpoints?
- How should security teams monitor AI agents and MCP servers in production?
- How should security teams implement AI security testing when agents, tools, and MCP servers are changing quickly?
- How should security teams run AI agents in hermetic environments without breaking developer velocity?
