Guardrails

Guardrails in Agent Router Enterprise run inline in the gateway data plane as a dynamic module, inspecting the prompt on its way to a model provider and the response on its way back. A guardrail is a project-scoped policy: a set of rules, each pairing a check type (what to detect) with a guardrail provider (how it is detected) and a stage (where on the request path it runs).

---

Where guardrails run

Evaluation happens in process, with no sidecar and no extra network hop. Every model request that crosses the gateway is inspected on the way in and on the way out.

Guardrails inspect large language model (LLM) traffic. Model Context Protocol (MCP) traffic is also proxied by the gateway, but standalone MCP profile requests do not pass through content guardrails; they are governed by identity, access control, and audit. See Guardrails for the request-path detail.

Running at the gateway rather than in application code has two consequences:

• Centralized governance: one policy protects every application in the project, with no per-application safety code and no software development kit (SDK) integration.
• Cost at the edge: a prompt blocked at the gateway never reaches the model provider, so no charge is incurred for a call that would have failed policy.

The core design split drives everything below:

• A check type states what to look for (personally identifiable information, jailbreak, toxicity, and others). There are 23.
• A guardrail provider states how it is detected (regular expression engine, keyword pipeline, machine-learning classifiers, external service). There are six provider kinds.
• A stage states where on the request path the rule runs: input, output, or both.
• Any check type can in principle be served by different providers, so the cost and accuracy point is selected per rule. Providers score, the gateway decides: a provider returns a normalized score between 0.0 and 1.0, and the gateway compares it to the rule's threshold and applies the action.
• Not every combination of the three is implemented. The capability matrix is the authority, and the API validates every rule against it at write time.

Anatomy of a guardrail

A guardrail is a named, project-scoped policy: a collection of rules plus shared settings. A rule is one check type, one provider, an action, a mode, and a stage.

Guardrail-level settings

Setting	Values	Meaning
Type	compliance, security, policy, quality, custom, evaluator	What class of concern the guardrail addresses
Severity	low, medium, high, critical	Operational severity of a trigger
Category	data_privacy, financial, healthcare, government, custom	Domain grouping
Failure mode	fail_close (default), fail_open	If evaluation itself fails (provider down, timeout): fail-close blocks the request, fail-open lets it pass. The setting is per path: fail-close where safety dominates, fail-open where availability dominates
Evaluation timeout	milliseconds	Per-guardrail evaluation budget (the built-in templates use 3000 to 5000 ms)
Triggered response	message	What the caller sees when a rule blocks. A rule's own message takes precedence over its guardrail's; with neither set, the message names the guardrail, the rule, and the stage by their identifiers. The text is returned as written: placeholders such as {{policy_name}} are not substituted

Rule-level settings

Setting	Values	Meaning
Check type	one of the 23 listed below	What to detect
Provider	one of the configured provider instances	The guardrail provider that scores the content
Action	block, redact	Block stops the request with HTTP 400 and the code content_policy_violation, plus an optional message; the X-Request-ID response header identifies it for investigation (see A guardrail block). Redact masks the matched content (for example [CREDENTIAL_REDACTED]) and lets the request continue
Mode	enforce, monitor	Enforce applies the action. Monitor is shadow mode: it records what would have happened and passes content unchanged, which surfaces trigger and false-positive rates on live traffic before enforcement. Monitor rules never break the request flow and are always effectively fail-open
Stage	input, output, or both	Run against the prompt, the response, or both. Labeled Run on in the Admin Console and execute_on in the API. Leaving it unset requests both stages, so a check supported on only one stage must have the stage set explicitly or the write is rejected
Content type	all, text, image, document, tool, thinking, context	Which kind of content an evaluation ran against. Carried on the evaluation and on the resulting trigger record, not set on the rule in the Admin Console
Target	project	Rules apply to the guardrail's whole project
Threshold	0.0 to 1.0	Violation sensitivity: the gateway flags a violation when the provider score is at or above the threshold (deterministic engines score 1.0 or 0.0)

Streaming behavior

• If every rule on a stage is monitor mode, evaluation is asynchronous and streaming is unaffected.
• If any rule on the output stage enforces, the response is buffered for evaluation before delivery, so enforcing output guardrails de-stream the response. This is a deliberate correctness trade-off; the operational implications are covered in Guardrails best practices and FAQ.
• Buffering follows the mode, not the action. Both actions buffer when the rule enforces: redact has to rewrite content it has already seen, so it de-streams a response exactly as block does. Choosing redact over block changes what the caller receives, never whether the response streams.
• Enforcement on the input stage leaves streaming intact. Input rules run before the request is forwarded, so their cost lands on time-to-first-token rather than on the stream, which makes enforce-on-input with monitor-on-output the combination that polices prompts while keeping responses streaming.
• A blocked response is returned as a structured HTTP 400 error body, not as a dropped or truncated stream, precisely because the response was buffered before the violation was found. See Streaming behavior.

Check types

23 check types, in four groups. Each name below is the value used in the Admin Console; the corresponding API constant is CHECK_TYPE_ followed by the upper-cased name, so pii is CHECK_TYPE_PII and factual_consistency is CHECK_TYPE_FACTUAL_CONSISTENCY.

Privacy and secrets

Check type	Detects
pii	Personally identifiable information: names, emails, phone numbers, national identifiers, payment cards, IBANs, and similar
secrets	Credentials and API keys (AWS, GitHub, Slack, generic API keys, and others)
protected_material	Copyrighted or otherwise protected content in outputs

Security

