AWS Bedrock Guardrails Architecture Deep Dive: Where the Inspection Sits and What It Cannot See

AWS Bedrock Guardrails is the AWS-side policy enforcement layer Amazon ships inside the Bedrock runtime. The product launched in April 2024 with content filters and prompt-injection mitigation and expanded through 2025 and into 2026 with PII redaction, contextual grounding checks, and the standalone ApplyGuardrail API. The architecture sits inside the InvokeModel and Converse call path on the AWS side of the API. The position has consequences for the deployer that runs Bedrock alongside non-AWS LLM endpoints, the deployer that needs per-decision evidence outside the AWS audit pipeline, and the deployer that needs to enforce a policy AWS does not author.

I want to walk through the Bedrock Guardrails request path, the four policy categories AWS exposes, where the inspection actually runs, the audit records the deployer receives, and the deployment patterns the Bedrock-only customer and the multi-cloud customer should each consider.

The Bedrock Guardrails request path

A standard Bedrock invocation runs the InvokeModel or Converse API against a model identifier. A guardrail-protected invocation includes a guardrailIdentifier and a guardrailVersion parameter the application supplies. The Bedrock runtime reads the parameters, fetches the guardrail configuration from the service-side store, runs the input checks against the prompt, forwards the prompt to the model if the input checks pass, runs the output checks against the model response, and returns the response (or the guardrail intervention) to the application.

The full path runs inside AWS's network. The application has no inspection point between the application and Bedrock other than the network proxy the customer's VPC may run. The guardrail evaluation, the policy versioning, and the audit record emission all happen inside the Bedrock service. The deployer reads the result through the API response and the CloudTrail audit pipeline.

The ApplyGuardrail API decouples the guardrail check from the model invocation. The application can call ApplyGuardrail against an arbitrary text payload and receive the guardrail's verdict without forwarding to a model. The pattern lets the deployer apply the same guardrail to non-Bedrock endpoints (a self-hosted model, a different cloud's API) by routing through the ApplyGuardrail call before issuing the model request.

The four policy categories

The first category is content filters. The configuration accepts categories (hate, insults, sexual, violence, misconduct) with severity thresholds (LOW, MEDIUM, HIGH). The guardrail evaluates the prompt and the response against the categories and blocks (or modifies) on threshold violations.

The second category is denied topics. The configuration accepts a topic definition with example phrases. The guardrail's classifier evaluates the prompt for semantic similarity to the denied topic and intervenes on a positive match. The category covers organization-specific content the standard content filters do not target (competitor disclosure, internal policy questions, off-label medical advice).

The third category is sensitive information filtering. The configuration accepts PII categories (US Social Security numbers, credit card numbers, US phone numbers, email addresses, and others) and regex patterns the deployer supplies. The guardrail detects the categories in the prompt and the response and either blocks or redacts on detection.

The fourth category is contextual grounding checks. The configuration evaluates the response against the grounding source the application supplies (the retrieved documents for a RAG application). The guardrail returns a grounding score and a relevance score the deployer's policy reads to decide whether to surface the response.

The four categories cover a meaningful slice of the production AI safety surface. The categories are also constrained to what AWS publishes. A deployer that needs a policy outside the four categories (per-user policy that depends on directory roles, per-tenant policy that depends on customer attribution, per-region policy that depends on data residency) has to layer the policy outside the guardrail.

Where the inspection actually runs

The inspection runs inside the Bedrock service. The classifier and the policy decision point are AWS-managed. The deployer configures the policy through the Bedrock console or the SDK and the configuration ships to the service-side store.

The position has three consequences. The deployer's policy is constrained by what the Bedrock guardrail configuration surface supports. A policy that depends on inputs the configuration surface does not accept (directory roles the application maintains, custom data classifications the deployer's own classifier produces, per-tenant rules that vary across customers) cannot run inside the guardrail.

