Guardrails

How Prompt Guard, Expert Witnesses, Judge, and Jury layer content safety and PII protection around a call, and why they fail closed by default.

A single content filter is a single point of failure: if it misses a jailbreak attempt or its classifier goes offline, nothing else stands between the request and the model. Agent Stream can run every LLM call through a layered, auditable safety pipeline instead, combining deterministic rules, purpose-trained classifiers, and LLM-based review. By default, an Expert Witness or AI Matching detector that cannot complete its check blocks the request instead of letting it through unchecked. PII protection →

What each guardrail layer does

The Prompt Guard fullscreen panel, showing a Regular Expression entry with its When detected action alongside an AI Matching entry with a provider, model, and entity types to detect
LayerRunsWhat it does
Prompt GuardRequest (Regular Expression and AI Matching) and response (Regular Expression only)Deterministic regex and model-backed PII inspection. Each guard’s When detected setting rejects the call, redacts each match with a fixed token such as <EMAIL>, or replaces it with a stable NER ID pseudonym such as [EMAIL_NER_001] to preserve relationships between values. See PII protection and NER IDs →.
Expert WitnessesRequest seam, response seam, or bothPurpose-trained external safety classifiers, consulted in addition to Prompt Guard. Multiple witnesses can run on one surface.
JudgeRequest, alongside the Decider on a buffered request when Mode is Decide LLM based on content (Decider mode), otherwise before the main model callAn LLM-based, or OpenAI-moderation-based, pre-check that can moderate or block a request before the main model is called. Running alongside the Decider keeps the added latency to the slower of the two calls.
JuryResponseA multi-juror LLM post-review that can approve, block, or re-drive (regenerate) the model’s response before it returns, with a single retry policy shared by the whole panel.

Guardrails compose. A surface can run Prompt Guard alone for a low-risk internal tool, or all four layers, plus multiple expert witnesses on both seams, for a customer-facing deployment.

Request-side and response-side guardrails are not the same set of checks:

Request seamPrompt Guard (Regular Expression and AI Matching), Expert Witnesses, Judge. Runs before the main model call, so a block here avoids the cost of that call.
Response seamJury, Prompt Guard (Regular Expression only), Expert Witnesses. Runs after the model responds, so it catches problems only visible in the output itself.

How guardrails apply to realtime voice

For realtime voice, accepted through the Audio Stream element, the Jury is the guardrail that applies: with Review realtime model replies on, it reviews each model reply in Gated or Barge-in mode. The Judge, Prompt Guard, and Expert Witnesses work on text requests and responses. When the surface has governance recording on, a blocked turn is recorded in its governance records as a block. See How realtime voice sessions are governed →.

Built-in Expert Witness providers

Built-in Expert Witness providers include EnkryptAI (Detect API, named-Guardrail, AI-Proxy, and legacy Policy modes), Lakera Guard, Azure Prompt Shields for request-side injection detection, Azure Content Safety for response-side harm moderation, and a generic OpenAI-moderation shape.

Why guardrails fail closed by default

Two guardrails have a fail-open or fail-closed choice, and both default to fail-closed: Expert Witnesses and the AI Matching detector in Prompt Guard. When fail-closed, a check that cannot complete blocks the request rather than passing it through silently. Fail-open is a deliberate choice for either of these two when the operator prefers availability over protection. A Judge or Jury call that errors fails the request, with no fail-open option.

Redact-and-continue

Redact-and-continue is the Prompt Guard behaviour where a matched pattern is replaced in-place, either with a static placeholder such as <EMAIL> or a stable NER ID pseudonym, and the modified request continues down the pipeline. This is distinct from block, which halts the request.

Why layering matters

  • Prompt Guard catches known patterns deterministically and cheaply.
  • Expert Witnesses add purpose-trained detection for categories a regex cannot express, such as jailbreak attempts or nuanced toxicity.
  • Judge stops a clearly unsafe request before the cost of the main model call is incurred.
  • Jury catches problems that only appear in the model’s own output, including cases where Judge passed the request but the response itself needs redirection or regeneration.

Rejection category

A Rejection Category is one of the stable canonical labels applied to every guardrail block: hate, toxicity, prompt injection, jailbreak, PII, secrets, policy violation, and more, with Uncategorized as the fallback. Categories are what make rejection breakdown dashboards possible per team, member, surface, and stage in Observability →.

A failed source authentication, a rate limit, a required payment, a timeout, or an upstream error stop a request for a different reason: they’re not guardrail content decisions, so they’re recorded by their own pipeline stage rather than as a Rejection Category. See Pipeline and stages → for where each of those stages sits.

  • PII protection and NER IDs: A deeper look at how Prompt Guard detects and pseudonymises sensitive data.
  • Pipeline and stages: Where guardrail stages sit relative to routing, the provider call, and metering.
  • OPA policies: Access-control decisions that run alongside content guardrails.
  • Governance records: How each guardrail’s verdict and evidence is captured into a signed, tamper-evident transcript.
  • Observability: The rejection breakdown dashboards built from Rejection Category data.