Configure guardrail providers

Enterprise Tier

Guardrail providers score content for guardrail rules, each returning a normalized score between 0.0 and 1.0 that the gateway compares to the rule's threshold. Providers belong to a project: each project starts with its own regexp, builtin, and tetrate providers, and any further provider, such as Azure AI Content Safety or Amazon Bedrock Guardrails, is created from the provider catalog.

---

Persona: Platform operator working in the Admin Console.

Estimated time: 15 to 25 minutes to review the provider ladder and confirm which providers the project owns. Add 10 minutes to stand up an Azure AI Content Safety provider, once the Azure resource and its key are in hand, and 20 minutes for an Amazon Bedrock Guardrails provider, once the guardrail version and the IAM access key exist.

When this guide applies

Situation	What it covers
Choosing which provider should score a new rule	Comparing regexp, builtin, tetrate, and azurecontentsafety on latency and capability
Understanding what a project already owns and what the catalog offers	The difference between a catalog template and the project's own providers
Adding a provider a project does not yet own	Creating one from a catalog template
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 machine-learning (ML) provider for jailbreak, toxicity, or semantic topics	tetrate endpoint, timeout, and auxiliary endpoint requirements
Sending checks to Azure AI Content Safety	Creating the provider, storing and rotating its write-only credential
Enforcing guardrails already defined in Amazon Bedrock	Checking the prerequisites, creating the provider, storing and rotating the IAM credential, choosing how rules map to Bedrock guardrails, creating the guardrail and its rules, and the monitor-first rollout
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 provider kinds and their place on the cost-and-capability ladder are clear.
• The difference between the catalog and a project's own providers is clear, and a provider can be created from a template.
• When to use subject-plus-term matching instead of a bare keyword list is clear.
• The required configuration for the tetrate provider is known.
• An Azure AI Content Safety provider can be created with its endpoint, and its credential stored and rotated.
• An Amazon Bedrock Guardrails provider can be created with its Region and IAM credential, the mapping of rules to Bedrock guardrails chosen, a guardrail and its rules created and bound to a guardrail version, and rolled out in monitor mode before it is enforced.
• A rule is only created with a check type its provider supports.

Prerequisites

• Administrator access to the Admin Console with permission to manage guardrails for a project.
• An active project selected in the Admin Console. 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.
• For the Azure steps only: an Azure AI Content Safety resource, its endpoint, and one of its keys.
• For the Bedrock steps only: a published Bedrock guardrail and an IAM user with an access key, as checked in Step 8.

Step 1: open Guardrail Providers for the project

1. Sign in to the Admin Console and select the project whose providers are to be managed.
2. Open Policies → Guardrails → Guardrail Providers.

The page has two halves:

• Your Providers lists the concrete providers this project owns. Each is an instance with its own UUID, and a rule binds to that instance rather than to a kind, so several instances of the same kind can coexist in one project. These are the only providers a rule can use.
• Provider catalog lists the templates the product ships. A template is a starting configuration, shared across every project and read-only: it cannot be edited, deleted, given a credential, or referenced by a rule. It exists to be copied into a project.

A newly created project arrives owning a regexp, a builtin, and a tetrate provider (the last displayed as Tetrate Guardrails), copied from the catalog on its behalf, so a guardrail can be written and enforced in it without any provider setup. Azure AI Content Safety and Amazon Bedrock Guardrails are deliberately not among them: neither can evaluate anything without a credential, so each stays a catalog template until an operator configures one, as described in Step 7 and Step 8. A generic external guardrail service has no catalog template at all; it is registered with the tetrate CLI by following Connect an external guardrail service.

What changed for projects that existed before

Before the provider catalog existed, regexp, builtin, and tetrate were three shared rows used by every project. They are now catalog templates, and each project owns its own copy. Existing rules were moved onto their own project's provider of the same kind during the upgrade, so what each guardrail enforces is unchanged. One consequence reaches automation: a script that creates rules against one of the three former shared provider identifiers is refused, and should read the project's own providers and use their identifiers instead.

Step 2: choose a provider on the cost-and-capability ladder

Every kind answers the same scoring interface (the external kinds implement it as the versioned Guardrail service contract; the in-process kinds answer it in process): each scores content and, for redaction, may return a sanitized 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, which check types they can execute, and where the content goes.

