Guardrails

Estimated reading time: 9 minutes

Guardrails are content-level controls that define what can be said or requested in messages between entities. They operate on the semantic content of interactions, not just authentication headers or API keys.

Why guardrails?

Authentication answers "who is calling?" but not "what are they asking for?" In AI infrastructure, the content of every interaction matters:

• An agent might be authorized to access a database tool but should not be allowed to request deletion of records
• An MCP server might return data that should be filtered before reaching certain callers
• An application should not receive raw error messages or internal system information

Guardrails close this gap by inspecting and filtering the content of interactions.

Configuring guardrails

A guardrail has a scope, which sets the direction of content it checks, and a place it attaches, which sets the traffic it covers.

Scope: input, output or both

• Input: content on its way in. On a task between two agents, that is the task's input before the receiving agent runs it; in a chat turn, the user's message and each MCP tool result before the model sees it.
• Output: content on its way out. On a task, that is the result before it is returned to the calling agent; in a chat turn, the agent's answer and the arguments of each MCP tool call before the call is sent.
• Both: input and output. This is the default.

Where a guardrail applies

• Organization-wide: every task and chat turn in the organization.
• One agent: the tasks that agent receives and its chat turns.
• One connection: the tasks carried over that connection between two agents.

On a task, the guardrails that run are the organization-wide ones, the receiving agent's own and the connection's. The calling agent's own guardrails are not applied to the tasks it sends, so there are no client-side or server-side guardrails: to control what an agent may send, attach an input guardrail to its connection or to the organization.

When an agent running on Praesidia calls an MCP tool during a chat turn, guardrails check the call in both directions. A block stops the call before it is sent, or replaces the result with a notice; a redaction rewrites the arguments or the result. The guardrails used there are the organization-wide ones and the calling agent's own; a connection's guardrails are not added. A tool called directly through the Praesidia API, outside a chat turn, is not checked by guardrails.

Example configurations

Restrict tool access

Allow an agent to use read-only tools on an MCP server but block write operations:

• Per-tool permissions on the agent's connection to the MCP server: deny create_*, update_* and delete_*. A matching deny wins, and a tool that no rule matches stays allowed, so list_* and get_* remain available. This is a permission on the connection rather than a guardrail; see connections.

Filter sensitive data

Keep personal data in MCP tool results away from the model, and out of what an agent returns:

• Input guardrail, organization-wide or on the agent: redact email addresses, phone numbers and national identification numbers. In a chat turn it rewrites each tool result before the model sees it.
• Output guardrail on the agent: the same redaction on its chat answers and on the results of tasks it receives.

Content restrictions

Prevent an agent from sending requests that include prohibited content:

• Input guardrail on its connection to the receiving agent, or organization-wide: block requests containing financial advice, medical diagnoses, or legal recommendations. The sending agent's own guardrails do not check the tasks it sends.

The intent layer: catching the right call on the wrong data

The controls above are a fast pattern layer: they inspect the content of a message and block or redact known-bad patterns — prompt injection, PII, credentials, prohibited tool names. Pattern matching is essential, but it only sees the text of a call, not what the call is trying to do.

The intent layer sits on top. It evaluates the action a call represents against declarative, organization-tunable rules, so it can catch calls that are technically valid and individually clean but semantically wrong — the right API call against the wrong data. Its rules target violation classes that pattern matching misses:

• Scope escalation — an entity reaching for permissions or resources beyond its assigned scope.
• Bulk data exfiltration — a single well-formed call that returns far more data than the task needs.
• Tool out of scope — invoking a tool that has no legitimate role in the current task.

The intent layer is rule-based: you declare the conditions, and a rule that matches a task returns the verdict you set for it; when several rules match, the strongest verdict applies. A block verdict is enforced and fail-closed: the task is refused. A flag verdict is recorded for observation, and the task goes ahead. When an agent sends the task with no person behind the request, as in an autonomous chain, by default either verdict holds the task instead until a person approves or rejects it, and a rejection or a hold that expires unanswered cancels the task. Flag first to measure, then promote to block once the rule is trusted.

