Content guardrails are policy rules that sit on the task path for your AI agents, scanning both the input that arrives and the output that leaves before either crosses a trust boundary. When a guardrail triggers, the platform takes a configured action — blocking the request, redacting the sensitive fragment, issuing a warning for review, or escalating to a human — rather than simply logging the fact after the damage is done. Guardrails apply at the level of each organization and can be scoped to a specific agent or connection, so your security and compliance posture is enforced automatically at every execution, not just when someone remembers to check.

Why Content Inspection Matters for Agentic Systems

Traditional application security focuses on who can make a request. Agentic systems add a second question: what content is moving through the system, and is it safe to let it proceed? An agent that can call tools, write to external systems, or pass results to downstream agents creates a content pipeline that is harder to audit manually. Sensitive data — personal identifiers, credentials, confidential business information — can appear in prompts fed to agents or in the responses they produce. Without automated inspection at the boundary, the only control is trusting that neither the user nor the model made a mistake.

Guardrails address this by treating content as a first-class subject of policy. A rule that prevents PII from appearing in an agent's output is enforced on every task completion, not just when an operator happens to review a log. A rule that blocks requests containing credentials prevents those values from reaching the model in the first place. The coverage is systematic rather than sampled. For context on how this fits the broader data exfiltration risk surface, see Data Exfiltration Risks in Agentic AI.

For a broader look at how guardrails fit alongside other runtime controls, see guardrails vs policies: understanding AI infrastructure controls.

Two Layers: Fast Pattern Matching and Intent

Content guardrails run in two complementary layers, and the difference between them is the difference between catching bad content and catching a bad action.

The first layer is the fast pattern layer. It scans the text of every request and response for known-bad patterns — prompt-injection signatures, PII, credentials, prohibited phrases — and blocks or redacts them before they cross the boundary. This is the layer most people picture when they hear "guardrails," and it is essential. But pattern matching only sees the text of a call, not what the call is trying to do.

That gap is where the hard failures live. An agent can make a call that is technically valid and individually clean, yet still wrong: the right API call against the wrong data. A support agent authorized to read customer records issues a perfectly well-formed query that returns the entire table instead of the one account the task needs. No prohibited pattern appears, every field is legitimately readable, and the call still exfiltrates data at scale. Pure pattern matching has nothing to flag.

The intent layer sits on top of the pattern layer to close that gap. It is a set of declarative, organization-tunable rules that evaluate what a call is trying to do — not just what text it carries. The rules target violation classes that pattern matching structurally misses:

  • Scope escalation — an agent reaching for permissions, resources, or operations beyond the scope it was assigned.
  • Bulk data exfiltration — a single technically-valid call that pulls far more data than the task legitimately needs.
  • Tool out of scope — invoking a tool the agent has no business calling for the task at hand, even if the call itself is well-formed.

The intent layer is rule-based in its current form: you declare the conditions, and the platform evaluates every call against them deterministically. Each rule resolves to one of two verdicts. A block verdict is enforced and fail-closed — the call does not proceed. A flag verdict records the violation for observation without stopping the task, which is the same warn-then-promote workflow you use to roll out any new rule safely: watch the flag rate first, then promote to block once you trust it. This keeps the intent layer honest about what it can and cannot yet decide automatically — it enforces the rules you have declared, not a statistical guess about behavior.

Because these evaluations run on every hop, they extend cleanly to agent-to-agent chains. Each inter-agent call carries a chain identifier that ties every hop of a delegated task back to the request that started it, so a scope-escalation or bulk-exfil verdict is attributable to the exact point in the chain where it happened — not just the terminal agent that made the final call. The chain graph view renders the full call graph of a delegated task hop by hop, with each intent verdict marked in place, so an operator can see precisely where a technically-valid-but-wrong call entered the chain. See Agent-to-Agent (A2A) Communication, Governed and Threat Model: Agent-to-Agent Delegation Abuse for how delegation across a chain produces exactly the "right call, wrong data" exposure the intent layer is built to catch.

The rest of this guide covers the pattern layer in depth — its evaluation types, actions, scoping, and fail modes. Read it alongside the intent layer above: the two work together, with pattern matching gating content and the intent layer gating actions.

Types of Guardrails

Praesidia supports three evaluation types, each suited to a different inspection task.

Rule-based guardrails use deterministic pattern matching — regular expressions and keyword lists — to detect known-bad content. This is the right choice for structured data patterns: credit card numbers, API key formats, national identifiers, specific prohibited phrases. Rule-based evaluation is fast and produces no false negatives for patterns you have enumerated.

ML-based guardrails run content through a moderation model that can classify tone, detect hate speech, or identify content categories that a regex cannot capture. You can point a guardrail at your own moderation endpoint or use a platform-provided model, depending on the sensitivity of the content passing through and your data residency requirements.

LLM-based guardrails use a language model to reason about content in context. This is appropriate for nuanced policy checks — detecting that a response is providing advice outside the agent's intended scope, identifying subtle prompt injection attempts, or evaluating whether output meets brand standards that are easier to describe in natural language than to encode as rules. LLM evaluation adds latency and external dependency, so it is best reserved for checks where context matters and the higher fidelity is worth the cost.

Scoping and Priority

A guardrail can apply across all agents in an organization or to a specific agent. Organization-wide guardrails establish a baseline that no agent can bypass; per-agent guardrails add checks appropriate for that agent's domain. Connection-level guardrails extend this further, allowing you to add checks specific to a particular integration — for example, a guardrail that applies only when an agent is calling a specific external tool.

