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.
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 requests per minute from a specific application
- Geographic restrictions: Only allow connections from IP addresses in approved regions
- Volume caps: A daily maximum of 10,000 requests per connection
- Time-based access: Only allow connections during business hours (9 AM to 6 PM UTC)
- IP allowlists: Only accept requests from known IP ranges
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 accesses a financial data MCP server. Without policies, a bug in the agent could make millions of requests, overwhelming the server. Without guardrails, the agent could request and receive sensitive financial data it should not have access to.
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
Both guardrails and policies are applied bidirectionally in Praesidia. For each entity in a connection, you can set controls:
- As a client (outgoing requests / incoming responses): What can this entity send? What can it receive?
- As a server (incoming requests / outgoing responses): What requests will this entity accept? What can it return?
This means an MCP server can have its own guardrails that prevent it from returning certain types of data, independent of what the calling application 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
- Set guardrails for each direction (client-side and server-side)
- Set policies for each direction (rate limits, geo restrictions, 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, and configure guardrails and policies per direction. 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, volume, or geographic bounds. Both run on every connection; neither substitutes for the other.
Can I apply guardrails and policies to both sides of a connection? Yes. Both controls are applied bidirectionally. You configure what each entity may send and receive as a client, and what it will accept and return as a server. This means an MCP server can enforce its own content restrictions on outgoing responses independent of what the calling agent is permitted to request — providing defense in depth at each end of the connection.
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 geographic restriction 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. See Scoping MCP Tool Permissions: Least Privilege for Tools for the tool-permission layer.