Guardrails

See Guardrails → for how the four layers compose conceptually. This page is the field-level reference for each layer’s configuration block.

Prompt Guard

The Prompt Guard block holds regex-based content filtering plus model-backed PII detection, screening what a caller sends before it reaches the model and what the model sends back before it reaches the caller. Its regex rules run inside Agent Stream with no extra LLM call, making it the fastest and cheapest of the four guardrail layers. It’s the natural first stop for known-shape sensitive data (SSNs, emails, credit cards) before reaching for something heavier like Judge or Jury.

• Regex guards handle anything with a recognisable shape (SSNs, emails, credit cards, custom patterns) instantly and with no extra model call, so start there.
• Model-backed PII detection only earns its cost when you need to catch PII without a fixed shape, like names, addresses, or organisations. It calls a detection model, so pair it with regex rather than using it alone.
• Add guards on the request side to stop sensitive data before it reaches the model at all; add them on the response side to catch anything the model itself echoes back or generates.

Prompt Guard appears twice on every LLM Surface canvas, once on the request side and once on the response side, and both start disabled. Each node has its own Enabled switch, so you switch the two sides on separately. Select a Prompt Guard node and turn on its Enabled switch, then open its editor: Edit request guards… on the request-side node, Edit response guards… on the response-side node. The button stays disabled until that node’s Enabled switch is on. In the editor, Add Prompt Guard creates a guard, and its Type of detection chooses Regular Expression or AI Matching. AI Matching is offered on the request side only.

Regex guards

Regex guards match a request or response against a pattern and, on a hit, reject, redact, or pseudonymise the matched text.

• Reject the call completely is a hard stop, not a filter, for when a match means something has already gone wrong and the call shouldn’t proceed.
• Redact the text that matches the pattern fits most cases: the sensitive value just needs to disappear, with no need to preserve context across turns.
• A conversation that keeps referring to the same hidden value across turns needs Use a NER ID to preserve context instead. Each distinct value gets its own stable ID rather than being replaced by the same static token every time. See PII protection and NER IDs →.

The rule set:

Add a pattern with Built-in Pattern to pick a ready-made detector by name, or with Custom Regex to write your own expression, with an optional label.

The Built-in Pattern dropdown shows each available pattern by its label. The list includes:

• Email Addresses
• US SSN (Simple Format)
• Phone Numbers
• Credit Card Numbers
• Date of Birth
• IP Addresses (IPv4)
• Passport Numbers (US)
• US Street Addresses

The rejection response:

Judge and Jury offer this same override further down their own panels, each under its own heading.

Model-backed PII detection

An AI Matching guard sends the request text to an OpenAI-compatible detection model that returns typed PII entities (names, addresses, organisations, …), catching PII that regex cannot. Send text only to a trusted detection endpoint, ideally one you host yourself.

• Link coreferences gives every mention of the same person or organisation, such as “Bob” and “Robert Smith”, one shared NER ID. It scans the whole prompt rather than each message on its own, so each turn sends more text to the detection model. Turn it on when the model needs to tell who’s who across mentions.
• Cache detections stays on by default so repeated messages in a multi-turn history skip the detection model on later turns.
• The default, Reject if PII detection is unavailable, fails a request rather than letting it through unmasked. Switch to Continue with regex masking only instead if availability matters more than catching non-regex PII on that one call.

Expert Witnesses

Expert Witnesses attaches one or more purpose-trained external safety classifiers: a sibling to Judge and Jury, but a pure classifier rather than a general reasoning LLM. Different witnesses can sit on different seams (for example, Azure Prompt Shields on the request and Azure Content Safety on the response). A pure classifier is typically faster and cheaper than a full reasoning LLM call, so reach for Expert Witnesses when a purpose-trained detection service already exists for what you’re screening (prompt injection, jailbreaks, harm categories) rather than asking a general LLM (Judge or Jury) to reason about it from scratch.

• With an existing EnkryptAI account, use EnkryptAI (Guardrail), bound to a guardrail you configure directly in EnkryptAI’s own console.
• The named cloud-security providers (Azure Prompt Shields, Azure Content Safety, Lakera) make sense when you already use that vendor elsewhere in your stack.
• Generic (OpenAI-moderation shape) is for a custom or self-hosted classifier that speaks the OpenAI-moderation-style response shape.
• Fail open on provider error stays off by default, so a guardrail outage blocks calls instead of silently letting them through. Turn it on only if availability matters more than this particular check on that seam. Among the guardrails, this switch and the AI Matching detector’s If PII detection is unavailable setting are the only fail-open choices, and both start fail-closed.

