In most AI platforms, the relationship between an agent and the resource it calls is implicit: the agent holds a credential, it makes a request, and the resource responds. There is no record of the relationship, no policy attached to it, and no way to revoke or constrain it without touching the agent itself. A governed connection model changes this: every link between an agent and a resource becomes a first-class, policy-bound object that carries its own authentication context, rate limits, spend cap, guardrails, and trust gate — enforced at dispatch, not bolted on afterward.

When agents call other agents or MCP servers through unmanaged paths, the operational picture degrades quickly. You cannot answer basic questions: which agents are authorized to call which resources? What is the monthly spend through a given link? What happens if the downstream resource is slow or unavailable? How do you revoke access to a specific resource without rebuilding the agent?

The answers to those questions live at the connection level. If connections are implicit, there are no answers — only post-hoc log scraping and guesswork.

The governance problem compounds as the agent fleet grows. A team running ten agents across five resources can track relationships manually. A team running fifty agents across dozens of MCP servers and peer agents cannot. Without a structured model, access sprawls, spend attribution breaks down, and the blast radius of a compromised agent becomes impossible to contain. For a structured treatment of how this risk manifests, see data exfiltration risks in agentic AI.

Connections as first-class objects

Praesidia models each agent-to-resource link it governs as an explicit connection record. There are two types: agent-to-agent, where one agent delegates work to another, and agent-to-MCP, where an agent invokes tools on a Model Context Protocol server.

Each connection is a distinct, managed entity with its own identity, lifecycle, and policy. You create it, configure it, test it, and disconnect it through a dedicated interface. The connection is visible in both the management console and the monitoring console, so the same record that an operator uses to configure policy is the record that shows live health and usage.

This explicitness matters for governance. An auditor or incident responder asking "which agents can reach this MCP server?" gets a direct answer from the connection list, filtered by server, with each connection's status, timestamps and usage counts. Last month is harder: a disconnected connection drops out of the list, and the list shows each connection's current policy only, because connections keep no policy history. Creating a connection, changing its policy and disconnecting it each write an audit entry with the user who made the change.

The policy on a connection between agents

A connection between two agents can carry a communication policy that governs which tasks can flow through it and at what volume. The policy is evaluated when a task is dispatched, before the receiving agent runs it, so a violation refuses the task and writes a decision record. Tool calls over a connection to an MCP server are not checked against this policy: the agent's tool rules, the connection's per-tool permissions and the server's per-tool rate limits govern them instead.

The policy covers several dimensions:

Allowed task types. You can restrict which kinds of task a connection may carry: a message, a tool call, or a delegated multi-step job. A new connection allows all three; a list limits it to the kinds named, so a connection can carry tool calls to another agent without letting the caller delegate whole jobs to it, and an empty list refuses every task.

Rate limits. Per-minute and per-hour task limits are checked each time a task is dispatched over the connection. Rate limits protect downstream resources from being saturated by a runaway or misbehaving agent, independent of any limits the resource itself applies.

Active time windows. A connection can be restricted to operate only during defined hours. This is useful for connections to resources that should only be used during business hours or within a scheduled workflow window.

Monthly spend cap. Each connection tracks accumulated cost and enforces a ceiling on monthly spend. When the ceiling is reached, further dispatch through that connection is blocked until the next period begins or the cap is adjusted. This makes spend attribution precise: you know exactly how much each edge in your agent graph is costing, and you can cap it independently.

Model and tool allowlists. If the agent on the other end of the connection can use multiple models or tools, the connection policy can restrict which ones are permitted for traffic flowing through this particular link. This is the mechanism for enforcing, for example, that a connection to a production resource may only use a specific approved model and not an experimental one.

Trust gates and guardrail scoping

Beyond the communication policy, each connection carries two additional governance controls.

A minimum trust threshold on the connection specifies the trust score the calling agent must hold before dispatch is permitted. Trust scores are computed from attestation signals across the agent's history. If the agent's current trust level falls below the connection's threshold — whether because of recent policy violations, unverified attestations, or a trust-evaluation error — the dispatch is denied. The gate fails closed: an inability to evaluate trust results in a denial rather than a pass-through. This is the correct default for a security control. For a deeper look at how trust scores are computed and what attestations inform them, see trust scores and attestations: deciding which agents to trust.

