Guardrails are safety and compliance rules that evaluate a user's message before the AI assistant responds. Each guardrail contains a natural-language rule that an LLM evaluates independently — if any guardrail fails, the response is blocked. Use guardrails to enforce content safety, privacy protection, regulatory compliance, and custom business policies.
The Guardrails page displays all configured guardrails with their category, priority, and reporting level.
Key Concepts
Before configuring guardrails, understand how they work at runtime:
- Granted through groups — a guardrail evaluates a user's message only if one of the groups that user resolves into (by direct assignment, role mapping, or auto-assignment rule) lists that guardrail. At runtime the assistant evaluates the union of guardrails from all of the requesting user's groups.
- Input only — a guardrail sees the user's message and nothing else. It runs before knowledge search, and there is no output guardrail, so a rule cannot inspect or reshape the assistant's answer. Write rules that decide whether a question should be answered at all.
- Independent evaluation — each guardrail is evaluated by a separate LLM call, so rules do not interfere with one another.
- Tripwire blocking — if any single guardrail fails (the user message violates the rule), the request is stopped and no answer is generated.
- Concurrent execution — guardrails run in parallel (up to three at a time) to minimize latency.
- Audit recording — every evaluation result (pass or fail) is recorded in the conversation audit trail for analytics, regardless of the guardrail's reporting level.
Creating a guardrail here makes it available, not active. A guardrail that no group lists is never evaluated — it screens nothing, for anyone. This page has no group control; to put a guardrail into effect, go to Settings → Users → Groups, open the group, and add the guardrail on its Guardrails tab (see Users, Roles & Groups). Repeat for every group whose members the rule should cover.
Viewing Guardrails
The Guardrails page offers three view modes, switchable from the toolbar:
- List view (default) — card-based layout showing each guardrail with its name, category badge, priority chip, a preview of its prompt, a reporting-level switch, and a fire badge.
- Table view — columns for name, description, category, priority, reporting level, fire count, fire rate and a sparkline trend; Name, Category and Priority are sortable.
- Analytics view — dashboard with three charts: a compliance trend line, a category distribution breakdown, and a top-fired guardrails chart (which also carries each guardrail's false-positive rate).
Table view lets you sort guardrails by name, category, or priority and see fire metrics at a glance.
Guardrails are listed highest-priority first by default. In Table view, click the Name, Category or Priority header to sort by that column; click it again to reverse the direction. Only those three headers carry a sort control — Description, Reporting Level, Fires, Fire Rate and Trend are not sortable.
The card (List) view relabels the category badge: compliance shows as Regulatory, quality as Behavioral, privacy as Legal, and custom as Procedural. The underlying category names are the ones you see in the edit modal, the filter dropdown, and Table view.
Filter the list from the toolbar:
- Search — case-insensitive substring match across the name, description, and prompt fields.
- Category — narrow to Safety, Compliance, Quality, Privacy, or Custom.
- Priority — narrow to a band: High (8–10), Medium (5–7), or Low (1–4).
- Reporting level — narrow to None, Alerts, or All.
Active filters appear as removable chips below the toolbar. Clear All lives inside the Filters popover, not next to the chips.
The priority scale is not coherent across the product. The Priority filter bands and the edit dropdown both assume a 1–10 scale, but stored priorities can be much larger (the seeded examples run from 60 to 100) — so the Table view priority chip, which always renders the value out of ten, shows readings such as 60/10 and 100/10, as in the screenshot above. A guardrail whose priority sits outside 1–10 will not match any filter band, so it will not appear when you filter by priority. Filter by category or search for it by name instead.
Creating a Guardrail
Open the Create Dialog
Click Add Guardrail in the top-right corner of the Guardrails page.
The create dialog asks for a name and optional description.
Enter a Name and Description
Type a descriptive name for your guardrail (required) and an optional description explaining its purpose.
Configure the Guardrail
After clicking Create Guardrail, the edit modal opens automatically. Fill in the remaining fields:
- Category — select the type of rule (Safety, Compliance, Quality, Privacy, or Custom).
- Priority — the dropdown offers 1 to 10. Higher values indicate more critical rules.
- Reporting Level — None, Alerts, or All. Note that this setting is not yet enforced: every evaluation is audited regardless of what you pick.
- Prompt — write the natural-language rule the LLM uses to evaluate the incoming user message. Be specific about which requests should be allowed and which should be blocked. A guardrail never sees the assistant's answer, so a rule about how responses should be worded cannot be enforced.
Save is disabled until the guardrail has a prompt. A guardrail with an empty prompt does nothing at runtime, so the console will not let you save one.
Creating a guardrail is deliberately a two-step flow: the Add Guardrail dialog asks only for a name and description, then the edit modal opens so you can write the rule. The guardrail exists as soon as the dialog is submitted — so if you close the modal without writing a prompt, you are left with a guardrail that evaluates nothing. Reopen it and add the prompt.
The priority dropdown offers 1–10, but the API accepts any whole number and older guardrails may already carry a much larger value (the seeded examples use 60–100). Such a value is preserved — the modal shows it and saving does not silently rewrite it — but the dropdown will only ever let you pick 1–10, so changing the priority of one of those guardrails means dropping it onto the small scale. Priority is a triage label: guardrails are fetched priority-ascending and dispatched in that order (three at a time), but every guardrail is evaluated and any single failure blocks the request — so priority does not change the outcome or give a rule precedence.
The edit modal provides access to all guardrail configuration fields including the evaluation prompt.
Save Changes
Click Save Changes to persist your guardrail. A success message appears briefly. Saving stores the guardrail, but it does not yet screen anything.
Assign the Guardrail to a Group
Go to Settings → Users → Groups, open a group, and add the new guardrail on its Guardrails tab. The guardrail now evaluates messages from every member of that group, starting with their next message. Until this step is done the guardrail is inert — see Users, Roles & Groups.
Write guardrail prompts in clear, specific language. For example, instead of "block bad content," write "set is_adhere_to_rules to false if the message contains personally identifiable information such as social security numbers, credit card numbers, or home addresses."
Editing a Guardrail
Click any guardrail card (or table row) to open the edit modal. You can modify any field — name, description, category, priority, reporting level, and prompt. Click Save Changes when finished.
The None / Alerts / All buttons on a guardrail card are a shortcut: they change that guardrail's reporting level in place, without opening the modal. The change saves immediately, and only the reporting level is sent — nothing else on the guardrail is touched.
Guardrail bodies are re-read from the database on every request, so editing a guardrail that a group already lists applies to the very next message — including messages in conversations that are already under way.
The edit modal has no group control. Which groups a guardrail applies to — and therefore whether it evaluates anything at all — is managed under Settings → Users → Groups.
Deleting a Guardrail
Open the guardrail you want to remove, then click Delete at the bottom-left of the edit modal. Confirm the deletion in the dialog that appears. Deleted guardrails are permanently removed and cannot be recovered.
Field Reference
| Field | Description | Required | Values |
|---|---|---|---|
| Name | Display name shown in the guardrails list | Yes | Free text |
| Description | Narrative explanation of the guardrail's purpose | No | Free text |
| Category | Classification of the guardrail type | No — defaults to Custom | Safety, Compliance, Quality, Privacy, Custom |
| Priority | Criticality label for admin triage. Guardrails are dispatched priority-ascending, but all are evaluated and any failure blocks — so priority gives no rule precedence | No | The dropdown offers 1–10; existing larger values are preserved |
| Reporting Level | Intended to control audit verbosity. Not enforced today | No — defaults to None | None, Alerts, All |
| Prompt | Natural-language instruction the LLM uses to evaluate the incoming user message | Yes — the modal will not save without one | Free text |
Analytics
Switch to the Analytics view to see guardrail performance metrics over a configurable date range. The Analytics view has its own date picker (with 30d/60d/90d presets) and a Channel filter, separate from the Analytics period date picker used by List and Table view. The Analytics picker allows a range of up to 90 days; the List/Table Analytics period picker is limited to a 30-day span. In both, a wider selection is silently clamped — and the fire-rate API backing the List/Table fire badges rejects ranges over 30 days.
- Compliance trend — line chart of the share of guardrail evaluations that passed. Note this counts evaluations, not conversations: one message screened by three guardrails contributes three results, so a single blocked message does not drag the rate down by a whole conversation.
- Category distribution — breakdown of guardrail fires by category.
- Top fired guardrails — bar chart ranking guardrails by fire count (this is a fire-count ranking, not a priority ranking). Each bar's label also carries that guardrail's fire rate and, where one exists, its false-positive rate — the share of its fires later marked as false positives. There is no separate false-positive chart. Clicking a bar opens that guardrail's edit modal.
In List view, each guardrail card shows a fire badge with the total fire count for the selected date range, and beneath it the fire rate as a percentage of conversations plus a sparkline. The badge color reflects the fire rate: green (below 15%), orange (15% up to 50%), and red (50% or more). Table view shows the same fire count, fire rate and sparkline as plain columns rather than a badge.
Related Pages
- Users, Roles & Groups — assign guardrails to groups; a guardrail only evaluates once a group lists it
- Knowledge Packs — manage the content collections your assistant draws from
- Knowledge Base — create and edit the Q&A pairs that power responses
- Conversation Logs — review conversation history and guardrail evaluation results
- Settings — configure confidence thresholds and escalation rules