Agent discovery is the continuous inventory of every AI agent operating in an enterprise environment, what each agent can reach, and who built it. It is the first pillar of Agent DOS, and the one that turns AI governance from a policy document into something you can operate.
The reason discovery comes first is unglamorous. You cannot apply runtime guardrails to an agent you do not know exists. You cannot audit its actions, propagate the right identity, or stop it in an incident. Most enterprise security programs already understand this for assets, identities, and SaaS applications. Agents are the newest item on the inventory, and they are the easiest to miss.
See how Trust3 AI implements agent discovery →
Why agent inventory is the hard part of agentic governance
When traditional software shipped, security saw it. A new app required a deployment, a network change, a credential, a vendor onboarding. There were natural choke points where security got a look.
Agents have almost none of those choke points. A data scientist can build a working agent in an afternoon inside Copilot Studio. An engineer can deploy one to Bedrock without leaving the AWS console. A developer using Cursor can wire an MCP server into a local workflow and reach internal systems with their own credentials. None of those paths necessarily touches procurement, identity governance, or change management.
The result is the now-familiar shadow agent problem. The security team knows about the agents that came through the AI platform team. They do not know about the agents that did not. The first time those agents surface is usually during an incident review or a regulatory question.
A clean discovery capability closes that gap before the incident, not after.
What discovery has to cover
A useful agent inventory is more than a list of names. For each agent, the discovery layer should capture:
- Identity. Which service principal, application registration, or token the agent operates under, and which human owner is accountable for it.
- Platform of origin. Bedrock, Databricks Mosaic, Copilot Studio, LangGraph, custom Python, or another framework. The platform shapes what controls are even available.
- Tool bindings. Every MCP server the agent connects to, every internal API it can call, every plugin or function it has been granted. Tool bindings are where the actual blast radius sits.
- Data reach. Every table, dataset, file store, or knowledge base the agent has been authorized to read or write. Reach often expands quietly as the agent's owner adds capabilities.
- A2A relationships. Which other agents this one calls, and which agents call it. Multi-agent topologies tend to grow without being mapped.
- Risk classification. Whether the agent operates over regulated data, executes transactions, communicates externally, or operates inside a high-impact business process.
- Lifecycle stage. Build, test, staged production, full production, or end-of-life. The same agent in different stages should be governed differently.
The output is an inventory record that a security architect can read and an auditor can accept.
How discovery works in practice
Effective agent discovery pulls signal from three places at once.
The first is the agent platforms themselves. Bedrock, Databricks, Copilot Studio, and similar environments expose APIs that list deployed agents and their configurations. A discovery layer that reads from these continuously is the floor of the capability.
The second is the development environment. Custom agents do not show up on platform APIs because they are not on a platform. They show up in code repositories, in CI pipelines, in container images. A discovery layer that introspects repos and build artifacts can flag a new agent before it reaches production.
The third is runtime traffic. An agent calling an MCP server or an internal API produces network and identity signals. A discovery layer that watches the egress side can detect an agent that none of the inventory sources saw, which is the failure case worth catching.
The combined signal is what turns a discovery feature into a usable inventory. Any one source on its own misses a significant share of agents.
What enterprises usually find in the first week
The first sweep of a real environment tends to surface a consistent pattern.
A handful of agents the security team already knew about, plus several they did not. Among the unknowns: a customer-service agent built in Copilot Studio by the support team, a coding agent in Cursor used by half of engineering, an analytics agent built on Databricks Mosaic by a data team, and one or two agents wired up by a single engineer for personal productivity that happen to reach company data.
None of these are usually malicious. Most are useful. The point of discovery is not to shut them down. The point is to let the security team see them, classify them, bring them into the same policy and observability layer as the sanctioned ones, and avoid finding out about them from an external party.
Where does your org actually stand?
The F500 benchmark scores your agent governance posture across discovery, observability, and security in 90 seconds. No signup required.
Get your score →Discovery across the agent lifecycle
Design. Discovery captures the intent record. Who is proposing the agent, for what purpose, against what data, with which tools.
Development. Discovery watches the repository and the build pipeline. New agent code, new MCP bindings, new tool definitions all show up as signals.
Pre-deployment testing. The discovered configuration is reconciled against the design intent. Drift between what was proposed and what was built is flagged here, not after launch.
Deployment. The agent enters the live inventory. Ownership, risk classification, and oversight assignment are confirmed before the agent receives production credentials.
Runtime. Discovery is continuous. New tool bindings, new MCP connections, new A2A peers added after launch are detected and reviewed. This is where silent scope expansion is caught.
Decommissioning. Discovery confirms the agent has actually been retired: credentials revoked, MCP connections closed, no live traffic from the service identity. Decommissioning that is documented but not enforced is one of the most common audit findings.
Where discovery aligns with standards
| Framework | Discovery's contribution |
|---|---|
| NIST AI RMF | Map function: catalog of AI systems, their context, and their dependencies. |
| ISO/IEC 42001 | AI system inventory requirement and ownership documentation. |
| EU AI Act | Article 11 technical documentation and Annex IV system descriptions for high-risk systems. |
| SOC 2 / ISO 27001 | Asset inventory and access governance controls extended into the agent layer. |
| ISO/IEC 42005 | Inputs to pre-deployment impact assessment. |
Frequently asked questions
No. DSPM products find sensitive data. Agent discovery finds the agents and pathways that reach data. Both belong in the stack, and they answer different questions.
Partially. CASB sees traffic to known SaaS platforms, which catches agents hosted on those platforms. It does not see custom agents, on-premise agents, or A2A relationships. Agent-aware discovery is a different layer.
By watching the development environment and the runtime traffic. The agent does not exist on a platform, but it leaves traces in repositories, MCP connection logs, and outbound calls.
A scripted automation runs a fixed set of steps. An agent receives a goal, plans, calls tools, and chooses among options at runtime. The dividing line is who decides the next step. If a model decides, it is an agent for governance purposes.
Usually the security or governance team operates the inventory, but each agent should have a named business owner accountable for its scope and behavior. Inventory without ownership is shelfware.