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.
Every request between connected entities passes through Praesidia, where it is authenticated and checked against configured guardrails and policies.
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
Simple point-to-point
The most common setup: one entity connects directly to another.
Application --> MCP Server
The application authenticates through Praesidia, receives a token, and uses it to make requests to the MCP server. Every request is validated.
Multi-layered orchestration
For complex setups where requests chain through multiple entities:
Application --> Agent --> MCP Server 1
--> MCP Server 2
Each hop in the chain is a separate connection with its own guardrails and policies. The agent authenticates as a client to each MCP server independently — so compromising or misconfiguring one hop never silently widens 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 score. A connection can require the client agent's trust score to be above a threshold at dispatch time. An agent whose trust standing degrades — through anomalies, violations, or failed attestations — loses access to trust-gated connections automatically.
- Backup connections. A connection can designate a backup, so planned maintenance or a suspended primary degrades gracefully instead of failing hard.
- 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. You can see request volumes, response times, and any guardrail or policy violations, and the connection graph view shows how your entities relate at a glance — including agent-to-agent chains, where each hop is attributable back to the request that started it.
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 hop is its own connection with its own controls, and chained calls carry an identifier tying every hop back to the originating request. A violation at hop three is attributable to that exact point in the chain, not smeared across the whole workflow.