Provider (kind)	Tier	How it detects	Latency	Content leaves the environment
regexp	Local	Pure pattern matching against the named-pattern catalog	Near zero; in-process	No
builtin	Local	A multi-layer keyword-and-regex detection pipeline	Near zero; in-process	No
tetrate	ML service	Embeddings, classifiers, and natural language inference (NLI) entailment via Tetrate's semantic router	Network hop; remote inference	No in the Self-Hosted Data Plane model, where the callout stays inside the customer network; in Tetrate-hosted deployments the data plane is Tetrate-operated
azurecontentsafety	Third-party SaaS	Azure AI Content Safety: severity analysis, Prompt Shields, protected-material detection, and groundedness	External round trip; metered per call	Yes; content is sent to Azure
bedrockguardrails	Third-party SaaS	A guardrail defined in Amazon Bedrock: content filters, denied topics, word filters, and sensitive-information filters, as configured in AWS	External round trip; metered per call by AWS	Yes; content is sent to Amazon Bedrock in the provider's AWS Region

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.

Where a generic external guardrail service is configured instead, it is connected through a provider of kind externalservice, appears as another provider in Your Providers, and declares the checks it supports per instance. A vendor service without a native implementation of the contract is reached through an adapter that translates between the two. See the guardrails reference.

Step 3: create a provider from a catalog template

A provider is created by copying a catalog template into the project. There is no blank provider form: the template supplies the kind, which is required and cannot be changed afterwards.

1. Open Policies → Guardrails → Guardrail Providers with the target project selected.
2. Find the kind in Provider catalog and choose Use this template.
3. Give the provider a name. Names are unique within the project, so a second instance of a kind needs a name of its own.
4. Fill in the settings the template leaves blank. For regexp and builtin there are none; for tetrate, azurecontentsafety, bedrockguardrails, and externalservice the connection settings are required. The externalservice settings are covered in Connect an external guardrail service.
5. Save. The provider appears under Your Providers and rules can bind to it.

A provider is created enabled unless it is saved otherwise. Enabled is not a cosmetic flag. A new rule cannot be written against a disabled provider at all, and rules that already exist are skipped at evaluation time with no error and no trigger record, so a guardrail whose provider is disabled stops enforcing without saying so. Disable a provider only as a deliberate act, and re-check the guardrails that depend on it.

Two rules govern what a guardrail rule may bind to:

• A rule can only bind to an enabled provider its own project owns. A template, a provider in another project, and an identifier that names nothing are refused identically, with an error stating the provider is not available in this project. A disabled provider is refused separately, and the error says it is disabled, so the fix is to enable it rather than to look for a different provider.
• Creating a guardrail from a guardrail template binds each of its rules to the project's own provider of the same kind. Where the project owns no provider of the kind a template needs, the guardrail is refused with an error naming that kind, rather than created with rules that can never run. Creating or enabling a provider of that kind and repeating the operation resolves it.

The same work through the admin API is a POST to the project's guardrails/providers collection carrying kind, name, and config, and through the CLI it is tetrate agentrouter api guardrails providers create. Listing providers returns only the project's own rows; templates are returned only when they are asked for explicitly.

Step 4: 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 5: configure a builtin provider

The builtin provider is the most configurable local provider. 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 6: configure a tetrate provider

The tetrate provider detects meaning rather than literal strings, routing each check to an embedding model, a security classifier, a personally identifiable information (PII) model, or NLI entailment behind a single endpoint. Which check reaches which model, and which checks cascade across layers, is described in About guardrails.

Step 7: configure an Azure AI Content Safety provider

The azurecontentsafety provider sends content to a Microsoft Azure AI Content Safety resource and returns its results as normalized scores. It is the only kind that covers factual_consistency (groundedness), and content evaluated by it leaves the customer environment, so binding a rule to it is an explicit decision per rule. The nine check types it supports, and the stage each runs on, are in the capability matrix.

Setup has two parts, kept deliberately separate: the configuration, which is stored as written and delivered to the gateway, and the credential, which is never part of it.

Create the Azure provider

