Configure guardrail providers
Enterprise Tier
A guardrail is a named policy: a collection of rules plus shared settings such as failure mode and a blocked-response message. Each rule names a check type (what to look for) and a provider (the engine that scores the content). Providers return a normalised score between 0.0 and 1.0; the gateway compares that score to the rule's threshold and applies the rule's action. This guide covers the three providers that ship with Tetrate Agent Router, how they differ, and which check types each one can run. Creating guardrails and rules is covered in Configure guardrails.
Persona: Platform operator working in the Admin Dashboard.
Estimated time: 15 to 25 minutes to review the provider ladder and confirm which engines are enabled for the project.
When this guide applies
| Situation | What it covers |
|---|---|
| Choosing which engine should score a new rule | Comparing regexp, builtin, and tetrate on latency and capability |
| Understanding why a check type is missing from the rule form | The provider-scoped check-type list |
| Tuning a keyword or pattern-based detection | The choices that matter on the builtin provider |
| Wiring the ML provider for jailbreak, toxicity, or semantic topics | tetrate endpoint, timeout, and auxiliary endpoint requirements |
| Confirming a rule can use a given check type | Where the provider-by-check-type support matrix lives, and the cases that surprise |
Outcomes
By the end of this guide:
- The three shipped provider kinds and their place on the cost-and-capability ladder are clear.
- When to use subject-plus-term matching instead of a bare keyword list is clear.
- The required configuration for the
tetrateprovider is known. - A rule is only created with a check type its provider supports.
Prerequisites
- Administrator access to the Admin Dashboard with permission to manage guardrails for a project.
- An active project selected in the Admin Dashboard. Guardrail providers are project-scoped; Rules, Patterns, and Guardrail Providers all operate inside the currently selected project.
- Familiarity with how guardrails and rules are created, covered in Configure guardrails.
Step 1: open Guardrail Providers for the project
- Sign in to the Admin Dashboard and select the project whose providers are to be managed.
- Open Guardrails → Guardrail Providers.
Providers are instances with UUIDs. Rules reference a provider by its id. The page may also show a Provider catalog of pre-built configurations that can be cloned; Your Providers lists the concrete instances rules can use. Three kinds ship by default: regexp, builtin, and tetrate (displayed as Tetrate Guardrails).
Where an external guardrail service is configured in addition to these kinds, it appears as another provider instance under the same page. This guide focuses on the three that ship in the box.
Step 2: choose a provider on the cost-and-capability ladder
All three kinds implement the same contract: they score content and, for redaction, may return a sanitised copy of the text. They never choose to block or redact themselves, because that decision stays with the gateway. 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 NLI entailment via Tetrate's semantic router | Network hop; remote inference |
Stack rules so cheaper providers evaluate first when the same content can be caught by a local check. A pattern match can short-circuit evaluation before a remote ML call runs. Operational ordering guidance is in Guardrails best practices and FAQ.
Step 3: configure a regexp provider
The regexp provider tests named patterns from the Patterns catalog against the content, scoring 1.0 on a match and 0.0 otherwise. Choose it when the content has a predictable shape (email addresses, national identifiers, API key formats) and in-process latency matters. The mechanism is described in About guardrails.
Because detection is only pattern matching, the check type is a label for what the operator intends to catch, and the referenced patterns define the real check.
Per-rule parameters: pattern names from the library, and an optional redaction format (for example {ssn}_REDACTED).
Step 4: configure a builtin provider
The builtin provider is the most configurable local engine. Each rule runs a fixed five-layer pipeline of blocked keywords, an allowlist gate, subject-and-term co-occurrence, detection patterns, and category keywords. Every layer runs, and a match anywhere scores 1.0. The layers, their evaluation order, and what each one matches are described in About guardrails.
Three choices matter most when configuring a rule on this provider:
- Reserve blocked keywords for zero-tolerance terms. That layer is checked first and the allowlist cannot suppress it.
- Prefer subject-plus-term matching to a bare keyword list where a word is only sensitive in context. Target subjects
[customer]with flagged terms[password]fire on "Please reset the customer's password before the demo" and ignore "I changed my password to something stronger", which a plain keyword list cannot do. - Set the minimum severity deliberately. It is the floor for the keyword and detection-pattern layers, so one keyword list can serve several rules at different sensitivities.
Step 5: configure a tetrate provider
The tetrate provider detects meaning rather than literal strings, routing each check to an embedding model, a security classifier, a PII model, or natural language inference (NLI) entailment behind a single endpoint. Which check reaches which model, and which checks cascade across layers, is described in About guardrails.
Step 6: confirm which provider supports which check type
A rule is valid only if its provider supports its check type. The Admin Dashboard mirrors this by scoping the check-type dropdown to the selected provider, so the quickest confirmation is to select the provider in the rule form and look for the check type in the list.
The full matrix is in the guardrails reference. Three cases account for most surprises:
regexpaccepts every check type, because a regular expression is check-type-agnostic.gibberish,relevance, andsentimentare available ontetrateonly.compliance,ban_competitors,ban_code, andprotected_materialare available onbuiltin, and nominally onregexp, but not ontetrate.
What to do next
- Configure guardrails: create a guardrail, add rules that reference these providers, and validate in monitor mode.
- Protect requests with guardrails: the developer-side view of how blocks and redactions appear.
- Guardrails best practices and FAQ: rollout order, fail-open versus fail-closed, and investigation.
Where to go next