The deployer's audit record is constrained by what AWS emits. The guardrail's decisions land in CloudTrail and in the model invocation logs. The records carry the AWS account identifier, the role that issued the request, the guardrail identifier, the policy decisions, and the model invocation outcome. The records do not carry the deployer's natural-person identifier when the application calls Bedrock with an application service account.

The deployer's non-Bedrock endpoints are not covered. A multi-model deployment that routes between Bedrock for SOC 2 boundaries and OpenAI for chat sees the guardrail on the Bedrock side and no guardrail on the OpenAI side. The ApplyGuardrail API can cover the OpenAI traffic if the application routes through it, but the deployer is then maintaining a Bedrock dependency for a non-Bedrock workload.

The audit records the deployer receives

CloudTrail records the API call to InvokeModel or Converse with the request identifier, the role, the timestamp, and the guardrail invocation outcome. Bedrock invocation logs (when enabled and written to S3) carry the prompt, the response, the guardrail intervention, the model identifier, and the latency.

The records satisfy the AWS internal audit needs and the SOC 2 evidence AWS provides for its own controls. The deployer's external audit needs are partly satisfied. EU AI Act Article 12 expects identification of the natural persons involved in the decision; the records carry the application's IAM role rather than the user. HIPAA 164.312 expects audit controls on PHI access; the records carry the prompt content (when invocation logging is enabled) but the access-control reconstruction depends on the application correctly propagating the natural-person identity into a context field the records can capture.

The Bedrock customer that needs the per-decision evidence at the natural-person level (a HIPAA-covered healthcare deployment, an EU AI Act high-risk deployment, a Fannie Mae LL-2026-04 lending deployment) has to either bind the natural-person identity into the IAM session through Cognito or an external identity broker, or run an external inspection layer that captures the natural-person identity at the application boundary.

The deployment patterns

The Bedrock-only customer with a single-model deployment can configure guardrails inside Bedrock and rely on the CloudTrail and invocation logs for the audit pipeline. The pattern works when the customer's AI workload runs entirely inside AWS and the natural-person identity reaches Bedrock through an IAM-integrated identity broker.

The Bedrock-only customer with a multi-model deployment (Bedrock for one workload, on-prem or self-hosted for another) can use ApplyGuardrail to apply the guardrail to non-Bedrock endpoints. The pattern adds Bedrock as a dependency on the non-Bedrock path. The deployer's resilience model has to consider Bedrock service availability for the policy decisions on the non-Bedrock workload.

The multi-cloud customer with Bedrock alongside OpenAI, Anthropic, or Azure OpenAI faces the policy fragmentation. The Bedrock guardrails cover one set of routes. The other routes either run uncovered or run an external inspection layer that covers all routes from a single policy surface. The external layer is the pattern the multi-cloud customer most often lands on for the per-decision evidence.

The deployer that needs per-user policy based on directory roles, per-tenant policy based on customer attribution, or per-region policy based on data residency runs the policy outside the Bedrock guardrail because the guardrail configuration surface does not accept those inputs.

DeepInspect

This is the architectural context DeepInspect deploys into for Bedrock customers. DeepInspect sits inline between the application and each AI endpoint the application calls. The inspection layer reads the prompt, the retrieved context, the response, and the identity the application propagates. The layer evaluates identity-aware policy (per-user, per-tenant, per-region, per-route) and commits per-decision audit records bound to the verified natural-person identifier.

For a Bedrock-only deployment that needs per-decision evidence at the natural-person level, DeepInspect runs alongside the Bedrock guardrails. The Bedrock guardrail handles the content and PII categories AWS authored. DeepInspect's records carry the natural-person identity and the deployer-authored policy decisions. The two record series compose into the full per-decision evidence the regulator reads.

For a multi-model deployment that includes Bedrock and non-AWS endpoints, DeepInspect covers all routes from a single policy surface. The deployer authors one policy that applies across Bedrock, OpenAI, Anthropic, and any on-prem model the deployment runs. Book a technical deep dive at deepinspect.ai.