1. Create the Content Safety resource on the Azure side, and note its endpoint URL and one of its keys.
2. Open Policies → Guardrails → Guardrail Providers with the target project selected.
3. In Provider catalog, choose Use this template on Azure AI Content Safety.
4. Name the provider.
5. Set endpoint to the resource URL, for example https://<resource>.cognitiveservices.azure.com. The other settings (api_version, groundedness_api_version, and timeout) can stay blank.
6. Save the provider disabled.

Only the endpoint's shape is validated on save, so a bad timeout or API version fails later, without an error. The settings, their defaults, and these failure modes are in Azure AI Content Safety: configuration and credential.

Store the Azure credential

1. Open the provider under Your Providers.
2. Enter the Azure key in the credential field.
3. Save, then enable the provider.

Through the admin API the same operation is SetGuardrailProviderSecret, and through the CLI it is tetrate agentrouter api guardrails providers set-secret.

A credential in the configuration is rejected, not ignored

A create or update carrying an api_key in the configuration of an azurecontentsafety provider fails, and nothing is stored. Resubmit the configuration without it, then set the credential through the credential operation.

Do not leave an Azure provider enabled with no credential

This kind cannot evaluate anything without a stored credential. Save the provider disabled, store the credential, then enable it, all in the same sitting. A rule cannot be bound to a disabled provider.

How the credential is stored, why no read returns it, and how it reaches the gateway are in the credential reference. What an operator sees on the data plane is covered in Configuration propagation.

Rotate or retire the Azure credential

1. Open the provider under Your Providers.
2. Enter the new Azure key.
3. Save.
4. Allow a few minutes for the gateway's periodic reconcile to deliver it, keeping the previous Azure key valid until traffic is observed succeeding on the new one.

The provider keeps its identifier, its configuration, and every rule bound to it. To retire the credential, delete the provider or the project that owns it.

Step 8: configure an Amazon Bedrock Guardrails provider

The bedrockguardrails provider, displayed as Amazon Bedrock Guardrails, evaluates content against a guardrail that already exists in the customer's AWS account. The guardrail itself is defined and edited in AWS, and content evaluated by this provider is sent to Amazon Bedrock, so binding a rule to it is an explicit decision per rule. The provider holds the Region, an optional endpoint, and the credential; each rule names the guardrail and version it applies. How Bedrock's result combines with the rule's action and mode is in How a Bedrock result combines with the rule.

Check the Bedrock prerequisites

Nothing is verified against AWS when the provider or a rule is saved, so a gap here first shows up on live traffic. Confirm each item before continuing:

1. A Bedrock guardrail exists in the Region the provider will name, with a published numbered version. See Bedrock guardrail versions.
2. An IAM user with a long-term access key holds bedrock:ApplyGuardrail on every guardrail the rules reference. IAM roles, IRSA, and temporary credentials are not supported. The policy is in Bedrock prerequisites and IAM policy.
3. Every data plane serving the project runs 0.11.0 or later.
4. The data plane can reach https://bedrock-runtime.<region>.amazonaws.com on port 443, or the VPC endpoint the provider will name.

Create the Bedrock provider

1. Open Policies → Guardrails → Guardrail Providers with the target project selected.
2. In Provider catalog, choose Use this template on Amazon Bedrock Guardrails.
3. Name the provider.
4. Set region, such as us-east-1. endpoint and timeout are optional; the Regions that require an endpoint and the other rules are in Amazon Bedrock Guardrails: configuration and credential.
5. Store the credential in one of two ways:
   • Enter the access key pair under IAM user credentials in the same drawer and save with Enabled on. The Admin Console creates the provider disabled, stores the credential, and then enables it.
   • Clear Enabled, save, and store the credential afterwards, as described in Store the Bedrock credential.

Through the CLI, the provider is created disabled with:

tetrate agentrouter api guardrails providers create \
  --project-id "${PROJECT_ID}" \
  --provider '{"name": "bedrock-guardrails", "kind": "bedrockguardrails", "enabled": false, "config": {"region": "us-east-1"}}'

The response carries the provider's id, which the credential command needs.

Store the Bedrock credential

1. Open the provider under Your Providers.
2. Under IAM user credentials, enter the Access key ID and the Secret access key. Both are required together.
3. Save, then enable the provider.