Check type	Detects
prompt_injection	Instructions smuggled into prompts or context to subvert the model, including system-prompt extraction and data exfiltration
jailbreak	Direct "ignore previous instructions" and role-play attacks in the user's own prompt
ban_code	Executable or malicious code in prompts or responses, including SQL injection payloads, detected by denylist and pattern. Available on the deterministic engines only
code	Executable or malicious code, additionally available on the tetrate classifier

Content safety

Check type	Detects
toxicity	Toxic, profane, abusive language
hate_speech	Hate speech targeting protected groups
sexual_content	Sexual content, including child-safety violations
violence	Violent content and threats
self_harm	Self-harm and suicide-related content
bias	Biased or discriminatory language (gender, age, disability, and others)

Policy, quality, and control

Check type	Detects
compliance	Regulation-specific prohibited practices (see the compliance templates below)
banned_topics	Configurable off-limits subject matter (for example medical, legal, or financial advice)
ban_competitors	Competitor names, recommendations, and comparisons
banned_substrings	Literal string denylists
regexp	Arbitrary custom patterns from the shared Patterns catalog
language	Language allow and deny lists (28 languages)
gibberish	Nonsense or garbled input
sentiment	Negative-sentiment content
relevance	Response relevance to the prompt
factual_consistency	Groundedness of a response against source material

Guardrail providers

Six provider kinds, compared by mechanism, deployment, and cost:

Provider kind	Detection mechanism	ML-based?	Where it runs	Data leaves the customer environment?	Latency and cost profile
regexp	RE2 pattern matching against a named, reusable Patterns catalog (custom patterns supported)	No, deterministic	In process, inside the gateway	No	Near zero, free (about 0 ms)
builtin	Five-layer keyword and regex pipeline: blocked keywords, then an allowlist gate, then subject and term co-occurrence within a sentence, then detection patterns, then category keywords, severity-banded	No, deterministic	In process, inside the gateway	No	Near zero, free (sub-millisecond)
tetrate	Tetrate Semantic Router: an embedding model plus task-specific small-model classifiers, comprising a domain classifier (violence, self-harm, hate speech, sexual content, weapons, crime), a PII classifier, a jailbreak classifier, a natural language inference (NLI) entailment fallback (ModernBERT class), a gibberish detector, and language identification. Cascading evaluation: local known patterns, then the ML classifier, then the NLI fallback, short-circuiting at the first firing layer	Yes, small-language-model and classifier based	In the customer cluster: a Helm-deployed workload in the customer data plane; CPU inference, no GPU required	No, the callout stays inside the customer network	Slower: in-cluster network hop plus inference, typically 40 to 120 ms; compute cost is the customer's own cluster capacity
azurecontentsafety	Azure AI Content Safety REST API: text analysis (hate, sexual, violence, and self-harm severity), Prompt Shields (jailbreak), protected-material detection, groundedness detection	Yes, hosted ML	Third-party SaaS (Microsoft)	Yes, content is sent to Azure	Slowest and metered: external network round trip (about 200 ms class) plus per-call vendor pricing
bedrockguardrails	Amazon Bedrock ApplyGuardrail against a guardrail defined in the customer's AWS account: content filters, denied topics, word filters, and sensitive-information filters, as configured in AWS	Yes, hosted ML	Third-party SaaS (AWS)	Yes, content is sent to Amazon Bedrock in the provider's AWS Region	Slowest and metered: external network round trip plus per-policy AWS pricing
externalservice	Generic HTTP callout to any guardrail service the customer runs or subscribes to; its supported checks are declared per instance	Depends on the service	Wherever it is pointed	Yes, to that endpoint	Depends on the service

Provider availability and evaluation order

• Providers are owned by a project (since 0.4.0). A provider is an instance with its own identifier, and only an instance the project owns can be referenced by one of its rules. Those instances are editable like any other row, so one kind can be configured differently from project to project.
• All six kinds also exist as catalog templates: regexp, builtin, tetrate, azurecontentsafety, bedrockguardrails, and externalservice. A template is global, read-only, and not usable by a rule. It holds a starting configuration that an operator copies into a project to create an instance. The previously shared, deployment-wide regexp, builtin, and tetrate rows became these templates. The externalservice template, External guardrail service, carries an empty configuration: every connection setting is supplied when the instance is created.
• A newly created project owns a regexp, a builtin, and a tetrate provider, copied from those templates when the project is created. azurecontentsafety and bedrockguardrails are not among them, because neither can evaluate anything without a credential; each stays a template until an operator creates an instance and configures one. externalservice instances are likewise created deliberately.
• A rule binds only to an enabled provider its own project owns. An identifier naming another project's provider, a catalog template, or nothing at all is refused identically, so provider identifiers cannot be probed across projects; a disabled provider is refused separately, with an error saying it is disabled. A provider that is disabled after its rules exist is skipped at evaluation, and the rules bound to it stop enforcing. Listing a project's providers returns the project's own rows unless templates are asked for, and reading providers requires the guardrail_providers.read permission or a scope that grants guardrail reads.
• A provider's credential is never part of its configuration. It enters through the write-only SetGuardrailProviderSecret call, is stored encrypted, and is returned by no read: a provider reports whether a credential is stored, not what it is. Calling the operation again rotates the credential in place, and deleting the provider or its project destroys it. Creating or updating a provider with a credential inside the configuration is refused with an error naming the operation.
• The kinds form a cost and capability ladder: deterministic engines catch known formats and phrasings for free, ML engines catch paraphrase, novel phrasing, and semantic evasion at a latency and compute cost, and third-party engines add vendor capabilities at per-call prices and a data-egress trade-off.
• Cheap-decisive-first ordering: the gateway hoists enforced block rules on the in-process engines ahead of everything else, so a local pattern hit short-circuits evaluation before any remote or ML call runs. ML latency and vendor fees are not incurred for requests a regular expression would have blocked anyway.
• One call per guardrail, per stage, per provider, per string: the rules of one guardrail that share a provider cost one evaluation call on each stage, not one per rule, and two guardrails on the same provider cost two. An externalservice provider takes every string of the request in one call instead, plus one call per item after a redaction. Results are cached per content snapshot and invalidated only when a redaction rewrites the content.
• Some combinations of check type, provider, and stage are not implemented, and are restricted by the capability matrix below.

