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.
• AWS credentials allowed to call bedrock:ApplyGuardrail for that guardrail.

For a repeatable test, add a word filter to the Bedrock guardrail with a unique token such as confidential-codename. The blocked request later in this guide uses the same token.

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. Use { "kind": "serial" } to wait without a timeout.

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": "How is the weather today?"
      }
    ]
  }'

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.

Next Steps

You have now enforced an AWS Bedrock guardrail through AISIX. Continue with Built-in Keyword Guardrails when you need an in-gateway blocklist.

For other external guardrail services, see Azure AI Content Safety Guardrails or Alibaba Cloud AI Guardrails.