The second is a list of guardrails. Praesidia passes a connection's list to the content check when a task is sent over a connection between two agents and when its result comes back, but applies a listed guardrail only if it is organization-wide or belongs to the receiving agent — and those already run on that agent's tasks — so the list neither adds a check for one connection nor relaxes one, and a connection to an MCP server does not use its list. Content checks on MCP traffic come from the agent's chat turn instead: when an agent running on Praesidia calls a tool, the organization-wide guardrails and the calling agent's own check the arguments before the call is sent and the result before the model reads it, and can block the call or redact PII from the result. A tool called directly through the Praesidia API is not checked by guardrails.

Health monitoring and backup connections

A governed connection is not just a policy container — it is a live operational entity. Health statistics are recorded on each connection between agents: request, success and failure counts, with the average latency and error rate across them. These stats update when a task over the connection completes and are visible in the monitoring console without any additional instrumentation on your part.

Periodic health snapshots give you a historical view of connection health, making it straightforward to correlate an agent failure with a degradation event on a specific connection rather than having to dig through task logs.

Praesidia does not fail over to a backup connection: setting one is refused because automatic failover is disabled. What it has is a circuit breaker on each receiving agent, shared by every connection to it: when an agent keeps failing, Praesidia briefly stops routing tasks to it rather than sending them anywhere else, so a failing agent is not flooded while it recovers.

Cross-org connections and sharing gates

Connections to agents in other organizations are handled differently from same-org connections. Before an agent-to-agent connection can be established across organizational boundaries, the target agent must have been explicitly shared with the requesting organization through Praesidia's agent-sharing feature. The connection creation enforces this gate: if no active share exists, the connection cannot be created.

This prevents one organization from constructing an unauthorized connection to another organization's agent, regardless of whether the target agent's identifier is known. The sharing relationship is the authorization record; the connection creation check enforces it at the infrastructure level.

Team-scoped connections and quotas

Connections can be scoped to a team within the organization. Team-scoped connections contribute to that team's connection quota rather than the organization-wide pool. This lets platform administrators delegate connection management to individual teams while keeping the overall connection footprint bounded.

Enterprise plans support team-level quotas, allowing a central administrator to allocate a fixed number of connections to each team and enforce the boundary without manual coordination. When a team's quota is reached, new connection creation is blocked until the quota is increased or an existing connection is removed.

Common questions

What happens when a connection's monthly spend cap is reached?

Dispatch through that connection is blocked for the remainder of the month. The blocking happens at policy evaluation time, before the task executes, so no further spend is incurred through that connection. The cap resets at the start of the next monthly period. You can raise the cap at any time from the connection policy editor if the limit was set too conservatively.

Can an agent bypass a connection's guardrails by calling a resource directly?

Praesidia checks only the traffic that passes through it: an agent that reaches a resource with its own credentials, outside Praesidia, is not checked or recorded by it. Inside Praesidia, a task sent from one agent to another passes the organization-wide guardrails and the receiving agent's own, on the task and on its result, and an MCP tool call an agent makes during a chat turn passes the organization-wide guardrails and the calling agent's own, on its arguments and its result. An organization owner can call a tool directly through the Praesidia API, and that call is not checked by guardrails. The guardrails listed on a connection add no check of their own, as described above.

Does removing a connection revoke access immediately?

Yes. Disconnecting a connection prevents any further dispatch through it. In-flight tasks that were already dispatched before the disconnect are not cancelled, but no new tasks can be routed through a disconnected connection. There is no grace period or propagation delay.

The connection model gives you a complete, inspectable graph of which agents can reach which resources and under what terms. Each edge in that graph has its own policy, its own health history, and its own cost attribution. The aggregate view — visible in the monitoring console — shows you the full topology of your agent estate at a glance.

Praesidia's approach is to make the implicit explicit: every agent-to-resource relationship that used to live informally in a credential or config becomes a managed, auditable, policy-bound connection. That shift is what makes it possible to govern an agent fleet at scale — not by restricting what agents can do in general, but by governing each specific link between agents and the resources they depend on. For related reading, see Building Secure Multi-Agent Workflows, Scoping MCP Tool Permissions: Least Privilege for Tools, and Trust Scores and Attestations: Deciding Which Agents to Trust.