Provider support by check type

A rule is valid only if its provider kind supports its check type on the stage the rule requests. The constraint is enforced at write time, not at request time, and the Admin Console mirrors it by scoping the check-type dropdown to the selected provider.

Each cell gives the stages the (provider kind, check type) pair supports:

• Both: the check runs on input, output, or both, so the stage may be left unset.
• Input only or Output only: the check runs on that stage alone. Because an unset stage requests both, such a rule must set Run on explicitly or it is rejected.
• No: the provider kind does not implement the check, and rules combining them are rejected.

The five kinds with fixed capabilities are shown. externalservice declares its capabilities per instance and is covered below.

Check type	regexp	builtin	tetrate	azurecontentsafety	bedrockguardrails	tetrate detection mechanism
ban_code	Both	Both	No	No	No	Not supported
ban_competitors	Both	Both	No	No	No	Not supported
banned_substrings	Both	Both	Both	No	Both	Keyword signal
banned_topics	Both	Both	Both	No	Both	NLI entailment
bias	Both	Both	Output only	No	No	NLI entailment
code	Both	Both	Both	No	No	Classifier
compliance	Both	Both	No	No	No	Not supported
factual_consistency	Both	No	No	Output only	No	Not supported
gibberish	Both	No	Both	No	No	NLI or classifier
hate_speech	Both	Both	Both	Both	Both	Signal evaluation
jailbreak	Both	Both	Input only	Input only	Input only	Security classifier, with NLI fallback
language	Both	Both	Both	No	No	Language signal
pii	Both	Both	Both	No	Both	PII model, returning entities and masked text
prompt_injection	Both	Both	Input only	Input only	Input only	Known patterns, then classifier, then NLI
protected_material	Both	Both	No	Both	No	Not supported
regexp	Both	Both	Both	No	Both	Catalog regex signal
relevance	Both	No	Output only	No	No	NLI against the original prompt
secrets	Both	Both	Input only	No	Both	Keyword signal
self_harm	Both	Both	Both	Both	No	Signal evaluation
sentiment	Both	No	Both	No	No	NLI entailment
sexual_content	Both	Both	Both	Both	Both	Signal evaluation
toxicity	Both	Both	Both	Both	Both	Signal evaluation (violence and hate)
violence	Both	Both	Both	Both	Both	Signal evaluation

Six qualifications apply when reading the table:

• regexp accepts every check type on both stages only because a regular expression is check-type-agnostic. The check type is a label, and the referenced patterns are the real definition, so a pii rule and a secrets rule on this provider behave identically given identical patterns.
• builtin runs its keyword and regex pipeline on both stages for every check it supports. It does not implement the meaning-based checks (gibberish, relevance, sentiment) or factual_consistency.
• tetrate carries stage limits on five checks: prompt_injection, jailbreak, and secrets on input only, bias and relevance on output only.
• azurecontentsafety covers the nine checks shown, with prompt_injection and jailbreak on input only and factual_consistency (groundedness) on output only.
• bedrockguardrails covers the eleven checks shown, with prompt_injection and jailbreak on input only. The set is fixed per kind, but the check type is a label: the bound Bedrock guardrail decides what is detected, and every rule bound to the same guardrail and version receives the same result. Contextual grounding is not supported, so neither factual_consistency nor relevance is offered.
• factual_consistency is therefore not available on any in-cluster provider except nominally through regexp. Groundedness checking requires azurecontentsafety or an external service that implements it.

The table is derived from the canonical capability declaration that the API validates against and the Admin Console uses to scope its forms. Where this page and the product disagree, the API's error message is authoritative.

Azure AI Content Safety: configuration and credential

An azurecontentsafety provider is configured with four settings. Only the endpoint is required; each of the other three is applied at its default when left blank.

Setting	Required	Default	Description
endpoint	Yes	none	The Azure resource endpoint, as an absolute http or https URL, for example https://<resource>.cognitiveservices.azure.com. A value with no scheme is rejected at write time. A trailing slash is stripped; a path segment is accepted and then prefixed onto every Azure request, which fails at call time rather than at write time
api_version	No	2024-09-01	The Azure API version for severity analysis, Prompt Shields, and protected-material detection. Passed through unvalidated
groundedness_api_version	No	2024-09-15-preview	The Azure API version for groundedness detection, which Azure versions separately. Passed through unvalidated
timeout	No	10s	Per-request budget for the call to Azure, written as a duration such as 10s, 1500ms, or 1m30s. A bare number is not a duration. The value is not validated at write time, and the gateway cannot build a provider whose timeout it cannot parse, so a malformed one leaves every rule bound to that provider evaluating nothing

The credential is not one of these settings and is never part of a provider's configuration:

• It is set through a dedicated write-only operation, a POST to the provider's secret sub-resource, which is the only way a credential enters. The equivalent command is tetrate agentrouter api guardrails providers set-secret.
• A configuration carrying one is rejected. A create or update that places api_key in an azurecontentsafety provider's configuration, or auth_token in an externalservice provider's, fails with an invalid-argument error naming the credential operation. Nothing is silently consumed and nothing is silently discarded.
• No read returns it. Listing providers, reading one, and the configuration delivered to the data plane all omit it. A read reports whether a credential is stored, never its value.
• Calling the operation again rotates in place. The provider keeps its identifier, its configuration, and every rule bound to it. The operation is audit-logged, recording who set a credential on which provider and never the value.
• There is no operation that clears one. A stored credential is destroyed by deleting the provider or the project that owns it.
• A template holds none. The operation is refused on a catalog template, which is read-only.
• It is encrypted at rest, and the provider row keeps only a reference to it. Editing the provider's name or configuration leaves the stored credential in place.
• It reaches the gateway outside the configuration, as a mounted Kubernetes Secret, so it appears in no ConfigMap and in no proxy configuration dump.

A provider of this kind cannot evaluate anything without a stored credential, and a rule cannot be bound to a disabled provider. A guardrail created from a template is refused where the provider of the kind it needs is disabled.

The guardrail's own evaluation timeout and failure mode apply on top of the provider timeout. With the default fail-close failure mode, an Azure resource that is throttling or unreachable blocks the traffic the rule governs.

An Azure AI Content Safety resource issues two keys, so one can be rotated while the other serves. The new key travels on the gateway's periodic reconcile, so the previous key stays valid until traffic is observed succeeding on the new one.

How the credential reaches the gateway, and what a rotation costs in propagation time, is described in Configuration propagation.

Amazon Bedrock Guardrails: configuration and credential

A bedrockguardrails provider is configured with three settings, and the configuration accepts no other key; key names are case-sensitive. Only the Region is required. No call is made to AWS when a provider is written. The Bedrock guardrail and its version are set on each rule, not on the provider.

Setting	Required	Default	Description
region	Yes	none	The AWS Region of the guardrails, such as us-east-1 or us-gov-west-1: lowercase words joined by hyphens, ending in a number. Requests are signed for this Region unless the endpoint's hostname names a Bedrock Region (the public, FIPS, VPC endpoint vpce-…, and api.aws hostnames do), in which case they are signed for that one
endpoint	No	https://bedrock-runtime.<region>.amazonaws.com	An absolute http or https URL with a host replacing the Regional endpoint, for a VPC interface endpoint or a FIPS endpoint. It carries no userinfo, query, fragment, or trailing slash, and cannot name a link-local or cloud-metadata address. Required for a Region whose name starts with cn-, eusc-, us-iso-, us-isob-, us-isof-, or eu-isoe-
timeout	No	10s	Budget for each call to Bedrock, written as a duration greater than 0s such as 10s or 1500ms, with no upper limit. Calls are not retried, and every call also stops at the Agent Router guardrail's evaluation timeout

Each rule on the provider carries a bedrockGuardrail configuration with two required fields:

Field	Description
guardrailIdentifier	The guardrail ID, such as gr4ab1cd2ef3, or the guardrail ARN, at most 2,048 characters. An ARN naming another Region than the provider's is accepted on write and fails when the rule runs
guardrailVersion	A positive whole number of up to eight digits, or DRAFT. DRAFT is accepted with a warning, because it follows every edit made to the guardrail in AWS. Every create or update of a rule whose stored version is DRAFT, renames included, returns in its warnings field: "the rule is bound to the DRAFT version of Bedrock guardrail "<id>", which changes whenever someone edits the guardrail in AWS; bind a numbered version in production". The Admin Console warns when DRAFT is chosen

The credential is an IAM user's access key ID and secret access key, set as one value through the same write-only operation as other provider credentials, in its aws_credentials field; the equivalent command is tetrate agentrouter api guardrails providers set-secret with --aws-credentials. The aws_credentials value carries access_key_id and secret_access_key, both required; there is no session token field, and IAM roles and IRSA are not supported. Both halves are stored together as one encrypted value, in the same store as an API key, and the gateway receives it unchanged as the provider's mounted credential file. Everything stated above for the Azure credential applies: it is returned by no read, audit-logged without its value, rotated in place, and destroyed only with its provider or project, and has_api_key reports true once it is stored. The gateway signs each call with Signature Version 4 using that credential alone, and never falls back to credentials from its own environment or the instance metadata service.

Bedrock prerequisites and IAM policy

Each prerequisite is required. The guardrail ID, version, and credential are not checked against AWS when the provider or a rule is saved, so a gap first shows up on live traffic.

• A Bedrock guardrail with a published version, created in the Region the provider names. Rules accept the working draft (DRAFT) too; see Bedrock guardrail versions.

• An IAM user with a long-term access key. IAM roles, IAM Roles for Service Accounts (IRSA), EKS Pod Identity, and temporary credentials with a session token are not supported: temporary credentials expire within hours and the gateway has no way to refresh them. The user needs only bedrock:ApplyGuardrail, on the ARN of every guardrail the project's rules reference:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "bedrock:ApplyGuardrail",
        "Resource": [
          "arn:aws:bedrock:us-east-1:111122223333:guardrail/abcd1234efgh",
          "arn:aws:bedrock:us-east-1:111122223333:guardrail/ijkl5678mnop"
        ]
      }
    ]
  }

