What breaks when organisations cannot see which AI skills and agent tools are running on developer endpoints?

Why This Matters for Security Teams

When developer endpoints run AI skills and agent tools that security cannot inventory, policy stops being enforceable and starts being aspirational. Agents may call hidden plugins, load unapproved connectors, or inherit instructions from compromised local files before any central control sees the request. That is especially dangerous in environments where code assistants and workflow automations are embedded directly into the developer workstation.

This is not just a visibility problem. It is an identity and trust problem for software that can act on behalf of a developer with tool access. NHI Management Group has highlighted how agentic systems create new exposure paths in the OWASP NHI Top 10, and the broader control model aligns with guidance in the NIST AI Risk Management Framework. In practice, hidden tools create a false sense of approval because the endpoint looks compliant while the agent is actually reaching beyond approved boundaries.

That risk is not theoretical. NHIMG research on the State of MCP Server Security 2025 found 53% of MCP servers expose credentials through hard-coded values in configuration files, and only 18% implement any form of access scoping for tool permissions. In practice, many security teams discover this only after an endpoint has already been used to launch unsafe automation or leak secrets, rather than through intentional asset discovery.

How It Works in Practice

Effective control starts with endpoint-level discovery of the agent runtime, the skills loaded into it, and the tool manifests it can invoke. Security teams need to know whether the endpoint is running a code assistant, a local MCP client, a browser-based agent, or a plugin that can chain actions across SaaS and internal systems. Without that inventory, they cannot validate whether the toolset matches approved use cases or whether the agent is pulling instructions from untrusted sources.

In practice, this means combining software inventory, endpoint detection, and workload identity so the organisation can distinguish the device, the user, and the autonomous workload. The emerging pattern is to evaluate each tool request at runtime rather than rely on a static allowlist. That aligns with the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, which both emphasise context-aware governance over broad trust in the host.

• Identify the agent, its skills, and its tool registrations at the endpoint before granting network or API reach.
• Bind tool execution to workload identity and short-lived credentials instead of long-lived developer secrets.
• Require policy evaluation at request time so a new skill cannot inherit old approval by default.
• Log which model, prompt source, and connector initiated the action so responders can reconstruct the decision path.

For implementation guidance, endpoint inventories should be correlated with agent telemetry and secrets discovery so security can detect when a local tool has expanded beyond its approved scope. NHIMG’s Analysis of Claude Code Security shows why developer-side AI controls are now part of core attack surface management, not just productivity tooling. These controls tend to break down when developers can sideload plugins or when offline tools cache credentials locally because central policy no longer sees the effective tool graph.

Common Variations and Edge Cases

Tighter endpoint visibility often increases friction for developers, so organisations have to balance operational speed against the need to constrain hidden capability. That tradeoff is especially sharp in research, platform engineering, and rapid prototyping teams where agents are frequently changing and local tools evolve faster than formal approvals.

There is no universal standard for how much agent-tool visibility is enough yet, but current guidance suggests treating unknown skills as untrusted until they are inventoried and bound to policy. The hardest edge case is the blended workstation, where a single developer endpoint runs sanctioned IDE extensions, experimental agent plugins, and personal automation scripts at the same time. In that situation, simply knowing the device is managed tells you little about which autonomous workflow is actually acting.

Security teams should also be careful not to equate visibility with safety. A visible tool can still be dangerous if it has excessive scope, and an invisible tool can still be contained if it cannot access secrets or privileged APIs. That is why current best practice is evolving toward layered controls: endpoint discovery, least privilege, runtime authorization, and rapid revocation. The risk pattern described in the OWASP Agentic Applications Top 10 becomes most acute when organisations allow local agents to chain tools without a clear approval boundary.

Related resources from NHI Mgmt Group

• What breaks when organisations can see AI tools on endpoints but cannot enforce policy at runtime?
• What breaks when organisations cannot see AI agents across devices and browsers?
• What breaks when organisations cannot see employee AI tool integrations?
• What breaks when organisations cannot distinguish human from AI agent activity?