About guardrails

Enterprise Tier

The Tetrate Agent Router gateway inspects large language model (LLM) requests and responses in flight. Guardrails decide what is allowed to pass. A guardrail is a collection of rules; each rule performs one check and is executed by a provider. Providers score the content, and the gateway decides what to do with the score. This page explains that model: what each object is, how the pieces connect, and how a single rule is evaluated.

---

For how guardrails are created and rolled out, see Configure guardrails. For field-level lookup, including every setting, all 23 check types, the five provider kinds, and the built-in templates, see the guardrails reference. For where guardrail evaluation sits on the request path, see Guardrails architecture.

The five objects

Guardrail

A named policy: a collection of rules plus shared settings (failure mode, evaluation timeout, blocked response).

Rule

One check type plus an action, run by a chosen provider against input, output, or both.

Provider

The engine that executes a check and returns a score. Each provider supports only some check types.

Check type

A name from a fixed vocabulary (pii for personally identifiable information, toxicity, jailbreak, and others): what a rule looks for.

Pattern

A named, reusable regular expression in a shared catalog that rules reference by name.

What guardrails are

The Guardrails module sits in the request path. It buffers the request body, understands the provider format (Anthropic Messages, AWS Bedrock, OpenAI Chat and Responses), and parses it into a conversation. Before that request reaches the model, and again when the response comes back, it runs guardrails over the content.

Guardrails inspect LLM traffic. Standalone Model Context Protocol (MCP) profile requests are also proxied by the gateway but do not pass through content guardrails: they are governed by identity, access control, and audit instead.

Buffering has one consequence worth knowing before an output rule is enforced. An enforcing rule on the output stage holds the model's response until evaluation completes, which de-streams the response. Rules in monitor mode are evaluated asynchronously and leave streaming intact. The latency implications are covered in Guardrails best practices and FAQ.

Every guardrail evaluation ends in one of three enforcement outcomes:

• block: reject the request or response outright, returning HTTP 403 with a message.
• redact: rewrite the content to mask the offending spans, then let it continue.
• monitor: record what would have happened, but let the content pass unchanged.

A guardrail is the policy object being configured. On its own it enforces nothing: enforcement comes from the rules it contains. A guardrail groups rules that share a few policy-level settings, most importantly the failure mode. If a rule cannot be evaluated because a provider is down, fail-close treats it as blocked and fail-open lets it pass.

Scope: a project-level policy. Guardrails are bound to a project, not to the organisation. The Admin Dashboard's top-left selector switches between an Organisation scope and individual projects (for example default and mvp); the Rules, Patterns, and Guardrail Providers pages all operate inside the currently selected project. A guardrail authored under one project does not apply to another: each project carries its own set of policies.

The Admin Dashboard groups guardrails into four project-scoped surfaces: Overview reports trigger activity across the project, Rules holds the guardrails and their rules, Patterns is the reusable regular expression catalog, and Guardrail Providers holds the configured detection engines.

The top-left selector: an Organisation scope sits above the Projects list. Guardrail policies live under a project, not organisation-wide, so switching projects manages a different set.

Creating a guardrail

Two entry points exist on the Rules page, both scoped to the current project.

• Add guardrail (start empty). The policy is named, its type, category, severity, failure mode, evaluation timeout, and blocked-response message are set, and rules are then added one at a time. This path gives control over every field.
• Create from template (start curated). A ready-made guardrail is cloned from a catalog with its rules, providers, and thresholds already wired, then tailored. This path reaches a baseline for a known regime faster.

Selecting a template clones a fully formed guardrail into the project, where it is then edited like any other policy. Every field of the clone remains editable, and no configuration is hidden. The catalog is grouped by domain and filterable by type (Security, Compliance, Policy, Custom, Evaluator) and severity; the 14 templates it ships, covering data privacy, healthcare, regulatory compliance, security, and content policy, are listed in the guardrails reference. The creation procedure itself, including validation in monitor mode before enforcement, is covered in Configure guardrails.

Providers have templates too. The Guardrail Providers page carries a provider catalog of pre-built configurations to clone when bootstrapping an instance, alongside "Your Providers": the concrete, operator-configured instances that rules reference by name.