• Every data plane that serves the project at 0.11.0 or later. An earlier data plane does not recognize the kind and drops its rules, even under fail-close, so a Bedrock rule would silently not run there. The write-time check is in Write-time validation. It runs only when a rule is written, so a data plane attached later to a project that already has Bedrock rules is not checked. A project with no serving data plane is not checked, and neither are provider writes or a rename or deactivation of a rule. A rule at organization scope is checked against the organization's data planes.

• A network path from the data plane to Bedrock. The gateway calls https://bedrock-runtime.<region>.amazonaws.com on port 443 unless the provider names another endpoint. A VPC interface endpoint (AWS PrivateLink) is set as the provider's endpoint, and no other setting changes: when the endpoint's hostname names a Bedrock Region, as the public, FIPS, VPC endpoint (vpce-…), and api.aws hostnames do, requests are signed for that Region, and otherwise for the provider's region. A Region whose name starts with cn-, eusc-, us-iso-, us-isob-, us-isof-, or eu-isoe- is outside the amazonaws.com domain the default endpoint is built on, so its provider is refused without endpoint. On a self-hosted data plane with the egress NetworkPolicy enabled, a VPC endpoint resolves to a private address that the policy refuses, which looks like a timeout. The endpoint subnet's CIDR and port 443 are added to egressResources.egress.networkPolicy.extraEgress.

Contextual grounding checks are not supported: Bedrock needs the source document that the answer should be grounded in, and the gateway does not have it. A guardrail that carries a contextual grounding policy can still be used, but that policy never runs.

How a Bedrock result combines with the rule

The provider sends one ApplyGuardrail call per distinct guardrail and version among its rules, per stage, per string, with the source set to INPUT on the input stage and OUTPUT on the output stage. Bedrock decides what counts as a detection. Most Bedrock filters return no numeric score, and Bedrock has already applied its own filter strength, so the provider scores any detection or intervention as 1.0 and a clean result as 0.0, for every rule bound to that guardrail and version. The rule's threshold therefore has no effect on this kind. Sensitivity is tuned in Bedrock, through each filter's strength and action.

What reaches the application depends on what the guardrail did and on the rule's action and mode:

Bedrock guardrail outcome	Block rule, enforce	Redact rule, enforce	Either rule, monitor
Nothing detected	Passes	Passes	Nothing recorded
Detected by a detect-only filter (action None in Bedrock)	Blocked	Recorded; the content passes unchanged	Recorded
Masked (action Mask)	Blocked	Bedrock's masked text replaces the content	Recorded
Blocked (action Block)	Blocked	Blocked, and recorded as a block	Recorded
Call failed (error or timeout)	Per the Agent Router guardrail's failure mode	Per the Agent Router guardrail's failure mode	Passes

Four consequences follow from the table:

• A detect-only filter is still reported, so a Bedrock guardrail with no blocking actions can be enforced by a block rule, or recorded by a monitor rule.
• A redact rule redacts only what Bedrock masked. Masked text carries Bedrock's placeholders, such as {EMAIL}. A detect-only finding on a redact rule is recorded and nothing is changed.
• A block in Bedrock always blocks: a redact rule meeting a guardrail that blocked is escalated to a block, and the trigger record and metrics show a block. Where a guardrail both blocks and masks the same content, Bedrock reports a block.
• A block rule blocks what Bedrock would only have masked.

A blocked request returns the blocked-response message of the rule or of its Agent Router guardrail, not the blocked message configured on the Bedrock guardrail; with neither set, the message names the guardrail, the rule, and the stage. A response Bedrock marks as an intervention without saying whether it blocked or masked, or a masked response with no masked text, is treated as a block. Failure modes behave as for Azure AI Content Safety, and responses are buffered and checked once complete, as for every provider.

Each call to Bedrock is bounded by the provider's timeout, 10 seconds by default, and is never retried. Rules bound to several distinct Bedrock guardrails make one call per guardrail, one after another: two guardrails can take up to twice the provider timeout. The Agent Router guardrail's evaluation timeout, when set, bounds all of those calls together, and a call still running when it expires fails. A failed call, including a throttled one, is a provider error and follows the Agent Router guardrail's failure mode.

A filter that is switched off for prompts or for responses in Bedrock produces nothing on that side. A rule that runs on input against a guardrail whose policies apply only to responses passes every request.

Trigger records and metrics name the guardrail rule and its check type, not the Bedrock policy that fired. The gateway log carries one line per call in which Bedrock reported anything, with the provider ID, the request ID, the stage, the rule IDs, the guardrail ID and version, Bedrock's action and action reason, and each finding as policy, type, and action, for example contentPolicy:INSULTS:BLOCKED. A failed call logs one warning line with the same identifiers and the error. Neither line ever carries the evaluated content, a matched value, or masked text.

Bedrock guardrail layouts

A Bedrock rule is bound to one Bedrock guardrail and version, and the whole Bedrock guardrail is evaluated on every call: each policy configured on it runs, whatever the rule's check type. The check type of a Bedrock rule is therefore a label. It names the rule in trigger records, metrics, and the Admin Console, and sets which stages the rule may run on, but it never narrows what Bedrock detects.

Within one Agent Router guardrail, rules bound to the same Bedrock guardrail and version share one call and receive the same result, so they always fire together. Rules bound to different Bedrock guardrails make one call each, one after another. Rules in different Agent Router guardrails are evaluated separately, even when they name the same Bedrock guardrail.

Two layouts follow:

