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.
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
Praesidia is free during beta. Sign up, register your entities, and start defining connections with guardrails and policies in minutes.