How the pieces connect

Three constraints govern how the objects relate:

• The check-type vocabulary is fixed and owned by the system. A rule names one of 23 check types, all of which are listed in the guardrails reference.
• A provider declares which check types it can execute. A rule is valid only if its provider supports its check type, verified when configuration loads rather than at request time. This is why the rule form offers only the checks the selected provider can run.
• A rule carries a configuration blob and a threshold. The configuration holds the check's parameters. The provider scores; the gateway compares score ≥ threshold to decide whether the rule was violated, then applies the rule's action.

The clean split: providers score, the gateway decides. A provider never chooses to block or redact and never compares against a threshold. It only returns a normalised score between 0.0 and 1.0 and, for redaction, a sanitised copy of the text. All policy (thresholds, actions, fail-open and fail-close, chaining redactions between providers) lives in the gateway. This is why the same provider can serve many rules at many thresholds at once.

Rules

A rule is the unit of enforcement. It answers five questions:

• What to look for. The Check type, which the rule's provider must support.
• Where to look. Run on selects the input stage, the output stage, or both. Which kind of content an evaluation ran against (text, image, document, tool call, thinking, or context) is an attribute of the evaluation rather than a setting on the rule, and appears on the resulting trigger record.
• Who evaluates it. The Provider instance, referenced by its UUID.
• How sensitive to be. The Threshold, between 0.0 and 1.0.
• What to do on a hit. The Action (block or redact) and the Mode (enforce applies the action, monitor records the would-be action without applying it).

The parameters of the check itself live in the rule's configuration, whose shape depends on the check type and the provider. Every field, with its permitted values, is tabulated in the guardrails reference.

The rule form changes with the provider and check type

A rule's configuration is not fixed. Two dropdowns at the top of the rule editor reshape everything beneath them.

1. Choosing a provider filters the check-type list. Selecting Tetrate Guardrails narrows the menu to exactly the checks that provider supports (PII, toxicity, jailbreak, banned topics, relevance, sentiment, and others), never one it cannot run. The dropdown reflects the same validation applied when configuration loads.
2. The provider and check-type pair decides the Configuration fields. The rest of the rule stays constant: Run on (input, output, or both), Action (block or redact), Mode (enforce or monitor), an "Edit as JSON (advanced)" escape hatch, and an optional triggered response. The body of the form differs every time.

Provider	Check type	Configuration the form shows
regexp	any (for example PII)	Patterns (one or more, from the pattern library) and Redaction format, which supports a {pattern_name} placeholder such as {ssn}_REDACTED.
builtin	PII or category	Category name, Minimum severity, Keywords (each with a severity), Blocked keywords, Target subjects, Flagged terms, Allowlist phrases, and Detection patterns (inline regular expressions, or entries from the library).
tetrate	PII	Nothing to configure: detection is handled entirely by the provider's built-in machine-learning (ML) model.
tetrate	banned_topics	Banned topics (a list, matched semantically rather than as literal strings) and Similarity threshold (0.0 to 1.0, or the provider default).

regexp with PII: the configuration is a pattern picker plus a redaction format.

builtin: the same rule shell, but a rich multi-field configuration of keywords, blocked keywords, target subjects and flagged terms, allowlist phrases, and detection patterns.

tetrate: the check-type dropdown is scoped to what this provider supports (its ML checks). The Admin Dashboard does not allow a provider to be paired with a check it cannot run.

The check type names what to look for, the provider decides how, and together they determine which controls the form shows. All of it is stored as the rule's configuration blob and forwarded verbatim to the provider as that check's parameters.

How a single rule is evaluated

1. Route to the provider. The gateway groups every active rule by its providerId and hands each provider all of its checks in one call.
2. The provider scores the content. For each check it returns a normalised score between 0.0 and 1.0, plus a sanitised copy of the text if, and only if, it transformed anything.
3. The gateway compares to the threshold. A score at or above the threshold is a violation. Below the threshold, the rule passes.
4. The action is applied. block returns immediately. redact swaps in the sanitised text and re-runs any providers with rules still pending against the new content. monitor logs and continues.