Layout	Calls to Bedrock per stage and string	What a trigger record says	Actions and modes
One Bedrock guardrail per kind of content, each on its own rule whose check type matches it (a PII guardrail on a pii rule, a content-filter guardrail on a toxicity rule). Recommended	One per Bedrock guardrail	The check type names the kind of content that fired	Set per kind: a PII guardrail can redact while a content guardrail blocks, each rolled out on its own
One bundled Bedrock guardrail carrying every policy, on a single rule	One	The check type is information only; the policy that fired is in the gateway log line	One action and one mode for every policy in the guardrail

The bundled layout's only advantage is performance: fewer sequential round trips to Bedrock, each bounded by the provider's timeout. It does not lower the Bedrock cost, because Bedrock bills each configured policy by the amount of text it evaluates in both layouts.

Bedrock guardrail versions

A rule names a version as a positive whole number of up to eight digits, such as 3, or as DRAFT, in capitals.

• A numbered version is an immutable snapshot. A rule bound to it behaves the same until the rule is changed. A numbered version is the form suited to production.
• DRAFT is the working copy. An edit to the guardrail in AWS changes what a DRAFT rule enforces on the next request, with no change in Agent Router. The Admin Console shows a warning when it is chosen, and every create or update of a rule bound to DRAFT returns a warning in the response's warnings field.

To roll a change forward, a new version is published in Bedrock and the rule is updated to it. Pointing the rule back at the previous version rolls it back.

Bedrock rotation

An IAM user can hold two access keys at once, so a new pair can be stored while the previous one stays active in AWS. The new pair replaces the old one in place and reaches the gateway on its periodic reconcile. No operation clears a credential and leaves the provider behind.

Bedrock error messages

Calls are not retried. The error in the gateway log for a failed call carries the HTTP status, Bedrock's error type, and its message, for example status 400 ValidationException: The guardrail identifier or version provided in the request does not exist. The common causes:

Bedrock error	Cause
ValidationException, "The guardrail identifier or version provided in the request does not exist."	The guardrail ID or version is wrong, or the guardrail is in another Region than the provider
ValidationException, "Guardrail was enabled but input is in incorrect format."	The rule names a guardrail ARN from another Region
UnrecognizedClientException (status 403)	The access key ID is unknown, for example deleted or mistyped
InvalidSignatureException (status 403)	The secret access key does not belong to the access key ID
AccessDeniedException (status 403)	The IAM policy does not grant bedrock:ApplyGuardrail on that guardrail's ARN
ThrottlingException (status 429)	Either the account's request rate quota, or content larger than a Bedrock policy accepts in one call; the message says which
A timeout or a refused connection, naming the address dialled	The data plane cannot reach the endpoint, often the egress NetworkPolicy in front of a VPC endpoint

The setup procedure is in Configure guardrail providers.

External guardrail services: per-instance capabilities

An externalservice provider wraps a remote guardrail service the customer operates. Its capabilities are declared per instance, not per kind:

• Checks are declared in the provider instance's configuration as a list of canonical check names. A rule write against that provider is validated against the instance's declared list rather than against a kind-wide set.
• Stages are unrestricted at write time. The gateway forwards the stage to the remote service, which decides what it evaluates.

The service implements the version 1 service contract: the gateway sends one POST carrying the stage, a list of checks, and a list of content items, and the service answers with exactly one result per pair of check and item, a score between 0.0 and 1.0 or a statement that the pair was skipped. The contract has no verdict field, because providers score and the gateway decides. Any answer other than HTTP 200 with a well-formed body is an evaluation failure, handled by the guardrail's failure mode. A vendor product that does not implement the contract natively is reached through an adapter that does.

Provider creation enforces the declaration: an externalservice provider with no valid, non-empty check list, drawn from the check-type vocabulary above, is rejected.

The service only ever sees content as it stands after every earlier rule: content an earlier rule blocked is never sent, and content an earlier rule redacted is sent masked. At the output stage the request also carries the user's prompt when the gateway has it, in the form the model received, so a service bound only to output-stage rules still receives the prompt. The wire format is the guardrail service contract, and the provider is set up by following Connect an external guardrail service.

Write-time validation

Creating or updating a guardrail rule or provider is validated against the matrix. Most rejections are an invalid-argument error naming the supported set. Four are not, and automation that branches on the code should expect them: a rule naming a provider that is a template, belongs to another project, does not exist, or is disabled is a failed-precondition, and so is a rule on a bedrockguardrails provider refused by the data plane version check; setting a credential on a catalog template is a permission-denied. The version check also fails as unavailable when the data planes it needs cannot be listed.

