When securing AI infrastructure, you need to control two fundamentally different things: what is being communicated and how the communication happens. Praesidia separates these into two distinct concepts: guardrails and policies.
Understanding the difference is key to building effective security for your AI stack. This post is about where the line between the two sits; for how to design the content layer itself, see content guardrails for AI agents.
Guardrails: content-level controls
Guardrails define what can be said or requested in messages between entities. They operate on the semantic content of interactions.
Examples of guardrails:
- An agent connecting to a database MCP server cannot request deletion of records
- A customer-facing application cannot receive responses containing internal system information
- An agent cannot include personally identifiable information (PII) in outbound requests
- Responses from an MCP server must not include raw SQL queries or error stack traces
Guardrails are about meaning and intent. They answer the question: "Is this communication appropriate between these two entities?"
Policies: operational controls
Policies define the operational boundaries of a connection. They govern how communication happens, regardless of content.
Examples of policies:
- Rate limits: A maximum of 100 tasks per minute that one agent can send another over their connection
- Spend caps: A monthly spend cap per connection, after which new tasks are refused until the next month
- Time-based access: Only allow connections during business hours (9 AM to 6 PM UTC)
- Allowed models and tools: A connection that may only use the models and tools you list
IP allowlists sit beside these policies rather than on the connection: they limit the networks that can reach the Praesidia API, for the whole organization, for particular routes or roles, or for one service-account key.
Policies are about mechanics and operations. They answer the question: "Is this communication happening within acceptable operational boundaries?"
Why both matter
You might think that one type of control is sufficient. But in practice, you need both working together.
Consider an AI agent that calls tools on a financial data MCP server. Without operational limits, a bug in the agent could call a tool millions of times, overwhelming the server; in Praesidia the limits on MCP tool calls are a per-minute limit on each tool, counted across all its callers, and an hourly limit for one agent in a per-tool permission on its connection to the server, while the connection policies described above apply to tasks between agents. Without guardrails, the agent could request and receive sensitive financial data it should not see; in a chat turn, Praesidia's guardrails check a tool call's arguments before it is sent and its result before the model reads it, and can block the call or redact data from the result.
Rate limiting alone will not prevent data leakage. Content filtering alone will not prevent denial-of-service through excessive requests. You need both layers. For a deeper look at the data exfiltration risk that guardrails are designed to contain, see data exfiltration risks in agentic AI.
Bidirectional application
Guardrails are applied in both directions in Praesidia; policies are enforced once, when a task is dispatched. When one agent sends a task to another over a connection, guardrails check:
- The request, before the receiving agent runs it: guardrails scoped to input.
- The response, when the receiving agent returns its result: guardrails scoped to output.
The guardrails that run are the organization-wide ones, the receiving agent's, and any attached to the connection itself; a guardrail scoped to both checks both. The calling agent's own guardrails are not applied to the tasks it sends, so there are no separate client-side and server-side settings. This means a receiving agent's output guardrails can stop it returning certain types of data, independent of what the calling agent is allowed to request. Defense in depth.
Practical setup
When you create a connection in Praesidia, you configure both guardrails and policies as part of the connection definition:
- Create the connection between two entities
- Attach guardrails to the connection, to the receiving agent or to the whole organization, each scoped to the request, the response, or both
- Set the connection's policies (rate limits, time windows, spend caps, etc.)
- The connection is now governed by both layers
As your security requirements evolve, you can update guardrails and policies independently without changing the underlying connection or re-issuing credentials.
Getting started
Register your entities, create connections between them, attach guardrails scoped to requests, responses or both, and set each connection's policies. As your security requirements evolve, each layer is independently adjustable — no need to rebuild connections or rotate credentials just to tighten a content rule or adjust a rate limit.
For deeper coverage of how guardrails work at runtime, see Designing Guardrails: Block, Redact, or Warn?. For the connection model that carries these controls, see Governed Connections Between Agents and Resources. For the three-layer picture of guardrails, evaluations, and monitoring together, see Guardrails vs Evals vs Monitoring.
Common questions
What is the difference between a guardrail and a policy? A guardrail checks the content of a communication — whether what is being said or requested is appropriate between these two entities. A policy checks the operational conditions of the communication — whether the request is happening within permitted rate, time, or spend bounds. Both are checked on each task sent over a connection between two agents. On an agent's connection to an MCP server the connection policy does not apply, and guardrails check a tool call when an agent running on Praesidia makes it during a chat turn, not when the tool is called directly through the Praesidia API. Neither substitutes for the other.
Can I apply guardrails and policies to both sides of a connection? Not as separate client-side and server-side settings. Guardrails check both directions of a task between two agents: the request before the receiving agent runs it, and the result it returns. The guardrails that run are the organization-wide ones, the receiving agent's and the connection's own, each scoped to input, output or both. Policies are enforced when the task is dispatched. So a receiving agent can be kept from returning certain content regardless of what the calling agent is permitted to request — defense in depth at the point where data leaves it.
Do I need to recreate a connection to change its guardrails or policies? No. Guardrails and policies are independently configurable on an existing connection. You can tighten a rate limit, add a content rule, or adjust a time window without disconnecting or re-credentialing the entities involved.
How do guardrails relate to MCP tool permissions? Guardrails operate on the content flowing through a connection — what can be said or returned. MCP tool permissions control which tools an agent is authorized to invoke. Both are necessary for a complete least-privilege model: tool permissions limit what actions are available, and guardrails constrain what content can flow when those tools are used. Guardrails do that in a chat turn of an agent running on Praesidia; a tool called directly through the Praesidia API is not checked by guardrails. See Scoping MCP Tool Permissions: Least Privilege for Tools for the tool-permission layer.