Intent rules run on the tasks sent over a connection between two agents, so they apply at the agent-to-agent hops of a chain; they do not run on chat turns or on the MCP tool calls an agent makes. A task that an agent sends while working on another task, naming that task as its parent or acting with that task's capability token, joins the parent's chain, and the decision record of an intent block or flag carries the chain identifier, so the verdict can be traced to the hop where it happened. The chain graph view shows a chain's tasks and the tool calls made for them, hop by hop. For the concepts behind this, see Content Guardrails for AI Agents and Agent-to-Agent (A2A) Communication, Governed.

Guardrail engines

Under the configuration model above, three evaluation engines do the work, and a guardrail can combine them:

• Rule and pattern matching. Deterministic checks — keyword and regex rules — evaluated in-line with negligible latency. Patterns are guarded against pathological regex (ReDoS), so a badly written rule cannot stall the evaluation path. Best for tool-name restrictions, known-bad strings, and structural checks.
• PII detection and redaction. Purpose-built detection of personal data categories (emails, phone numbers, identifiers) with redaction as the action — the content proceeds with the sensitive spans removed, rather than the whole message being blocked.
• LLM-based evaluation. A model-judged check for semantic categories that patterns cannot express — topical restrictions, intent classification, nuanced content policies. Higher latency and cost than pattern rules, so it is best reserved for the flows whose risk justifies it.

Templates and presets cover the common configurations, so most teams start from a preset and tune rather than authoring from scratch. On a task or a chat turn, each guardrail that runs adds an entry to the guardrail log with its verdict, passed or triggered; a triggered entry also keeps the action taken and an excerpt of the content checked, and the guardrail's trigger count goes up by one. That is how you tell a guardrail that is working from one that is merely configured. Guardrails the model gateway applies to model traffic add no entry to the guardrail log; the gateway reports the requests they block as decision records, and recording is not guaranteed.

Guardrails vs policies

Guardrails and policies serve different purposes:

Both work together. On a task between two agents, passing the connection's policy (within its rate limits and time window) does not exempt the task from guardrail evaluation (requesting prohibited data); either check can stop it.

Common questions

Which guardrail engine should I start with? Pattern rules and PII redaction first: they are deterministic, near-free in latency, and cover the highest-frequency risks (known-bad content, sensitive data in responses). Add LLM-based evaluation selectively, on the flows where semantic judgment is worth its latency and cost.

Do guardrails block by default, or just log? It depends on each guardrail's action. Block, the default, stops the content; redact and replace modify it before delivery; warn records the trigger and lets the content through. A guardrail given a rollout stage applies its action only at the enforce stage, and the organization's governance mode can hold it below that; until then a trigger is recorded and the content goes through. For intent-layer rules specifically, you set each rule's verdict: a block verdict is enforced and fail-closed (the task is refused), and a flag verdict is recorded while the task goes ahead; on a task an agent sends with no person behind the request, by default either verdict holds the task until a person approves or rejects it. The recommended pattern is flag first to measure, then promote to block once the rule is trusted.

Why configure guardrails per direction rather than per entity? Guardrails are not set per direction on a connection: each one has a scope and a place it attaches. The scope is the direction it checks, input, output or both, because the risks differ: what an agent may receive (injection, prohibited requests) and what it may send back (PII, internal details) are different rule sets. The place it attaches is the organization, one agent or one connection, and a connection's own guardrails let the same agent carry different rules on different relationships.

How do I know a guardrail is actually working? Check its guardrail log. On tasks and chat turns, each guardrail that runs adds an entry to the guardrail log with its verdict, passed or triggered, and the log can be filtered by guardrail and by agent; the guardrail's trigger count shows how many times it has fired. A guardrail with no entries while the agent it should cover has had tasks or chat turns is not running on them — for example, it is disabled, attached elsewhere, or scoped to the other direction. Guardrails the model gateway applies add no entry to the guardrail log; the gateway reports the requests they block as decision records, and recording is not guaranteed.

Next steps

• Set up policies on connections
• Learn about connections