Skip to main content
The AWS Bedrock Guardrail policy evaluates text against a guardrail you have already defined in Amazon Bedrock and applies the verdict at the gateway. One call covers everything that guardrail contains: denied topics, content filters, word lists, and the sensitive-information policy. It either blocks the request, or rewrites it in place — replacing the spans AWS anonymised with the masked text AWS itself returns, before the request reaches the model.
Only the last user message is sent. Not the system prompt. Not the earlier turns. Not tool definitions, tool calls or tool results. Not attachments. The gateway walks back through the messages, takes the most recent one whose role is user, and sends that single string — and if there is no user message with text in it, the request is forwarded without calling AWS at all.This is the single biggest limit on the policy, and it is not configurable. An instruction planted in a system prompt, smuggled into a tool result, or built up across several turns is invisible to this guardrail. Size your expectations around one message.
This policy puts a synchronous call in front of every request. What that costs depends on your region, your guardrail and the size of the message, so measure it in your own environment rather than assuming.

​
Part 1 — Build the guardrail in AWS (TBD)

This walkthrough is being written against a real account. Until then, follow AWS’s own documentation to create the guardrail, and come back for Part 2.
Everything in this part happens in your own AWS account. TrustGate never creates or changes anything there. These are the values the policy will ask you for, and the AWS-side decisions that change what it does:
TrustGate’s PII action does not set AWS’s per-entity action. They are two different decisions, and both have to agree before anything is ever masked.AWS decides, per entity, whether a match comes back as blocked or as anonymised. TrustGate’s PII action decides only what the gateway does with an anonymised verdict — and its default, Block request, turns AWS’s anonymise verdict into a hard block. A guardrail configured to mask email addresses, dropped into a policy left at its defaults, refuses the request instead.Real masking needs both: the entity set to Anonymize in the AWS console and PII action set to Anonymize here. An entity AWS comes back as blocked is always a block, whatever this setting says.
Contextual grounding is read but can never fire. The gateway sends one unqualified block of text and never marks any part of it as the grounding source or the query, which is what AWS requires before it evaluates grounding or relevance. A guardrail whose only active policy is contextual grounding will allow everything, and it will look exactly like a guardrail that is working.

​
Part 2 — Give the gateway access to AWS

The gateway needs to call bedrock:ApplyGuardrail on your guardrail. There are two ways, and they are the only two.

​
Method A — IAM role (STS)

You create a role in your account that may call the guardrail, and the gateway assumes it. Choosing IAM role (STS) in the policy hides the key fields entirely: the gateway assumes the role as its own identity — the instance or pod identity it already runs with — and stores nothing of yours but the ARN. The role needs bedrock:ApplyGuardrail on the guardrail, and its trust policy has to permit the gateway’s identity to assume it. Ask your NeuralTrust contact for that identity.
The policy cannot send an external ID. It assumes the role with a session name and nothing else, so a trust policy that requires an sts:ExternalId condition will refuse every call. Write the trust policy without one.

​
Method B — Static keys

Create an IAM user with bedrock:ApplyGuardrail on the guardrail and paste its access key ID and secret into the policy. Session token is there for temporary credentials.
The keys are stored as provided and are shown again whenever the policy is reopened. Rotate them on your normal schedule, and prefer the role where it is available to you.If you use a session token, note that nothing refreshes it. Temporary credentials expire, and when they do every request fails closed until someone pastes new ones. Static keys without a session token, or a role, are what you want for anything long-lived.

​
Part 3 — Configure the policy in TrustGate

Open Policies → Library → AWS Bedrock Guardrail.

​
AWS connection

​
Guardrail

Guardrail ID — the guardrail’s identifier in AWS. Required, and the console checks only that it is not empty; whether it exists is discovered on the first request.

​
When triggered

PII action — Block request (the default) or Anonymize. Read the warning in Part 1 before changing it: this decides what the gateway does with an anonymised verdict from AWS, and it does nothing at all unless the entity is set to anonymise on the AWS side. Block message — leave your expectations low here.
The block message is stored and never used. The field is saved with the policy, and the 403 names the matched policy and the matched name — never this text. Do not rely on it to tell your callers anything.