Each witness:

The connector configuration:

Which seam a witness checks, the request before it reaches the LLM or the response before it reaches the client, is fixed by whether you place it on the request-side or response-side canvas node. Unlike Prompt Guard, Judge, and Jury, Expert Witnesses have no custom-rejection-response editor; a flagged verdict always uses the default rejection.

Provider options

Judge

The Judge block evaluates a request before it reaches the LLM. In Decide LLM based on content mode on a buffered request, it runs in parallel with the Decider; otherwise, including on a streamed request, it completes before the model is called. A surface with a Judge can still stream its responses. Reach for it when you need judgment calls beyond what a fixed regex pattern or a narrow classifier can make: standard content-moderation categories, or your own custom criteria.

The Judge node is already on every LLM Surface canvas and starts disabled. To switch it on, select the node, turn on its Enabled switch, then open its editor with Edit judge…. The Judge doesn’t run on realtime voice, where model replies can be reviewed with the Jury instead, and the dashboard won’t save a canvas with both an enabled Judge and an enabled Audio Stream element.

• Builtin Content Moderation covers standard categories (hate, violence, sexual content, etc.) as a single classification call with nothing to write; it’s enough for most surfaces.
• Custom, domain-specific judgment calls for User-Defined LLM Judge instead: you write the criteria via Strictness, Focus Areas, and Custom Instructions, and a full LLM reasons about the request against them.
• Start Confidence Threshold around 0.7–0.8, then adjust from there: raise it if legitimate requests are getting rejected on borderline calls, lower it if clearly bad requests are slipping through as low-confidence approvals.
• For a reasoning model (e.g. Qwen3) that exhausts its token budget on reasoning before producing a decision, turn on Disable Thinking / Chain-of-Thought. Left off, the system already auto-retries with thinking disabled once that happens.

A judge rule’s name is generated automatically from whichever higher-level control produced it (a builtin-mode rule is named “Content flagged” or “Category: <cat>”; an LLM-mode rule “JSON field rejection” or “Regex rejection”), so you configure Moderation Categories or Decision Evaluation above rather than a rule list directly. The rejection response itself comes from the “Custom Rejection Response” card: Status Code (default 403), Response Body, Content-Type (default application/json).

Provider/model/endpoint target fields (shared by Judge, Jury, Decider, failover, and load-balancing targets):

Jury

The Jury block evaluates the LLM’s response before it returns to the caller. It’s the mirror of Judge on the way out, catching problems that only reveal themselves once the model has generated an answer (a policy violation, an unwanted claim, whatever your jurors are built to catch). Because the Jury needs the whole response, an enabled Jury answers a streaming request with a buffered response. On a realtime voice surface, the Jury reviews each model reply when Review realtime model replies is on (see Server tools and modalities → Realtime voice).

Like the Judge, the Jury node comes with every LLM Surface canvas, switched off. Select it and turn on its Enabled switch, then use Add juror to add jurors and Verdict & redrive settings… for the verdict and redrive options.

• Parallel, the default, is the strictest bar: every juror must approve independently, and since they run concurrently it costs no extra latency over the slowest one.
• Serial exits early on the first rejection, so order cheaper or faster jurors first.
• Majority trades some strictness for resilience against a single juror’s false positive: more than half approving is enough.
• Redrive Policy defaults to no retries. Change it only if the model should get a chance to fix its own answer using the Jury’s rejection reason, since each redrive step costs another full model call.

Execution modes:

Each juror:

Decision evaluation modes:

The Jury’s own version of this override, under its Final negative-verdict response heading:

Related

• Guardrails concept: The four-layer model, fail-closed behaviour, and the rejection taxonomy.
• PII protection and NER IDs: How masking and pseudonymisation work conceptually.
• Routing and variants: The Decider, which shares the same provider/model/endpoint target shape used here.
• OPA policies: Access-control decisions that run alongside these content guardrails.
• Core configuration: Where Prompt Guard, Expert Witnesses, Judge, and Jury sit among a surface’s other optional configuration blocks.