Guardrails are the safety controls applied to an agent's inputs and outputs — six independent checks that mask sensitive data, catch hallucinations, filter harmful content, block words or topics, and define what users see when something is stopped.

Overview

Guardrails appear as a single Guardrails group in the agent editor's side-nav, with six types: PII Masking, Hallucinations, Content Filters, Custom Word Filter, Denied Topics, and Blocked Messaging. Each guardrail screen has its own Save button at the top. Your changes are stored only when you click Save. Use Cancel (Reset on Content Filters, Discard Changes on PII Masking) to go back to the last saved settings. The group is permission-gated, so it only appears if your role grants access, and the same controls are available for AI teams.

The controls are independent — set up only the ones that matter for your use case. The detection-model pickers on Hallucinations, Content Filters, and Denied Topics all start on the same workspace default model as the equivalent pickers on the agent's Models tab, so the two surfaces agree until you choose a different model for one of them.

PII Masking

PII Masking filters sensitive information out of inputs and outputs — "Filter out any sensitive information using the following available methods." Three independent methods can be turned on in any combination:

• Regex Pattern — define your own patterns. Add rows with a Name, a Regex Pattern, and a Behavior: Mask, Block, or Redaction. Use this for organization-specific identifiers.

• PII by UnifyApps — "Automatic PII detection and masking by UnifyApps," which detects common personal data without you listing types.

• Automations — apply your own automations to filter sensitive information (pick one or more under Select Automations). Only automations that implement the PII-masking callable interface appear in Select Automations. Build your automation from that interface so it receives the text and returns the masked text or a stop decision.

If you haven't added any regex rows, the table reads No Regex Patterns. Rows left completely blank aren't saved — only filled-in patterns persist.

Under the hood, PII by UnifyApps runs the text through a dedicated named-entity detection service (not your chat model) that finds entities like names, emails, and phone numbers and masks each detected span with asterisks matching its length — the shape of the text is preserved, the value is gone. Masking rewrites the text and lets the conversation continue; only a Block behavior (or an automation that says stop) halts the exchange.

Hallucinations

Hallucinations checks the model's responses and blocks ones that score too low on two measures. Enable either or both:

• Grounding — "Ensure model replies are factually correct based on the supplied reference content." Set a Grounding Score Threshold on a 0–10 scale; responses below it are blocked, and higher values filter more strictly.

• Relevance — "Validate if the model responses are relevant to the user query." Set a Relevance Score Threshold (also 0–10); off-topic replies below the threshold are blocked.

Pick the Hallucination Detection Model that scores the responses. Start with moderate thresholds and raise them if the agent still lets through weak answers.

Both checks are LLM-as-judge. Relevance grades how relevant the context is to the question on an integer 0–10 rubric (0–4 irrelevant, 5–6 moderately relevant, 7–8 highly relevant, 9–10 fully relevant), and greetings and small talk are deliberately graded leniently so casual messages aren't blocked. Grounding grades how well the answer is supported by the context on the same scale. The judge sees the whole conversation — including tool calls and results — plus the latest message and answer. If the judge's output can't be parsed, the score defaults to 0, which fails the threshold, so errors fail safe (block) rather than letting an unchecked answer through. Because these are full judging calls rather than tiny classifications, Hallucinations is the most expensive guardrail — budget one extra model call per enabled check per response.

Content Filters

Content Filters screen for harmful content by category, separately for prompts and responses — "Adjust filtering levels to identify and prevent inappropriate user inputs and outputs." For each category you set a strength: None, Low, Medium, or High (None turns it off).

• Filter Strength for Prompts covers six categories: Hate, Insult, Sexual, Violence, Misconduct, and Prompt Attack (attempts to manipulate or bypass the agent's safeguards).

• Filter Strength for Responses covers five: Hate, Insult, Sexual, Violence, and Misconduct. Prompt Attack applies only to incoming prompts, so it isn't a response category.

Pick the Content Filtering Model that does the detection. Stronger settings catch more but may over-block — tune per category.

Each enabled category is judged by a model, not a keyword list. For Hate, Insult, Sexual, Violence, and Misconduct, the text is sent to your Content Filtering Model with a strict policy-classifier prompt; the model answers with exactly one severity token (None/Low/Medium/High) and is instructed to pick the higher severity when uncertain. Your configured strength is a tolerance level: Low blocks only High-severity content, Medium blocks Medium and High, High blocks anything above None. Prompt Attack is scored by a prompt-attack classifier; you control only its strength. The classifier returns an attack/benign label with a confidence score mapped to severity (benign → None; above 0.9 → High; 0.5–0.9 → Medium; at or below 0.5 → Low). If a category's model call fails, the platform falls back to treating it as Low severity rather than silently passing it, and every per-category verdict is saved onto the message record for audit.

Custom Word Filter

Custom Word Filter blocks words and phrases in inputs and responses — "Use these filters to block certain words and phrases in input and model responses." It has two parts:

• Filter Profanity — on by default; "uses a dynamic list of commonly recognized profanities."

• Words & Phrases — type each word or phrase on its own row; a new empty row appears as you type, and Enter moves to the next row.

Denied Topics

Denied Topics blocks inputs or responses about subjects you define — "Use denied topics to block user inputs or model responses associated with the topic." Add each topic with:

• Topic Name (required).

• Definition (required) — "Provide a clear definition to detect and block user inputs that come under the definition of the topic."

• Sample Phrases (optional) — example phrases that resemble how the topic shows up.

Pick the Topic Detection Model that does the matching. Clear definitions and a few sample phrases make detection far more reliable than a name alone.

Blocked Messaging

Blocked Messaging sets the message shown when a guardrail blocks something — "Define user messages to be published if input or model responses are blocked by the guardrail." You write two messages:

• Blocked Messaging for Prompts — shown when a user's input is blocked.

• Blocked Messaging for Responses — shown when the model's response is blocked.

If you don't write one, the platform falls back to a default: "This query cannot be answered due to content guidelines. Can you please rephrase your request and try again?" Blocked messages pass through the platform's translation store, so a user chatting in another language sees the message in their language when a translation exists. The block itself is recorded on the conversation — the offending message is flagged as a guardrail hit, which is how blocked interactions surface in sessions and traces.

Note: Write blocked messages that are clear and on-brand so a blocked interaction still feels handled rather than broken.

When Guardrails Actually Run

Input and output guardrails run at different points around the model call:

• Input guardrails evaluate the user's message. All enabled families run in parallel — content filters, denied topics, custom word filter, and PII/sensitive information each get their own check, and the verdicts combine: if any one trips, the message is blocked.

• By default, input guardrails run asynchronously alongside the agent — the agent starts working on the reply while the checks run, and just before the response is released the platform waits for the guardrail verdict. If the verdict says block, the blocked message is published instead of the agent's answer. A guardrail can instead run synchronously, in which case the check finishes first and a blocked input never reaches the model.

• Response guardrails evaluate the model's answer before delivery. They rerun the applicable families against the response (content filters, denied topics, word filter, PII, automations) and additionally run the Hallucinations grounding/relevance checks, which only apply to a response.

Workspace vs Agent-Level Guardrails

The platform keeps a global (workspace-level) guardrail configuration alongside each agent's own settings, and at runtime it deep-merges the two — the agent's setting wins wherever both define a value, and the global value fills every gap (an empty list on the agent does not erase a configured global list). A workspace admin can set a safety baseline once, and individual agents only configure what's different for them.