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

The platform models every agent-to-resource link as an explicit, named connection. 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 had access to this MCP server last month?" gets a direct answer from the connection list, with timestamps, usage stats, and the policy that was in force during that period.

The policy attached to every connection

Every connection carries a communication policy that governs what can flow through it and at what volume. The policy is evaluated before the agent task is executed, so a violation stops the task immediately and emits an audit record.

The policy covers several dimensions:

Allowed task types. You can restrict which categories of task a connection may carry. A connection to a data-retrieval MCP server can be limited to read-only task types, preventing an agent from using the same connection to issue writes. The default-permissive versus default-restrictive choice is explicit and must be set deliberately when configuring a connection.

Rate limits. Both per-minute and per-hour request limits are enforced continuously. 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.

Connections also carry a scoped set of content-inspection rules applied to this specific edge. Rather than applying a single global guardrail policy to all agent traffic, you can attach a tighter or more permissive set of guardrails to individual connections. A connection to a customer-facing MCP server might carry guardrails that redact PII from responses, while a connection to an internal data tool carries a different profile focused on output size and format validation.

Health monitoring and backup connections

A governed connection is not just a policy container — it is a live operational entity. Rolling health statistics are recorded on each connection: latency, error rate, request counts, and success/failure breakdowns. These stats update as tasks flow through the connection 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.

When a connection becomes unhealthy, you can configure a backup connection that acts as a circuit-breaker failover target: if the primary connection is in a degraded state, traffic can fall over to the backup. This keeps agent workflows running through transient downstream issues without requiring manual intervention.

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?

Policy and guardrails are applied for all agent-to-agent and agent-to-MCP traffic that flows through a connection. Guardrails are not an optional layer agents opt into — they are applied to every request before it is sent. If an agent's access to a resource is modeled as a connection, the guardrails on that connection are applied to all traffic through it.

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.