Through the CLI, the pair is passed as one JSON value:

tetrate agentrouter api guardrails providers set-secret "${PROVIDER_ID}" \
  --project-id "${PROJECT_ID}" \
  --aws-credentials "$(jq -n --arg id "${AWS_ACCESS_KEY_ID}" --arg secret "${AWS_SECRET_ACCESS_KEY}" \
    '{accessKeyId: $id, secretAccessKey: $secret}')"

--api-key is refused for this kind, and --aws-credentials for every other kind. The provider is then enabled with tetrate agentrouter api guardrails providers update, exactly as for an external guardrail service. The command line is visible in the process list while the command runs, so the values are read from the environment, as above, rather than typed.

Everything stated for the Azure credential applies to the pair, which is stored as one value. The gateway signs with this credential alone and never reads AWS credentials from its own environment or the instance metadata service.

Rotate or retire the Bedrock credential

1. Create a second access key for the IAM user in AWS.
2. Store it on the provider, as above. The new pair replaces the old one in place.
3. Allow a few minutes for the gateway's periodic reconcile to deliver it, as described in Configuration propagation.
4. Deactivate the previous key in AWS once traffic is observed succeeding on the new one, then delete it.

There is no operation that clears the credential: it is destroyed by deleting the provider or its project.

Choose how rules map to Bedrock guardrails

A Bedrock rule names one Bedrock guardrail and version, and Bedrock evaluates the whole guardrail on every call: every policy configured on it runs, whatever the rule's Check type says. The check type of a Bedrock rule is therefore a label. It decides how the rule is named in trigger records, metrics, and the Admin Console, and which stages Run on offers, but it never narrows what Bedrock detects. Two approaches follow, and the choice is made in AWS before any rule exists:

Approach	In Bedrock	In Agent Router	Choose it when
One rule per Bedrock guardrail, check type matching its policy (recommended)	One guardrail per kind of content, such as a PII guardrail with only a sensitive information policy, and a content guardrail with only content filters	One rule per Bedrock guardrail, each with the check type that names what its guardrail detects, such as pii and toxicity	Trigger records, metrics, and the Events tab should say what kind of content fired, and each kind needs its own action, mode, or rollout
One rule for one bundled Bedrock guardrail	One guardrail carrying several policies, such as content filters, denied topics, and a sensitive information policy	One rule bound to it. Its check type is information only: pick the one closest to the guardrail's main purpose	The fewest calls to Bedrock matter most, and one action and mode suit every policy in the guardrail

The recommended approach keeps reporting accurate: a pii rule fires only on what the PII guardrail found, so a trigger record says what happened without opening the gateway log. Each kind of content also gets its own action, so a PII guardrail can sit on a redact rule and a content guardrail on a block rule, and each can be moved from monitor to enforce on its own schedule.

The only benefit of the bundled approach is performance: one call to Bedrock per stage instead of one per guardrail. Calls to different Bedrock guardrails are made one after another, so each extra guardrail adds one Bedrock round trip to the request, and each is bounded by the provider's timeout. Bedrock bills each policy by the amount of text it evaluates, so the bundle does not lower the Bedrock cost. In exchange, every trigger record carries the one rule's check type whatever fired, and the Bedrock policy that fired is visible only in the gateway log line.

Two rules bound to the same Bedrock guardrail and version add nothing: within one Agent Router guardrail they share a single call and always fire together. Bind each Bedrock guardrail once. More detail on the trade-off, including how the result of one call is shared, is in Bedrock guardrail layouts.

Create the guardrail and its Bedrock rules

The rules live in an Agent Router guardrail, which holds the settings shared by its rules: the failure mode, the evaluation timeout, and the blocked-response message. The full procedure for guardrails and rules is in Configure guardrails; the Bedrock-specific choices are:

1. Open Policies → Guardrails → Rules and choose Add guardrail.
2. Name the guardrail and set its Failure mode. Under the default, Fail closed, a failed Bedrock call, such as a wrong credential or an unreachable endpoint, blocks every request the guardrail covers; Fail open lets them pass. The setting applies to every rule in the guardrail.
3. Set Evaluation timeout (ms) to cover every Bedrock guardrail the rules bind: the calls run one after another, and a call still running when the evaluation timeout expires fails.
4. Decide what Triggered response a blocked caller sees. The form fills in "This request was blocked by a guardrail policy.", which does not say which guardrail or rule fired; clear the field to return a message that names the guardrail, the rule, and the stage by their identifiers, or enter another message. Placeholders such as {{policy_name}} are not filled in and reach the caller as typed. The message configured on the Bedrock guardrail itself is never returned.
5. Save, then choose Add rule on the new guardrail.
6. Set Provider to the Bedrock provider created in this step.
7. Set Check type as decided in Choose how rules map to Bedrock guardrails. For prompt_injection and jailbreak, Run on offers input only, because Bedrock applies its prompt attack filter to prompts alone.
8. Set Run on to the stages the Bedrock guardrail's policies cover. A rule that runs on input against a guardrail whose policies apply only to responses passes every request.
9. Set Action. Redact replaces the content with Bedrock's masked text, such as {EMAIL}, only where a Bedrock policy masks; where a policy blocks, the request is blocked even on a redact rule. Block blocks on anything Bedrock reports, including a detect-only finding and content Bedrock would only have masked. The full table is in How a Bedrock result combines with the rule.
10. Set Mode to monitor for the first rollout, as described in the next section.
11. Under Configuration, enter the Guardrail ID or ARN: the guardrail ID shown on the guardrail's page in the Amazon Bedrock console, or its full ARN. The guardrail must be in the provider's Region.
12. Enter the Version: a published version number, such as 1, or DRAFT. Production rules use a numbered version, because DRAFT follows every edit made to the guardrail in AWS; saving a DRAFT rule shows a warning that says so. More detail is in Bedrock guardrail versions.
13. Choose Add rule. Repeat for each further Bedrock guardrail.
14. Turn the guardrail on with its On switch in the Rules list, if it is off.

The rule's threshold has no effect on this kind: Bedrock has already applied each filter's strength, so sensitivity is tuned in Bedrock. A save is refused while a data plane serving the project runs a build older than 0.11.0, with a message naming the data plane.

Through the API or the CLI, the rule carries its binding in the bedrockGuardrail configuration, as guardrailIdentifier and guardrailVersion. The Bedrock-specific fields of a rule body, beside its guardrail ID and name:

{
  "providerId": "<provider id>",
  "checkType": "CHECK_TYPE_PII",
  "executeOn": "EXECUTE_ON_INPUT",
  "action": "RULE_ACTION_REDACT",
  "mode": "RULE_MODE_MONITOR",
  "configuration": {
    "bedrockGuardrail": {
      "guardrailIdentifier": "gr4ab1cd2ef3",
      "guardrailVersion": "1"
    }
  }
}

Roll out the Bedrock rule in monitor mode first

Because nothing is verified when the provider or a rule is saved, a wrong guardrail ID, version, Region, or credential first appears on live traffic. Under the default fail-close failure mode, that blocks every request the rule covers.

1. Create the rule in monitor mode.
2. Send a request through the project gateway that the Bedrock guardrail is known to act on, and require a trigger record for the rule on Policies → Guardrails → Rules → Events.
3. Watch tars.guardrails.evaluations with error.type=provider_error for the Agent Router guardrail that holds the rule. It stays at zero on a healthy provider.
4. Switch the rule to enforce.

A monitor rule never blocks on a provider error and records no trigger for one, so clean-looking traffic in monitor mode proves nothing until the known-positive request has produced a trigger record. The proxy log line and the metric that expose a failing provider are described in Connect an external guardrail service, and apply to this kind unchanged. When a call fails, the causes of each Bedrock error are listed in Bedrock error messages.

Step 9: confirm which provider supports which check type

A rule is valid only if its provider supports its check type. The Admin Console scopes 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, with the cases that most often surprise, is in the guardrails reference.

---

Where to go next

Configure guardrails

Create policies and rules that reference these providers.

Guardrails best practices and FAQ

Roll out safely with monitor mode and deliberate failure modes.

Protect requests with guardrails

The developer-side view of how blocks and redactions appear.

Configuration propagation

How long a provider change takes to reach the gateway, and what a credential change does to it.