On failure. If a provider errors, the guardrail's failure mode decides: fail-close (the default) treats the rule as blocked, and fail-open skips it. Providers never retry, because deterministic fail-open and fail-close behaviour is the gateway's job.

Patterns

A pattern is a named regular expression, for example us-ssn mapped to \b\d{3}-\d{2}-\d{4}\b. Patterns live in a catalog shipped to the provider as { patterns: [ { name, pattern } ] }. Rules do not have to embed regular expressions; they can point at a catalog entry by name, so one canonical definition of a social security number or an API key is reused across many rules and stays consistent.

Two consumers reference the catalog:

• The regexp and tetrate providers take a rule parameter patternNames (a list of catalog names) plus an optional redactionFormat.
• The builtin provider's detection patterns can each set a patternName that resolves to a catalog regular expression instead of an inline pattern.

The catalog tolerates bad input: a single malformed entry is logged and skipped rather than taking the whole provider offline, and a rule referencing a name missing from the catalog simply drops that reference, which is also logged. Catalog regular expressions are compiled as authored, carrying their own flags, whereas regular expressions written inline on a rule are compiled case-insensitively.

The Patterns library ships more than 80 built-in named patterns grouped by category (EU, Singapore, Brazilian, and UAE PII; Protected Class for Fair Lending; Dangerous Content for Crisis). Entries can be filtered to built-in only, searched by name, or created with New pattern. These are the entries a rule points at by name.

Guardrail providers

Providers are the engines that execute checks. A provider is an instance with its own UUID, and a rule points at that instance rather than at a kind, so several instances of the same kind can coexist in a project. Three kinds ship with Agent Router, ordered below by cost and capability; two further kinds, Azure AI Content Safety and a generic external service, are operator-configured integrations described in the guardrails reference. All of them implement the same contract, so a rule looks identical regardless of which one runs it: only the provider reference changes. What differs is how they detect and which check types they can execute.

Provider (kind)	Tier	How it detects	Latency
regexp	local	Pure pattern matching against the named-pattern catalog.	Near zero, in process
builtin	local	A multi-layer keyword-and-regex detection pipeline.	Near zero, in process
tetrate	ML service	Embeddings, classifiers, and natural language inference (NLI) entailment via Tetrate's guardrails engine.	Network, remote inference

The regexp provider

The regexp provider resolves the patternNames on a rule against the catalog and tests them against the content. A match scores 1.0 and no match scores 0.0. If a redactionFormat is set, matched spans are rewritten for redact rules.

regexp advertises support for every check type. Because detection is only pattern matching, the check type is a label describing what is being detected, and the behaviour is the same whether the rule is tagged pii or secrets. The referenced patterns define the check.

Provider config: patterns (the named-regex catalog).

Per-rule parameters: patternNames, redactionFormat.

The builtin provider

builtin is the most configurable local provider. For a given rule it runs a fixed five-layer pipeline over the content. Unlike a stop-at-first-hit filter, every layer runs and every matched span is redacted into a single sanitised output. A match anywhere scores 1.0.

As with regexp, the check type is mostly a label: the same pipeline powers toxicity, banned_topics, secrets, and the rest. What distinguishes one rule from another is its parameters.

Property	What it means
keywords	Category keywords, each tagged with a severity (high, medium, or low). Matches only if severity is at or above the rule's minSeverity. The general keyword layer.
blockedKeywords	Zero-tolerance keywords. Always matched and redacted, severity ignored, and never bypassed by the allowlist.
targetSubjects and flaggedTerms	The conditional layer. A subject and a flagged term only trigger when they co-occur in the same sentence, producing far fewer false positives than a bare keyword.
allowlistPhrases	An escape hatch. If any allowlist phrase appears, the conditional, pattern, and keyword layers are suppressed. Blocked keywords still fire.
detectionPatterns	Regular expressions: each is an inline pattern or a catalog patternName, plus per-pattern exceptions and a severity band.
minSeverity	The severity floor for the keyword and detection-pattern layers.

The five layers in evaluation order

