Amazon Bedrock guardrails and inline security

Bedrock is the one platform on this list that ships a first-party guardrail with a standalone evaluation API, which changes the question from "how do I add a control" to "which controls belong to the platform and which do not". This page answers that from AWS's own documentation and states plainly what we do not claim.

We publish no tested-compatibility claim for Amazon Bedrock. Our own tested support belongs in the supported models and frameworks matrix, which is not filled in yet. Everything below is either documented by AWS and linked, or follows from where a control sits.

What the ApplyGuardrail API does

AWS documents ApplyGuardrail as a way to "assess any text using your pre-configured Amazon Bedrock Guardrails, without invoking the foundation models". The properties that matter for architecture:

• Decoupled from the model. The documentation is explicit: "ApplyGuardrail API is decoupled from foundational models. You can now use Guardrails without invoking Foundation Models."
• Both directions. You set source to INPUT for user content and OUTPUT for model output, and "can evaluate user inputs and FM generated outputs independently".
• Callable anywhere in the flow. AWS gives the RAG case directly — "you can now evaluate the user input before performing the retrieval, instead of waiting until the final response generation".
• A decision, not a score. The response carries action, either GUARDRAIL_INTERVENED or NONE, plus assessments naming the policy that fired, and output containing the masked text or the configured canned message.
• Its own latency figure. Invocation metrics include guardrailProcessingLatency, which is the honest way to report the cost of a check: per call, for that configuration.
• A debugging mode. Setting outputScope to FULL returns non-detected entries as well, which is what you want while tuning rather than in production.

Source: Use the ApplyGuardrail API in your application, read 13 August 2026. Read it before designing around this page — the policy types and the response shape are versioned and this is a snapshot.

Bedrock Guardrails is a reasonable choice, and for a team entirely inside AWS with no other model provider it is often the right first control. Nothing below argues otherwise.

Where a separate inline layer attaches

There are three shapes, and they are not exclusive.

In front of bedrock-runtime. Your application calls a layer you run, the layer calls Bedrock. AWS SDKs expose an endpoint override, so this is usually a client-configuration change rather than an application rewrite. This is the only shape that covers every call regardless of the code path, and it is the one that survives someone adding a new service next quarter.

Called explicitly, alongside ApplyGuardrail. Because ApplyGuardrail is itself a standalone check, an application already structured around it has a natural place to put a second, differently-sourced check — before retrieval, before the model call, or on the response. Two independent detectors disagreeing is information; one detector agreeing with itself is not.

Inside the framework. If your Bedrock calls go through an agent framework, the framework's own hooks are available too — see LangChain and LlamaIndex for what each can and cannot enforce from there.

How to split the controls

The useful question is not "platform or third party" but "what does each one have that the other does not".

Reasons a control belongs to the platform. It is in the same trust boundary and the same network, so it adds no new processor to your transfer analysis and no new hop to your latency budget. It is configured with the rest of your AWS estate and audited with it. If Bedrock is the only place your models are, this is a strong argument.

Reasons a control belongs outside it. Portability: one policy that applies to Bedrock, to a self-hosted model and to whatever the team adopts next, rather than a policy per platform that drifts apart. Independence: a detector supplied by the same vendor as the model shares its blind spots. And the ability to run the check on your own corpus at your own threshold, which is the only false-positive number worth having — see detection accuracy and false positives.

What neither of them does. Authorisation. A guardrail evaluating text cannot decide whether this user was entitled to the document that text came from, or whether this agent may call that tool. Those are enforced at the retriever and at the tool. RAG security and AI agent security set out why, and it is the most common gap in an otherwise well-built Bedrock deployment.

Data residency and network path

Adding a hop changes the answer to "where is this processed", so decide it deliberately. A layer running in your own AWS account, in the same region as the Bedrock endpoint you call, adds no new jurisdiction. A hosted layer in a different region does, and that belongs in your transfer analysis before it belongs in a diagram — see GDPR and LLM data handling for what that analysis has to cover, and data residency for what is still open about our own hosted service.

If the requirement is that prompt content never leaves your account at all, on-premises deployment is the answer that actually satisfies it. No choice of processing region does.

What to ask us before you commit

• Do you support an endpoint-override deployment in front of bedrock-runtime today, and for which SDKs?
• Can your check be called standalone, the way ApplyGuardrail can, so it can run before retrieval?
• Can it be deployed inside our own AWS account and region?
• What happens to a call when the layer cannot reach a decision?

Get the answers in writing; evaluation and security review has the rest of the list.

Related

• Google Vertex AI
• The Anthropic API
• LLM firewall versus WAF
• Build versus buy