When multiple guardrails apply to the same task, they run in priority order. A high-priority block rule halts evaluation of subsequent rules, while warn-only rules accumulate without stopping the request. You set priority explicitly when creating or editing a guardrail, giving your team control over the evaluation sequence rather than leaving it to insertion order.

Enforcement Actions

Each guardrail specifies the action to take when it triggers. The available actions reflect a range of severity and reversibility.

Block stops the task entirely. For input validation, this means the task is rejected before it reaches the agent. For output validation, it means the agent's response is suppressed and the task is marked failed. Block is the appropriate action for hard policy violations — a credential in a prompt, PII leaving the system unredacted, or a request that falls outside the agent's permitted scope.

Redact allows the task to proceed but removes or masks the sensitive fragment. For output guardrails, this means the response reaches the caller with the sensitive content replaced by a placeholder. Redact is appropriate for content that should not be transmitted verbatim but whose presence does not indicate a breach on its own — a response that incidentally includes a partial identifier, for example.

Warn records the trigger and continues without modifying the content. This is suitable for monitoring: you want visibility into how often a pattern appears without blocking legitimate traffic. Warning-only guardrails are also useful during the rollout of a new rule, letting you observe trigger rates before committing to a block action.

Escalate routes the task to a human review queue rather than resolving it automatically. This is the right action for content that is ambiguous — where the rule triggered but the correct response depends on context that the system cannot evaluate. The task is held until a reviewer approves or rejects it. For more on designing this decision tree, see designing guardrails: block, redact, or warn?.

Fail Mode: Closed vs Open

Each guardrail has a fail mode that controls what happens if the evaluation itself encounters an error — a provider timeout, a model returning an unexpected response, or an internal evaluation fault. The default is fail-closed: if the guardrail cannot complete evaluation, the task is blocked. This is the conservative choice. A guardrail that cannot be evaluated is not a guardrail; the failure itself is treated as a reason to stop.

Fail-open is available for guardrails where blocking on evaluation error would cause unacceptable disruption. Activating fail-open for a given rule is an explicit decision that trades safety margin for availability. For guardrails protecting against serious violations — credentials, regulated personal data — fail-closed should remain the default.

Templates and Presets

Starting from scratch with guardrail configuration takes time, and the cost of getting it wrong falls on every task that runs before you notice. Praesidia ships with a library of templates for common use cases: PII detection, prompt injection protection, credential detection, toxicity filtering, off-topic response blocking. You can apply a single template or apply a full industry preset that activates a curated set of guardrails appropriate for your sector.

Templates are a starting point, not a final state. Once applied, each guardrail is editable: you can tune the severity, adjust the action, override the fail mode, and add patterns specific to your organization. The template origin is tracked so you can see which guardrails started from a standard definition and which were built from scratch.

For a deeper look at how PII-specific rules work, see PII detection and redaction in AI pipelines.

Audit Logs and Stats

Every guardrail evaluation produces a log record: the result, the scope (input or output), the action taken, a content sample for triggered events, and the processing time. These records are paginated and available from the guardrails audit log view.

Aggregate stats show trigger counts over time by guardrail, making it straightforward to identify which rules are firing most frequently and whether trigger rates are stable or trending upward. An unexpected spike in triggers for a specific guardrail is often the first signal that a new class of problematic input has appeared, that an agent prompt has changed in a way that produces off-policy output, or that a particular integration is behaving differently than expected. For a comparison of guardrails against evaluation and monitoring as distinct layers, see Guardrails vs Evals vs Monitoring.

Common questions

Can I test a guardrail without running it on live traffic? Yes. The platform provides a way to test a guardrail rule against sample content before enabling it on production traffic. This is useful when creating a new rule: you can verify it fires on the inputs you intend and does not fire on inputs you want to permit.

What happens when an agent's output is blocked — does the caller see an error? When a guardrail blocks an agent's output, the task is marked failed and the caller receives an error response indicating that the content did not pass validation. The specific content that triggered the guardrail is not included in the error message returned to the caller; that detail is available only in the guardrail audit log, accessible to operators with the appropriate permission.

How do I apply guardrails to a specific connection rather than all of an agent's traffic? When configuring a connection between an agent and a resource, you can associate additional guardrail rules with that connection. Those guardrails run alongside any agent-level and organization-level guardrails for tasks that flow through that specific connection. This lets you apply stricter content rules to a sensitive integration without affecting the agent's other traffic. See governed connections between agents and resources for the connection configuration reference.

How do content guardrails relate to prompt injection defenses? Guardrails handle the content dimension — what is in a message — while prompt injection defenses focus on detecting manipulative instruction patterns in retrieved content. The two work together: input guardrails can flag injection signatures, while output guardrails catch data that an injection attempt may have caused the agent to surface. See how to detect and defend against prompt injection for a deeper treatment.

Do guardrails add significant latency to every agent task? Rule-based guardrails add minimal overhead. ML-based evaluation adds a network call to a moderation endpoint. LLM-based evaluation adds the most latency, typically comparable to a short model inference. For latency-sensitive paths, use rule-based checks at the baseline and reserve ML or LLM evaluation for high-risk connections where the fidelity justifies the cost.

Praesidia's guardrail system gives your team a systematic way to enforce content policy on every agent interaction — not as a post-hoc audit step, but as an active control on the task path. The result is a clear boundary between what your agents are permitted to receive and produce and what your policy requires, enforced automatically at the point of execution.