1. Blocked keywords (zero tolerance): checked first and redacted immediately. The allowlist cannot suppress this layer.
2. Allowlist (gate): if a phrase is present, layers 3 to 5 are skipped for this content.
3. Conditional: for each sentence, if a targetSubject and a flaggedTerm both appear, both are redacted.
4. Detection patterns: inline or catalog regular expressions match the working text, honouring exceptions and the severity floor.
5. Category keywords: keywords at or above minSeverity are matched and redacted.

Why subject and term matters. With targetSubjects: [customer] and flaggedTerms: [password], the rule only triggers when both concepts land in the same sentence.

"Please reset the customer's password before the demo." fires.

"I changed my password to something stronger." is ignored.

The lone mention of "password" never fires, which is the false-positive suppression a plain keyword list cannot provide.

builtin also has one specialised check that skips the generic pipeline: ban_competitors. It takes brandSelf and a list of competitors, matches competitor names (word-boundary matching for single words, phrase matching for multi-word names), and ignores any competitor mention that overlaps the configured brand, so the brand "Acme Cloud" does not trip an "Acme" competitor rule.

Provider config: patterns (optional catalog, referenced by detectionPatterns[].patternName).

Per-rule parameters: keywords, blockedKeywords, targetSubjects, flaggedTerms, allowlistPhrases, detectionPatterns, minSeverity, failOpen, and for ban_competitors: brandSelf, competitors.

The tetrate provider

The tetrate provider, backed by Tetrate's semantic router, detects meaning rather than literal strings. It routes each check to the right model behind a single endpoint:

• Embedding and signal evaluation for toxicity, hate speech, violence, self-harm, sexual content, language, secrets, banned substrings, and regex signals.
• A security classifier (prompt-guard) for jailbreak and prompt injection.
• A PII model that returns detected entities and a masked copy of the text.
• NLI entailment (an auxiliary service) for banned topics, sentiment, bias, code, gibberish, and relevance.

Some checks cascade across layers. Jailbreak first tries the fast security classifier, then falls back to NLI entailment to catch roleplay-style attacks such as "developer mode". Prompt injection cascades three ways: configured known_patterns matched locally, then the ML classifier, then an NLI fallback, short-circuiting at the first layer that fires. In each case the provider returns a score, and the threshold decision stays with the gateway.

Because several checks call a remote model, the provider needs an endpoint (required) and a timeout (required). Checks backed by NLI or the classifier additionally need an auxEndpoint; without it, those specific checks return an error rather than silently passing.

Provider config: endpoint (required), auxEndpoint, timeout (required), patterns (catalog).

Representative per-rule parameters: banned_topics takes topics; language takes allowed_languages and block_unknown; banned_substrings takes substrings and case_sensitive; secrets takes secret_types, custom_patterns, and entropy_analysis; prompt_injection takes known_patterns and ml_detection; toxicity and bias take categories; regexp takes patternNames and redactionFormat.

Which provider handles which check type

A rule is valid only if its provider supports its check type, enforced when configuration loads and mirrored in the UI by the provider-scoped check-type dropdown. The full matrix, covering all 23 check types and every provider kind, is in the guardrails reference. Four properties of that matrix are worth carrying into it:

• regexp accepts every check type, but only because a regular expression is check-type-agnostic. The check type is a label, and the referenced patterns are the real definition.
• builtin covers the keyword-shaped and regex-shaped checks. It does not implement the three inference-backed checks (gibberish, relevance, sentiment) or factual_consistency.
• tetrate is the only shipped provider that reads meaning, and the inference-backed checks are exclusively its own. It does not implement the four checks that are keyword-shaped or policy-shaped by nature: compliance, ban_competitors, ban_code, and protected_material.
• factual_consistency is implemented by none of the three shipped providers, other than nominally by regexp. Groundedness checking requires an operator-configured provider that implements it, such as Azure AI Content Safety.

---

Where to go next

Configure guardrails

Create project policies and rules, and validate in monitor mode before enforcing.

Configure guardrail providers

Choose regexp, builtin, or tetrate for each check type.

Guardrails reference

Every setting, all 23 check types, the five provider kinds, and the built-in templates.

Protect requests with guardrails

How developers see blocks and redactions in application code.

Guardrails architecture

Where guardrail evaluation sits on the request path through the gateway.

Guardrails API reference

Request and response detail for the guardrail and rule management API.