See every relationship that gives an AI agent power.
An agent on its own can do nothing. It becomes dangerous through what it is connected to: the agents it can call, the MCP servers it is attached to, the tools on those servers, and the rules — or the absence of rules — on each of those hops. The picture draws the agents you govern and the agent-to-agent connections between them; the servers, their tools and the rule on each hop are read beside it, in the inventory and on the agent itself.
Everything on the map is something you put under control: an agent you registered or adopted, a server you registered, a rule you wrote.
Four relationships, and they are the ones that matter
Not an abstract topology of everything in your estate. The specific hops an attacker — or a confused agent — would have to use.
Agent to agent
Which of your agents can call which. Agent-to-agent (A2A) connections are drawn between the agents you govern, so a chain of three agents ending at a payment tool reads as one picture instead of three separate reviews.
Agent to MCP server
Each connection between an agent and a registered MCP server is its own object, with its own authorization and its own evidence. Connecting one agent to a server never quietly widens another agent's access.
Server to tool
Every registered MCP server is inventoried tool by tool, so the question stops being “is this server allowed?” and becomes “which of its twelve tools is this agent allowed to call?” A tool whose definition changes after you approved it is flagged as drift.
Agent to rule
What each agent is actually permitted to do with those tools: allow or deny by tool name, conditions on the arguments a call carries, a cap on calls per hour, an expiry date on the permission. The edge and its rule are read together.
And the question every review opens with: who owns this agent? Agents with no owner are listed as exactly that.
A picture for the shape, a panel for the detail
The trust graph draws the agents you govern and the agent-to-agent connections between them — the view for “what is talking to what” and for spotting an agent nobody meant to wire up.
The connections list is the same information as rows: every governed hop, what it links, and whether it is active — the view you take into an access review.
For one agent, open its detail panel. It is a panel over the list rather than a page of its own, and its Tool Access tab is where a permission is granted, narrowed with a condition, or denied outright.
What this is not
Two things buyers ask us in the first ten minutes, answered before you have to ask.
It does not collapse into a rating
We do not hand you a single number for an agent and call it security posture. A number is not something you can act on, and it hides the one edge you would have removed. The output is a list you can read: this agent, this server, these tools, this rule.
It maps what you govern, not what exists
The graph is built from agents you registered or adopted and from MCP servers you registered. That boundary is deliberate — an edge on the map is an edge Praesidia can also act on, not an observation you would have to go and enforce somewhere else.
Go deeper
Runtime security
What happens on the edge you just looked at, when the agent actually uses it: identity, rules, approval, containment. →
MCP server governance
Identity per server, tool-level authorization, and evidence for every call your agents make through one. →
Identity and access for AI
Why an agent needs credentials of its own before any of these relationships mean anything. →
Verify the evidence yourself
praesidia-verify re-walks the signatures and the hash chain on your own machine, with no call back to us. →
Start with one agent and see what it can reach
Connect it, look at the hops, then decide which ones it keeps.