​
Advanced Settings

Guardrail version — defaults to DRAFT. Point production at a published version number instead: DRAFT changes the moment anyone edits the guardrail in AWS, with no change to this policy and no event to tell you. Session name — the STS session name, for the IAM role method. Defaults to BedrockClientSession. It shows up in CloudTrail, which is the only reason to change it.

​
Stage and mode

The form offers no choice of leg. A policy you create here screens the request on its way to the model, which this policy always does. The gateway can also screen the model’s answer for this policy — evaluating it, and masking it in place — but the form has no control for it, so today it can only be turned on outside the console. Start in Observe, which records every decision without refusing or rewriting anything, and switch to Enforce once the decisions look right.

​
How the decision is made

1

One message is sent to the guardrail

The most recent user message, as described at the top of this page. One call per request.
2

AWS's assessments are read in a fixed order

Denied topics, then content filters, then word lists, then sensitive information, then contextual grounding. The first blocking finding wins and is the one named in the response — regardless of how many others also matched, and regardless of which you would consider the more serious.
3

A blocking finding refuses the request

The request never reaches the model. The caller gets 403, and the response names which of the guardrail’s policies fired — denied topics, content filters, word lists, sensitive information or contextual grounding — and, where AWS provides one, the name it matched.
4

Masking applies only if nothing blocked

With PII action set to Anonymize, and AWS coming back with an anonymised verdict, the masked text AWS returned replaces the original message and the request continues to the model. The model never sees the original.
5

Otherwise the request passes through untouched

A block anywhere discards the masking. If sensitive data would be masked but another policy blocks the same message, the block wins and nothing is sent. And if masking is chosen but cannot be carried out — AWS returned no masked text, or the request body cannot be re-encoded — the gateway blocks rather than forward the original. Masking that fails is never a silent pass-through.

​
Modes and failures

Observe never masks. It records what would have happened and forwards the original text. Masking is only ever applied in Enforce.
In Enforce this policy fails closed, and there is no setting to change that. If AWS cannot be reached, requests are refused rather than forwarded unscreened. Every failure class collapses into the same 502 with no detail — an expired credential, a denied permission, a wrong region and a throttle are indistinguishable to the caller. The gateway logs the underlying error at debug level, so at a default log level it is invisible on the gateway too.

​
Limits

  • Only the last user message is inspected on the request leg. No system prompt, no conversation history, no tool definitions, no tool calls or results.
  • Contextual grounding can never fire. See the note in Part 1. A guardrail relying on it looks healthy and allows everything.
  • The form cannot turn on screening of the model’s answer. A policy created there inspects requests only.
  • Streaming responses are not inspected, on any leg. They pass through untouched.
  • The block message is never returned to the caller.
  • Text only. Files, images and audio are not sent to AWS.
  • LLM traffic only. The policy does not apply to MCP (Model Context Protocol) tool calls.

​
Verify the policy

Open the Playground, pick the application the policy applies to, and send these three prompts in this order. Starting with the control means a failure tells you something specific.
1

Control — the path works at all

Expect a normal reply and the decision allowed. In Enforce, a 502 here means the gateway could not get an answer out of AWS at all: region, credentials, permission or guardrail ID. Nothing below will work until this does.
2

Sensitive information — masking works

Send a prompt containing an entity your guardrail is configured to anonymise, for example an email address:
With PII action set to Anonymize, expect the decision anonymized.Read the reply, not just the status. It must not contain the address. That is what proves the model never received it.If you get a 403 instead, the two settings disagree: either the entity is set to Block in AWS, or PII action is still Block request. If you get a plain allowed, the entity is not in your guardrail at all.
3

A denied topic — blocking works

Send something your guardrail’s denied topics or content filters should refuse.Expect the decision block, a 403 naming the policy that fired, and no time at the provider in the timing breakdown. That the provider leg is empty is the evidence that matters: the request never reached the model.
Every decision is emitted as a metadata event, in Observe mode too, where nothing is blocked. See the event schema for the fields recorded.

​
Troubleshooting