Write	Rejected when
Create or update a rule	The check type is not supported by the provider's kind or, for externalservice, is absent from the instance's declared check list. The error lists the checks the provider does support
Create or update a rule	The requested stage, where unset means both, falls outside the (kind, check) pair's supported stages. The error names the supported stages
Create or update a rule	The referenced provider's kind is unknown
Create or update a rule	The referenced provider is a catalog template, belongs to another project, or does not exist. All three are refused identically, stating the provider is not available in this project
Create or update a rule	The referenced provider is disabled
Create a provider	The kind is missing, or names no engine the data plane implements. The error lists the accepted set, which is the authority: it is a superset of the six kinds documented above, because it also carries engines that are present in the data plane but not offered. The kind is fixed at creation and cannot be changed afterwards
Create or update a provider	The configuration carries a credential for the kind: api_key on azurecontentsafety, access_key_id, secret_access_key, or session_token in any spelling on bedrockguardrails, auth_token on externalservice. The error names the credential operation to use instead
Create or update a provider	The configuration carries the key the data plane reads the credential file from: api_key_file on azurecontentsafety, credentials_file on bedrockguardrails, auth_token_file on externalservice. Only the management plane sets it; the error names the credential operation to use instead
Create or update an azurecontentsafety provider	The configuration's endpoint is missing, empty, or is not an absolute http or https URL. The error names the expected shape
Create or update a bedrockguardrails provider	region is missing or is not an AWS Region name; endpoint is empty, is not an absolute http or https URL with a host, carries userinfo, a query, a fragment, or a trailing slash, or names a link-local or cloud-metadata address; endpoint is absent for a cn-, eusc-, us-iso-, us-isob-, us-isof-, or eu-isoe- Region; timeout is not a duration or is not greater than 0s; the configuration carries a key outside region, endpoint, and timeout; or a value is not a string ("bedrockguardrails config <key>: must be a string, got <type>"). Each error names the key and the expected shape
Create or update an externalservice provider	The configuration's check list is missing, empty, or contains names outside the canonical check vocabulary
Create or update an externalservice provider	The configuration carries a key outside service_url, checks, endpoint, timeout, ca_cert_pem, and name, or a value other than checks that is not a string
Create or update an externalservice provider	service_url is missing, is not an absolute http or https URL, carries userinfo, a query, a fragment, or a trailing slash, or names a link-local or cloud-metadata address
Create or update an externalservice provider	endpoint is blank or does not start with /; timeout is blank, is not a duration, or is not greater than 0s and at most 30s. To take the default, leave the key out
Create or update an externalservice provider	ca_cert_pem is empty, is larger than 8 KiB, holds more than 4 certificates, or holds anything other than plain CERTIFICATE blocks. The error never repeats the value
Create or update a rule on an externalservice provider	The raw configuration's threshold is not a number, or is not greater than 0 and at most 1
Create or update a rule on a bedrockguardrails provider	The bedrockGuardrail configuration is missing, guardrailIdentifier is empty, longer than 2,048 characters, or neither a lowercase alphanumeric ID nor a Bedrock guardrail ARN, or guardrailVersion is neither a positive whole number of up to eight digits nor DRAFT
Create or update a rule on any other provider	The configuration carries the bedrockGuardrail variant, which only bedrockguardrails accepts. The error names the variant, the kind it requires, and the rule's provider kind
Create a rule on a bedrockguardrails provider, update one so that its provider or configuration changes, or turn an inactive one on	A data plane serving the project, or for an organization rule one of the organization's data planes, has not reported its build recently, reports a build that cannot be read, or runs a build older than 0.11.0. A failed-precondition naming the data plane, for example "data plane <id> runs <version>, and Amazon Bedrock Guardrails rules need 0.11.0 or newer: an older build drops them without enforcing them, so upgrade it first". A project with no serving data plane passes. When the data planes cannot be listed, the write fails as unavailable
Create or update a rule	The configuration uses the deprecated externalService variant, for any provider kind. A stored rule that carries it stays editable as long as the write does not send it back; per-check parameters belong in the raw configuration
Set a credential	The target is a catalog template, which is read-only, or its kind takes no credential
Set a credential	The credential's shape does not match the kind: aws_credentials on any kind other than bedrockguardrails, api_key on bedrockguardrails, or an aws_credentials missing either half ("aws_credentials requires both access_key_id and secret_access_key"). Sending both api_key and aws_credentials, or neither, is refused too

Updates re-validate whenever the provider, check type, stage, or configuration changes. Edits confined to unrelated fields (name, description, active) do not re-trigger validation, which is what keeps legacy rules editable. The credential check is the exception: every update that carries a configuration is screened for a credential key, whether or not the configuration changed.

Because the Admin Console scopes the rule form to the same matrix, these rejections surface mainly through direct API use and automation, where the error fails an apply fast instead of shipping a rule that can never fire.

Troubleshooting: rules that never fire

Rules created before write-time validation existed were never checked against the matrix, and they are grandfathered: they keep working exactly as before. A grandfathered rule whose (provider kind, check type, stage) combination is unsupported nevertheless never fires, because the provider returns a zero score for the unsupported check or stage and the rule is a silent no-op.

Where a guardrail does not fire on content that should trigger it:

1. Check the rule against the matrix above. Confirm that the provider kind supports the check type, and that the rule's stage, remembering that unset means both, falls within the supported stages.
2. Check the management-plane logs. The management plane logs a warning, including the rule ID, provider kind, check type, and stage, every time it ships a rule to the data plane that the matrix says can never fire. Searching for that warning is the fastest way to find pre-existing no-op rules.
3. Check the Admin Console. A stored check type the provider does not support is shown as disabled in the rule's form.

Editing a grandfathered rule repairs it: changing its provider, check type, stage, or configuration re-triggers validation, so the edit is held to the matrix and the corrected rule is guaranteed to be a combination that can fire. Edits limited to name, description, or active status leave the rule untouched by validation.

Built-in guardrail templates

Agent Router Enterprise ships 14 ready-made template guardrails (is_template=true). Creating a guardrail from a template clones its rules into the project, where every setting can then be tuned. All template rules ship with action = redact, mode = monitor, an observe-first default: a template rule records what it would have done until it is promoted to enforce, and to block where appropriate. The rollout procedure is covered in Configure guardrails.

Data privacy and PII (regex-based: deterministic, in process, about 0 ms)

All rules use the pii and secrets check types on the regexp provider with named pattern catalogs, on both input and output, redacting matches in place (for example [CREDENTIAL_REDACTED], [{pattern_name}_REDACTED]).

