Connections
Connections are at the core of Praesidia's security model. A connection defines a trusted relationship between two entities and the controls that govern their communication. If entities are the nouns of the platform, connections are where the policy actually lives — most controls attach to the relationship, not to the entity in isolation, because the same agent legitimately deserves different permissions against different servers.
What is a connection?
A connection is a defined, authenticated link between two entities. Unlike traditional IAM where you assign permissions to individual resources, Praesidia focuses on the relationship between entities.
Requests between connected entities that go through Praesidia are authenticated and checked: a task between two agents against the connection's policy and against the organization's, the receiving agent's and the connection's own guardrails; an MCP tool call an agent makes in a chat turn on Praesidia against its connection's per-tool permissions, with the organization's and the calling agent's guardrails checking the call's arguments and its result. Traffic that goes around Praesidia is neither checked nor recorded.
Creating a connection
To create a connection, you need two registered entities. Specify:
- Client entity: The entity that initiates requests
- Server entity: The entity that receives requests
- Guardrails (optional): Content-level controls
- Policies (optional): Operational controls
A connection is directional. If Entity A needs to call Entity B and vice versa, you create two connections.
Connection types
Praesidia has two types of connection: from an agent to another agent, which carries tasks, and from an agent to an MCP server, which carries tool calls. The client end is always an agent.
Simple point-to-point
The most common setup: one entity connects directly to another.
Agent --> MCP Server
When the agent calls one of the server's tools in a chat turn on Praesidia, the call goes ahead only while the agent has an active connection to that server. Praesidia sends it with the credentials stored for the server and checks it against that connection's per-tool permissions before it reaches the server.
Multi-layered orchestration
For complex setups where requests chain through multiple entities:
Application --> Agent --> MCP Server 1
--> MCP Server 2
Each hop from the agent onward is a separate connection with its own controls: the agent's connection to each MCP server carries its own per-tool permissions, and a connection to another agent its own policy and guardrails. The agent can use an MCP server only through an active connection of its own to that server, and each tool call it makes is checked against that connection, so a permission granted or misconfigured on one hop does not widen another.
No implicit trust
Connections must be explicitly defined. Even if two entities are registered in the same account, they cannot communicate unless a connection exists between them.
This zero-trust approach ensures that adding a new entity to your account does not automatically grant it access to existing services. It also keeps the answer to "what can reach this server?" short and reviewable: it is exactly the list of connections that name it.
Connection-level controls
Beyond guardrails and policies, connections carry several controls specific to the relationship:
- Tool-level permissions. For connections to MCP servers, you can scope which tools the client may invoke — attribute-based permissions that turn "access to the server" into "access to these three tools on the server." Permission sets can be exported and imported, so a reviewed configuration can be reproduced rather than reconstructed.
- Minimum trust level. A connection between two agents can require a minimum trust level of the agent that sends tasks over it. Each time that agent sends a task over the connection, the task is refused if the agent's trust level is below the minimum. The level comes from the agent's trust score, cached for up to five minutes, and an agent whose score cannot be computed counts as untrusted. As the score falls, for example because guardrails keep triggering on the agent's chat turns or on the tasks it receives, the agent loses access to the connection without anyone changing it. MCP tool calls do not read the trust score, so a minimum trust level never gates them.
- Health tracking. Connections record health snapshots over time, giving you a per-relationship view of reliability rather than a single global uptime number.
Updating connections
You can update guardrails and policies on a connection at any time without re-issuing credentials or restarting services. Changes take effect immediately.
This allows you to respond to security events in real time: tighten rate limits, add content filters, or temporarily disable a connection without disrupting the rest of your infrastructure. Suspending a single connection is the narrowest containment action the platform offers — often the right first move when one relationship looks wrong but the entities themselves are healthy.
Monitoring
Each connection provides visibility into the interactions flowing through it. A connection between two agents counts the tasks that complete or fail over it, with their average response time and error rate, and the connection graph view shows how your entities relate at a glance. Agent-to-agent chains have their own view, which shows a chain's tasks and the tool calls made for them, hop by hop. A task joins a chain when it names a parent task, is sent with a task's capability token, or carries the identifier of a chain that already exists in your organization; any other task starts a new chain.
Note: Monitoring and analytics capabilities are continuously expanding.
Common questions
Why are connections directional? Because the security questions differ by direction: what A may send B and what B may send A are separate policies with separate risks. Directionality also keeps audit semantics clean — every logged interaction has an unambiguous initiator. When both directions are legitimate, two connections make both sets of rules explicit.
What happens to in-flight traffic when I change a connection's controls? Control changes apply from the next request onward — there is no redeploy or credential rotation involved. This is what makes the connection the right place for incident response: tightening a rate limit or adding a guardrail takes effect immediately.
Can I restrict which tools an agent can call on an MCP server? Yes — tool-level permissions are configured on the connection, so the same MCP server can expose different tool subsets to different clients. This is the least-privilege pattern for MCP: server access is the door key, tool permissions are the room keys.
How do multi-hop chains stay governed? Each agent-to-agent hop is a task sent over its own connection, checked against that connection's policy and minimum trust level, the organization's intent rules, and the organization's and the receiving agent's guardrails. A hop joins the chain when it names the task it continues as its parent, is sent with that task's capability token, or carries the chain's identifier, and when one of those checks blocks it, the record of the block carries the chain identifier and the connection. A violation at hop three is recorded against that hop's connection within the chain, not smeared across the whole workflow.