Agent discovery is the first control for governing AI agents

At a glance

What this is: This is an engineering post about discovering hidden AI agents across a fleet, with the central finding that self-reporting is unreliable and host-based artifact scanning is needed instead.

Why it matters: It matters because IAM and security teams cannot govern agentic access, MCP usage, or tool permissions until they can inventory the agents, runtimes, and servers actually present.

Context

AI agent discovery is the control problem that appears before authorisation, runtime policy, or incident response can work. If the programme cannot identify where agentic frameworks, MCP servers, and local model runtimes exist, then governance is built on an incomplete inventory rather than a defensible control baseline.

The article treats discovery as fleet inspection rather than self-attestation. That matters for agentic AI identity because agents are often introduced through developer installs and local tooling, which leaves security teams dependent on host artifacts instead of procurement records or manual declarations.

Key questions

Q: What breaks when AI agents are discovered too late or not at all?

A: When agents are not discovered early, teams cannot assign ownership, set scope, or prove what systems the agent can reach. That leaves shadow AI outside IAM, IGA, and PAM oversight. The result is unmanaged identity growth, weak auditability, and limited ability to contain misuse or offboard the agent cleanly.

Q: Why do hidden AI tools create a governance risk beyond ordinary software sprawl?

A: Hidden AI tools can process sensitive data, call external services, and change outputs or decisions without leaving a clear ownership trail. That makes them different from ordinary application sprawl, because the risk includes data exposure, untracked delegation, and incomplete auditability. The control problem is visibility first, not policy wording.

Q: How do you know if AI discovery is actually working?

A: AI discovery is working when the organisation can produce one authoritative inventory, classify tools consistently, and explain which data and permissions each tool can reach. If the team still has to switch between dashboards or cannot map runtime usage back to policy, discovery is incomplete even if coverage looks broad.

Q: What should organisations do when discovery finds an unapproved MCP server or local model runtime?

A: Treat it as an unmanaged authority path until an owner, environment scope, and business purpose are confirmed. If those cannot be established quickly, isolate the component and remove its access to tools or data before it becomes a standing control exception.

Technical breakdown

Why self-reporting fails for AI agent inventory

Agentic software does not behave like a managed SaaS service that can accurately announce itself to a control plane. In practice, teams discover it through what the workload leaves behind: framework packages, local model runtimes, MCP server manifests, and tool configuration files. That is an EDR-style model applied to agent discovery, where the signal comes from host-level evidence rather than application claims. The technical issue is not just visibility. It is that agentic components are composable, developer-installed, and easy to shadow across endpoints and build environments.

Practical implication: build discovery around host artifacts, not self-reported inventories.

Why MCP servers and local models need separate inventory logic

MCP servers, local model runtimes, and framework packages are related but not interchangeable. An organisation can have a model runtime with no governed tool access, an MCP server with no agentic framework, or an agentic framework that invokes local tools without a central service record. Discovery therefore has to recognise multiple layers of the stack, not just one software label. This is especially important because MCP is a connection layer between agents and tools, while local runtimes often sit outside traditional SaaS oversight.

Practical implication: inventory the agent, its tool bridge, and its runtime as separate governance objects.

Why tenant-scoped scanning is a governance boundary, not a technical detail

The post makes clear that scanning defaults are tenant-scoped and disabled by default. That is not merely a product preference. It is the line between governing your own fleet and probing systems you do not own. Discovery tooling for agentic environments therefore needs both technical scope control and explicit operational ownership, because an inventory mechanism can itself become an overreach if its boundary is unclear. In governance terms, discovery without scope control is just another access problem.

Practical implication: define tenant boundaries and approval paths before enabling fleet-wide discovery.

Threat narrative

Attacker objective: The objective is not a classic intrusion outcome but hidden capability growth, where unmanaged agentic components gain operational presence before security governance can see them.

