Find every AI agent before it becomes a security blind spot.
Nobody files a ticket to add an agent. They arrive inside a product team's sprint, wired to a database and a payments tool, and the first time security hears about one is usually during an incident or an audit. Praesidia builds the inventory from what your stack already emits and from what tries to connect to it — not from a spreadsheet somebody remembers to update.
Point your existing telemetry at it and the list starts filling itself in.
Four sources, and we will tell you exactly what each one sees
Discovery is the claim most easily oversold, so here is the closed list.
Your OpenTelemetry traces
Send your GenAI traces to Praesidia and the agents in them are listed as observed — seen doing work, not yet under control. Adopt one and it becomes a governed agent with an identity of its own. No code rewrite; if your stack already emits traces, this is a destination change.
Agents you register
Register an agent or an MCP server through the API or the SDK and it arrives with its own credentials, a named owner, and only the connections you granted. This is the path for anything a platform team ships deliberately.
Strangers at the door
When an agent you have never registered tries to talk to one of yours, the attempt does not just fail quietly — it is captured for you to claim or ignore. An agent another team built, reaching for yours, is exactly the thing an inventory built from paperwork never catches.
Registered MCP servers, tool by tool
Every MCP server you register is inventoried tool by tool, so you know what each one can be asked to do before an agent asks. A tool whose definition changes after you approved it is flagged as drift, because a tool's description is an instruction to the model.
An inventory is only useful if it answers the awkward questions
The first review always asks the same things, and “we think about a dozen” is not an answer that survives it. What you get is a list you can filter and hand over, with the gaps visible rather than averaged away.
Agents with no owner are called out as such. An agent nobody is accountable for is not a nuance in a report — it is the first thing to fix, and it is usually the one still holding a credential from a project that ended.
From there the next questions are what it can reach, and what it is allowed to do when it gets there.
Finding it is step one of three
An inventory that only informs you is a longer list of things to worry about. Each of these rows has an action attached.
Adopt it
An observed agent becomes a governed one: its own credentials instead of a shared service account, an owner, and an explicit list of what it may connect to.
Decide what it may do
Allow or deny tools on each connection, put conditions on the arguments a call can carry, cap the calls per hour, and set a date the permission expires.
Keep the record
From that point, its decisions land in an append-only, hash-chained record — signed under the default configuration — that you can export and verify yourself.
Observe first, then enforce: watch the decisions a rule would have made before it changes anything. See how enforcement works.
Where the inventory stops
A discovery claim is easy to make and expensive to be wrong about. These are the edges of ours.
It works from traffic and telemetry
The sources are the four above: your traces, what you register, what knocks on your agents' door, and the servers you have registered. It is not a scanner pointed at your source repositories or your infrastructure accounts, and we would rather say so than let you find out later.
An MCP server nobody registered is not inventoried
Tool-level inventory and drift detection apply to servers you have registered. That is also why registering them is the first thing we ask for: an unregistered server is a gap in the list, and the list is the whole point.
Go deeper
Agent graph
What each agent you found is connected to, and the rule sitting on each of those hops. →
Runtime security
What happens when one of them tries something you would not have approved. →
MCP server governance
Identity per server, tool-level authorization, and evidence for every call through one. →
Getting started
The setup path from an empty workspace to a first agent under control. →
Find out how many agents you are actually running
Start the inventory with one workspace and your existing traces.