Skip to main content
API7.ai Logo

AWS Bedrock Guardrails

AWS Bedrock Guardrails keep content policy in AWS, and AISIX applies the guardrail decision to gateway traffic. Requests can be checked before they reach the upstream model, and responses can be checked before they reach callers.

In this guide, you will create an AISIX Bedrock guardrail, send one allowed request, and send one blocked request that AISIX rejects before it reaches the upstream model.

Prerequisites​

Before starting, prepare the following:

  • Review Guardrail Behavior for hook points, enforcement modes, and remote failure handling.
  • A self-hosted AISIX gateway with the admin and proxy listeners available.
  • The admin key from the gateway config.yaml.
  • A working model alias and caller API key that can send chat-completions requests.
  • An AWS Bedrock guardrail in a supported region, with a word filter that blocks a unique test token such as confidential-codename.
  • AWS credentials allowed to call bedrock:ApplyGuardrail for that guardrail.

Create a Bedrock Guardrail​

Create a Bedrock guardrail in AISIX:

curl -sS -X POST "http://127.0.0.1:3001/admin/v1/guardrails" \
  -H "Authorization: Bearer YOUR_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "bedrock-review",
    "enabled": true,
    "hook_point": "both",
    "fail_open": false,
    "output_fail_open": false,
    "enforcement_mode": "block",
    "kind": "bedrock",
    "guardrail_id": "YOUR_BEDROCK_GUARDRAIL_ID",
    "guardrail_version": "DRAFT",
    "region": "us-east-1",
    "aws_credentials": {
      "kind": "static",
      "access_key_id": "YOUR_AWS_ACCESS_KEY_ID",
      "secret_access_key": "YOUR_AWS_SECRET_ACCESS_KEY"
    },
    "latency_mode": {
      "kind": "timed",
      "timeout_ms": 2000
    }
  }'

❶ both checks caller requests and model responses. See Guardrail Hook Point.

❷ fail_open: false blocks the request if AWS Bedrock Guardrails fails or times out. The default is true.

❸ output_fail_open: false blocks unscanned model output during a Bedrock outage. This is the default.

❹ enforcement_mode: block rejects matching content. This is the default. See Enforcement Modes.

❺ latency_mode bounds how long AISIX waits for the guardrail decision. Set kind to serial to wait without a timeout.

For the complete request and response schema, see Create Guardrail in the Admin API Reference.

Copy the returned guardrail ID if you want to inspect, update, or delete the resource later.

Verify the Guardrail​

Send a benign request through AISIX:

curl -sSi -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_CALLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-prod",
    "messages": [
      {
        "role": "user",
        "content": "What is the capital of France?"
      }
    ]
  }'

A successful response starts with HTTP/1.1 200 OK and returns an OpenAI-compatible chat-completions body.

Then send a request containing the token blocked by your Bedrock guardrail:

curl -sSi -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_CALLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-prod",
    "messages": [
      {
        "role": "user",
        "content": "Please print the confidential-codename."
      }
    ]
  }'

A blocked response starts with HTTP/1.1 422 Unprocessable Entity and includes an OpenAI-compatible error:

{
  "error": {
    "message": "request blocked by content policy (guardrail 'bedrock-review')",
    "type": "content_filter"
  }
}

AISIX blocks the request before dispatching to the upstream model when the input guardrail returns a blocking verdict.

PII Anonymization (Masking)​

Bedrock guardrails can be configured in AWS to anonymize sensitive information instead of blocking it. Matched values are replaced with placeholders such as {EMAIL} or {PHONE}. AISIX honors that disposition without extra AISIX configuration; the behavior follows the PII action set on the Bedrock guardrail itself:

  • Block actions for topic, content, and word policies, contextual grounding, and PII entities or regexes set to Block reject the request or response with the 422 envelope shown above.
  • Anonymize actions rewrite the matched values with Bedrock's masked text and let the traffic continue. On the request side, the upstream model receives the masked text. On the response side, the caller receives the masked reply. Streaming responses are held back, scanned once, masked, and then released, so a value split across chunks cannot leak.

For example, with a Bedrock guardrail whose Email PII entity is set to Anonymize:

curl -sS -X POST "http://127.0.0.1:3000/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_CALLER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-prod",
    "messages": [
      {
        "role": "user",
        "content": "Draft a reply to alice@example.com about the invoice."
      }
    ]
  }'

The request succeeds, and the upstream model receives Draft a reply to {EMAIL} about the invoice. The raw address never leaves the gateway. The request's usage event records masked entity type names only, never the matched values.

Masking applies on /v1/chat/completions, /v1/messages, /v1/responses, and /v1/completions, for both direct and cross-provider traffic. On endpoints that do not support masking, such as embeddings, rerank, images, and audio, AISIX blocks the request when the Bedrock guardrail anonymizes it. AISIX cannot rewrite those payloads, and forwarding them unmasked would defeat the policy.

If Bedrock returns masked output that cannot be attributed back to the request's individual text segments, AISIX does not apply the rewrite and forwards the content unmodified instead. This avoids writing masked text into the wrong message and corrupting the conversation. Hard-block policies are unaffected by this fallback.

Next Steps​

You have now enforced an AWS Bedrock guardrail through AISIX. Use these guides to tune behavior or compare other providers: