AI agent discovery and inventory, from your traffic, telemetry and code.
Praesidia's agent discovery builds one inventory of your AI agents from the traces you send, the agents and MCP servers you register, the unregistered agents that try to reach yours, and connected GitHub and GitLab repositories where repository discovery is enabled for your deployment. It does not scan cloud accounts, data warehouses or endpoints.
Review each discovery sighting, link a registered identity where needed, and adopt it into your AI asset inventory. Runtime controls are configured separately.
Three things the list gives you
A list that fills itself in
Built from traffic, telemetry and code you already have, not from a spreadsheet somebody remembers to update.
The awkward gaps, named
Agents with no owner are called out as such — usually the ones still holding a credential from a project that ended.
An action on every row
Link a discovered agent to a registered identity, then adopt it into the AI asset inventory. Adoption does not issue runtime credentials: enroll the agent, connect its supported routes and configure enforcement separately.
Five sources, and nothing else
- 1
Send your OpenTelemetry GenAI traces to Praesidia and the agents in them are listed as observed.
- 2
Register an agent identity or an MCP endpoint through the supported API or SDK flow. Authentication depends on the entity and route; managed agents use task capabilities, while MCP endpoints use their configured authentication.
- 3
An unregistered agent that tries to reach one of yours is captured for you to claim or ignore.
- 4
Every MCP server you register is inventoried tool by tool, with drift flagged when a definition changes.
- 5
Where repository discovery is enabled, connect a GitHub or GitLab organization to find agents, MCP servers, tools, prompts and vector stores defined in its repositories and re-check them on a schedule.
- 6
Link a registered identity to the sighting and adopt it into the asset inventory, optionally under an AI system. Set up credentials, connections and runtime controls separately.
Where the inventory stops
- It works from traffic, telemetry and code
- The five sources above are the closed list. Where enabled for your deployment, repository scanning reads the GitHub and GitLab organizations you connect; it does not scan your cloud accounts, data warehouses or endpoints today, and we would rather say so than let you find out later.
- Tools are inventoried once a server is registered
- Tool-level inventory and drift detection apply to MCP servers you have registered. A server found in a repository is listed for you to adopt; until it is registered, its tools are a gap in the list, which is why registering servers is the first thing we ask for.
- Observed is not governed
- An agent seen in your traces is listed as observed — seen doing work, not yet under control. Adoption links an existing registered identity into the asset inventory; it does not issue credentials, create connections or enforce traffic.
- Then: observe before you enforce
- Once an agent is governed, a rule can be evaluated and recorded without changing behaviour, so you can read a week of real decisions before anything is blocked.
Works with
- LangGraph
- CrewAI
- OpenAI Agents SDK
- Google ADK
- Microsoft Agent Framework
- MCP server configurations
Repository scans recognise agents built with these frameworks and the MCP servers configured in code. Each framework also has a connection recipe, limited to the setup its page lists. Compare every runtime in the catalog.
Read the docs: getting started. Then: what each agent can reach · runtime security · MCP server governance.
Common questions about AI agent discovery
AI agent discovery is finding the AI agents an organization actually runs, including the ones nobody registered, and keeping them in one inventory with an owner. Praesidia builds that inventory from your traces, the agents and MCP servers you register, the unregistered agents that try to reach yours, and connected GitHub and GitLab repositories where repository discovery is enabled for your deployment.
Five, and nothing else: the OpenTelemetry GenAI traces you send; agents and MCP servers registered through the API or SDK; unregistered agents that try to reach one of yours; the tools of each MCP server you register; and the agents, MCP servers, tools, prompts and vector stores defined in the GitHub and GitLab repositories you connect, re-checked on a schedule where repository discovery is enabled.
No. Cloud accounts, data warehouses, SaaS agent platforms and endpoints are not scanned today. Where enabled, repository discovery reads only the GitHub and GitLab organizations you connect.
It is listed as observed: seen doing work, not yet under control. Register the agent using its supported identity flow, link the sighting, and adopt it into the asset inventory. Adoption does not create credentials or connections. Configure supported runtime routes and controls separately; new policies start in observe mode.
Not until you register them. A server found in a repository is listed for you to adopt; tool-level inventory and drift detection apply to the MCP servers you have registered.
Yes. Discovery and the inventory are in every plan, including the free Developer plan; the governance dashboard is on the Team plan's Advanced tier and on Enterprise.
Go deeper
- Building an AI agent inventory — how to discover, register and maintain the agents you deploy.
- OTLP telemetry ingest for agent discovery — turning the traces you already send into an inventory.
- The AI governance guide — what to do with the inventory once you have it.
- The AI agent security guide — identity, authorization and guardrails for the agents you found.
- Shadow AI and AI agent governance, defined in the glossary.
Find out how many agents you are actually running
Start the inventory with one workspace and your existing traces.