1. Entry occurs when agentic software arrives through npm packages, pip installs, or local runtime deployments instead of formal procurement and inventory processes.
2. Credential access or control exposure follows when agents bring MCP server manifests and tool configurations that create unmanaged paths to data and tools.
3. Impact is an incomplete security inventory, which leaves authorisation, monitoring, and policy enforcement operating against unknown agentic assets.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent discovery is now a governance prerequisite, not an optional hygiene task. If you cannot enumerate AI agents, you cannot decide who or what is authorised to act through them. The article’s core point is that agentic software often bypasses procurement and therefore bypasses the normal identity register, which means the first failure is governance blindness. Practitioners should treat discovery as the front door to agent control.

Shadow AI is an inventory failure before it is a security failure. Agents introduced through package managers and local runtimes create the same kind of blind spot that shadow IT created, but with a narrower margin for error because agents can call tools and mutate state. The implication is that identity programmes need an evidence-based discovery layer for agentic components, not a policy document that assumes vendors or developers will self-report.

Host-artifact scanning is the only defensible discovery model when software does not self-identify. Framework packages, MCP manifests, local model runtimes, and tool configs are the artifacts that matter because they prove runtime presence. That shifts the programme away from declarations and toward measurable fleet evidence, which is the only reliable basis for authorisation, review, and lifecycle governance.

Discovery and authorisation are collapsing into the same control plane for agentic systems. Once an agent can be installed locally and start using tools, the act of finding it and the act of governing it are inseparable. The practical conclusion is that security teams need a discovery pipeline that feeds directly into agent authorisation, offboarding, and runtime policy enforcement.

MCP visibility is becoming a core identity question, not just a protocol question. If agents are the actors and MCP is the bridge to tools, then untracked MCP servers are untracked authority paths. Practitioners should view MCP discovery as part of identity inventory, because unmanaged tool bridges expand the effective attack and governance surface even before any malicious action occurs.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agent discovery now sits on the critical path for agentic AI governance. A programme that cannot inventory framework packages, MCP servers, and local model runtimes is not ready for authorisation, review, or offboarding. The control model has to move from declarations to host evidence before policy can mean anything.

Shadow AI is mostly a visibility problem until it becomes a privilege problem. The moment an undiscovered agent can call tools, the inventory gap turns into an access gap. Security teams should expect discovery outputs to feed directly into agent authorisation and lifecycle controls, not into a standalone asset list.

Local installation paths are now part of the identity surface. Package managers and endpoint runtimes can introduce agentic components outside normal procurement and approval channels, which means the security team needs a discovery process that is as continuous as the deployment pipeline itself.

For practitioners

• Build host-based AI agent discovery Scan endpoints and workloads for framework packages, local model runtimes, MCP server manifests, and tool configuration files rather than waiting for self-reporting.
• Treat agent inventory as a governance register Record each discovered agentic framework, runtime, and MCP server as a governed identity asset with an owner, environment, and authorised purpose.
• Enforce tenant-scoped discovery boundaries Define which fleets may be scanned, approve those scopes explicitly, and prevent discovery tooling from extending beyond owned environments.
• Connect discovery to offboarding workflows Remove or quarantine agentic components that cannot be tied to an owner, approved environment, or current business need.

Key takeaways

• AI agent discovery is a prerequisite for governance because self-reporting is not reliable enough to support inventory, ownership, or authorisation.
• Host artifacts such as framework packages, MCP manifests, and local runtimes provide the evidence teams need to find hidden agentic components across a fleet.
• Discovery should feed directly into authorisation and offboarding, because unmanaged agents become standing authority paths the moment they can call tools.

Key terms

• Agent Discovery: Agent discovery is the process of finding every AI agent across cloud platforms, low-code tools, repositories, and deployment pipelines. It matters because governance cannot start until the organisation can see where the agent exists, who owns it, and what it can reach.
• Build Artifact Scanning: Inspection of compiled or packaged release outputs before they are deployed to production. This is different from repository scanning because the artifact is the exact content users receive. It is the right control for catching secrets that appear only after a build step transforms source into public code.
• 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.
• Tenant-Scoped Scanning: Tenant-scoped scanning is discovery limited to systems and environments owned by the organisation running the scan. It is a governance boundary as much as a technical one, because inventory tooling must not create unauthorized visibility or operational overreach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.