Template	Severity and failure mode	Coverage
Baseline PII Protection	critical, fail-close	Minimal set for internal tools: tax identifiers, credentials and API keys (AWS, GitHub, Slack, generic), payment cards and IBAN
GDPR EU PII Protection	critical, fail-close	EU national identifiers, financial data, contact information, business identifiers (GDPR Art. 32)
Canadian PIPEDA PII Protection	critical, fail-close	SIN, OHIP and driver licenses, passports and immigration documents, institutional IDs, contact and financial data (PIPEDA, FIPPA)
Australian PII Protection	critical, fail-close	TFN, ABN, Medicare, passports, international IDs, financial data, credentials, network infrastructure identifiers, protected-class information
Singapore PDPA Compliance (PII half)	critical, fail-close	NRIC-class identifiers, contact, financial, and business identifiers

Regulatory compliance (builtin keyword pipeline: deterministic, in process, sub-millisecond)

All rules use the compliance or banned_topics check type on the builtin provider's five-layer keyword pipeline, on both input and output unless noted.

Template	Severity and failure mode	Coverage
EU AI Act Article 5 Compliance	critical, fail-close	Prohibited practices: manipulative AI, vulnerability exploitation, social scoring, emotion recognition, biometric profiling, with parallel rule sets in English and French
Singapore MAS AI Governance	critical, fail-close	MAS AI risk-management guidelines for financial institutions: fairness and bias assessment, transparency and explainability, human oversight, data governance, model security controls
Singapore PDPA Compliance (policy half)	critical, fail-close	Sensitive data categories, do-not-call registry, cross-border data transfer, profiling and automated decisions
UAE Regulatory Compliance	high, fail-close	Anti-discrimination law and cultural-sensitivity requirements
Healthcare Claims Compliance	critical, fail-close	Claims-processing safety: fraud coaching, disclosure of protected health information (PHI), prior-authorization gaming, system-override attempts, unauthorized medical advice

Security (builtin, input stage, deterministic, in process)

Template	Severity and failure mode	Coverage
Prompt Injection Detection	critical, fail-close	Input-only rules for prompt injection, system-prompt extraction, data exfiltration, jailbreaks, malicious code injection, and SQL injection (prompt_injection, jailbreak, and ban_code check types)

Content and business policy (builtin, deterministic, in process)

Template	Severity and failure mode	Coverage
NSFW Content Safety (Global)	high, fail-close	Toxicity in five language variants (English, Spanish, French, German, Australian English), plus violence, self-harm, and child-safety rules (toxicity, violence, self_harm, sexual_content)
Bias & Discrimination Protection	high, fail-open	Gender, racial, religious, sexual-orientation, age, and disability bias (bias, hate_speech)
Professional Advice Guardrails	high, fail-open	Output-only rules preventing unauthorized legal, financial, and medical advice (banned_topics)
Competitor Mention Detection	medium, fail-open	Paired input and output rules for competitor references, recommendations, and comparisons (ban_competitors)

The same check types can be re-pointed at the ML providers where semantic coverage is needed. A jailbreak rule on the tetrate provider uses its jailbreak classifier with NLI fallback instead of, or layered behind, the pattern-based template rule.

Design characteristics

Characteristic	Description
In-gateway, in-process evaluation	A dynamic module in the data plane, rather than an SDK embedded per application or a separate proxy-of-a-proxy service hop
ML detection without data egress	The tetrate provider runs embedding and classifier models inside the customer cluster on CPU, so semantic detection (jailbreak, PII, toxicity, and the NLI-backed checks) sends no prompt to a third party. Third-party engines (Azure AI Content Safety, Amazon Bedrock Guardrails, external services) are available and are an explicit opt-in per rule
Combinations validated before they ship	The API rejects a rule whose provider kind cannot serve its check type on its stage, so a rule that could never fire cannot be created. The Admin Console scopes its forms to the same matrix
A cost ladder controlled per rule	The same check type can be served by a free in-process engine or by an ML engine. The gateway auto-orders cheap decisive checks first so local hits short-circuit expensive calls, and batches all of a provider's checks into one call
Redaction as well as blocking	Rules can mask matched content in place, with configurable redaction formats, and let traffic flow, on inputs and on outputs, instead of only rejecting requests
Shadow mode on every rule	Any rule can run in monitor mode against live traffic before enforcement. Monitor evaluation is asynchronous and never affects latency or streaming
Deliberate failure semantics	Fail-close, fail-open, and the evaluation timeout are explicit per-guardrail settings, so safety-critical paths can fail closed while availability-critical paths fail open
Investigation support	Blocked responses carry an X-Request-ID header. Operators holding a read-only grant of the guardrail_providers.read permission can look up which rules fired, the scores, and the offending content, and join against their own logging by that ID
14 ready-made templates	Region-specific and regulation-specific packs (GDPR, PIPEDA, PDPA, MAS, EU AI Act Article 5, UAE, Australian privacy, healthcare claims) plus security and content-safety packs, multilingual where relevant (EU AI Act in English and French, toxicity in five language variants), cloneable and fully editable per project

---

Where to go next

About guardrails

The object model: policies, rules, providers, patterns, and thresholds.

Configure guardrails

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

Configure guardrail providers

How the scoring engines differ in detection approach, latency, and configuration.

Guardrails best practices and FAQ

Rollout order, latency budgets, failure modes, and investigation.

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. Providers, patterns, and triggers have their own API references.