AI Governance

AWS Bedrock Guardrails in Bifrost: PII Detection and Content Filtering Setup

Bifrost integrates AWS Bedrock Guardrails as a gateway-layer guardrail profile, enforcing PII redaction and content filtering across every LLM provider without per-application configuration. This walkthrough covers IAM auth, profile setup, CEL rule targeting, and a working two-rule configuration for input and output scanning.

AWS Bedrock Guardrails provides PII detection across 50+ entity types and content filtering across six harm categories, all configured in the AWS console and callable via a single guardrail ARN. The integration challenge is coverage: most teams end up calling the guardrail only from applications that have been explicitly wired up to it, leaving other services, new integrations, and agent workloads unprotected. Bifrost, the open-source AI gateway built in Go by Maxim AI, solves this by running Bedrock Guardrails as a gateway-layer profile that applies to every request routed through the gateway, regardless of which application sent it or which model provider handles it. One guardrail ARN, one profile configuration, uniform enforcement across 1,000+ models.

What AWS Bedrock Guardrails Provides

Before configuring the integration, it helps to understand what policies Bedrock Guardrails can enforce and what each policy does in the request pipeline.

AWS Bedrock Guardrails provides six configurable safeguard policies:

Content filters: Detects and blocks harmful content across six categories: hate speech, insults, sexual content, violence, misconduct, and prompt attacks. Each category has configurable filter strength for both inputs and outputs independently.
Sensitive information filters (PII): Identifies and either blocks or anonymizes 50+ PII entity types, including name, email, phone, address, age, Social Security Number, credit card numbers, and medical information. Actions (BLOCK or ANONYMIZE) can be configured independently per entity type and per direction (input vs. output). Anonymize replaces detected PII with identifier tags rather than blocking the entire request.
Denied topics: Natural language topic definitions that instruct the guardrail to block conversations about specific subjects. For example, "competitor products" or "investment advice outside the platform's scope."
Word filters: Specific word and phrase blocklists for organization-specific policy enforcement.
Contextual grounding: Scores model responses against a retrieved context window for RAG applications, flagging hallucinated content that cannot be grounded in the source documents.
Automated Reasoning checks: Formal logic verification for factual accuracy claims.

Within Bifrost's guardrail system, the Bedrock profile applies whichever of these policies are configured in your Bedrock guardrail. You configure the policies once in the AWS console, then point Bifrost at the guardrail ARN. Bifrost calls the guardrail on every matched request and enforces the guardrail's verdict.

AWS Bedrock Guardrails is the only provider in Bifrost's current guardrail lineup with support for image content analysis, making it the right choice for multimodal agent workflows where images flow through the prompt or response.

Prerequisites

Before configuring the Bifrost profile, you need:

A Bedrock guardrail created in the AWS Bedrock console with the PII and content filter policies configured for your use case
The guardrail ARN (format: arn:aws:bedrock:<region>:<account-id>:guardrail/<guardrail-id>) and a published version number (or "DRAFT" for the draft version)
AWS credentials with bedrock:ApplyGuardrail permission on the guardrail ARN, or an IAM role attached to the host running Bifrost

The minimum IAM policy for Bifrost to call Bedrock Guardrails:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:ApplyGuardrail",
      "Resource": "arn:aws:bedrock:<region>:<account-id>:guardrail/<guardrail-id>"
    }
  ]
}

Scope the Resource to the specific guardrail ARN rather than *. If you have multiple guardrail profiles in Bifrost (for example, one per environment or one per use case), list each ARN.

Step 1: Creating the Bedrock Guardrail Profile in Bifrost

The Bedrock guardrail profile tells Bifrost which ARN to call and how to authenticate. Bifrost supports three authentication modes for the Bedrock profile: keys (static IAM access key and secret), api_key (Bedrock API key), and iam_role (ambient IAM role no explicit credentials in config).

Option A: Static IAM credentials (keys mode)

curl -X POST <http://localhost:8080/api/guardrails/bedrock> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "PII and Content Filter",
    "enabled": true,
    "timeout": 15,
    "config": {
      "guardrail_arn": "env.BEDROCK_GUARDRAIL_ARN",
      "guardrail_version": "1",
      "region": "env.AWS_REGION",
      "auth_type": "keys",
      "access_key": "env.AWS_ACCESS_KEY_ID",
      "secret_key": "env.AWS_SECRET_ACCESS_KEY"
    }
  }'

All credential fields support "env.VARIABLE_NAME" syntax. Bifrost resolves the value from the process environment at startup and never exposes credentials in API responses or the management UI.

Option B: IAM role (ambient credentials recommended for EC2, EKS, ECS)

When Bifrost runs on an EC2 instance, EKS pod with IRSA, or ECS task with an attached task role, use iam_role mode. No credentials appear in the config file:

curl -X POST <http://localhost:8080/api/guardrails/bedrock> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "PII and Content Filter",
    "enabled": true,
    "timeout": 15,
    "config": {
      "guardrail_arn": "env.BEDROCK_GUARDRAIL_ARN",
      "guardrail_version": "1",
      "region": "env.AWS_REGION",
      "auth_type": "iam_role"
    }
  }'

To assume a specific role rather than the instance role:

{
  "auth_type": "iam_role",
  "role_arn": "env.AWS_ROLE_ARN",
  "external_id": "env.AWS_EXTERNAL_ID",
  "session_name": "bifrost-guardrails-session"
}

In config.json for both auth modes, the structure sits under guardrails_config.guardrail_providers:

{
  "guardrails_config": {
    "guardrail_providers": [
      {
        "id": 1,
        "provider_name": "bedrock",
        "policy_name": "PII and Content Filter",
        "enabled": true,
        "timeout": 15,
        "config": {
          "guardrail_arn": "env.BEDROCK_GUARDRAIL_ARN",
          "guardrail_version": "1",
          "region": "env.AWS_REGION",
          "auth_type": "iam_role"
        }
      }
    ]
  }
}

Note the timeout field at the provider level (in seconds). Bedrock Guardrails is an external API call; 10-15 seconds is a reasonable ceiling. If the call exceeds the timeout, Bifrost passes the request through rather than blocking, so set the timeout based on the acceptable latency impact for your endpoints.

Step 2: Creating CEL Rules That Invoke the Profile

A profile alone does nothing. Rules define when the profile fires. Rules use CEL (Common Expression Language) expressions to scope enforcement. Each rule specifies whether it applies to inputs, outputs, or both, and links to one or more profiles by their numeric IDs.

Rule for input scanning (PII in prompts, prompt attacks)

This rule fires on all incoming user messages and routes them through the Bedrock profile before the request leaves Bifrost for the model provider:

curl -X POST <http://localhost:8080/api/guardrails/rules> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "Bedrock: Block PII and Prompt Attacks in Inputs",
    "enabled": true,
    "celExpression": "request.messages.exists(m, m.role == \\"user\\")",
    "applyTo": "input",
    "samplingRate": 100,
    "timeout": 15000,
    "selectedGuardrailProfiles": ["bedrock:1"]
  }'

The CEL expression request.messages.exists(m, m.role == "user") scopes the rule to requests that include at least one user message. This avoids running the guardrail on requests that contain only system messages or tool results, which reduces unnecessary latency on automated pipeline traffic that does not carry user-sourced content.

Rule for output scanning (PII in responses, harmful content)

This rule fires on all model responses before they return to the calling application:

curl -X POST <http://localhost:8080/api/guardrails/rules> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "Bedrock: Filter PII and Harmful Content in Outputs",
    "enabled": true,
    "celExpression": "true",
    "applyTo": "output",
    "samplingRate": 100,
    "timeout": 15000,
    "selectedGuardrailProfiles": ["bedrock:1"]
  }'

Output scanning with cel_expression: "true" applies to every response. PII detected in outputs can be ANONYMIZE'd (redacted with identifier tags like [SSN]) rather than blocked outright, depending on how your Bedrock guardrail is configured. This keeps the response usable for the caller while removing the raw sensitive value.

Scoping to specific models or providers

CEL expressions can narrow the scope further. To run the expensive PII check only on GPT-4-class models where sensitive data is more likely to be in the prompt:

// Only run on GPT-4 family (input scanning)
request.model.startsWith("gpt-4")

// Only run on Anthropic Claude models
request.model.contains("claude")

// Apply to all non-internal traffic (if you embed a virtual key check)
true  // use samplingRate to manage cost on high-volume endpoints

The full CEL expression reference for Bifrost guardrail rules is in the guardrails documentation.

Step 3: Testing the Configuration

Once the profile and rules are created, test with a request that contains a known PII trigger. Use the Bifrost inference endpoint directly:

curl -X POST <http://localhost:8080/v1/chat/completions> \\
  -H "Content-Type: application/json" \\
  -H "x-bf-vk: your-virtual-key" \\
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "My SSN is 123-45-6789 and email is jane@example.com. Can you summarize this for me?"
      }
    ]
  }'

If the Bedrock guardrail is configured to BLOCK on SSN detection at input, Bifrost returns a guardrail intervention response instead of forwarding to the model. If it is configured to ANONYMIZE, the SSN and email are masked before the request reaches the provider.

For output testing, submit a prompt that would cause the model to echo back sensitive information, and verify the response is sanitized before it arrives at the caller.

The Bifrost Web UI also provides a Test button on guardrail rules that accepts a sample message payload and shows whether the rule would trigger for that content, without making a live inference call.

Complete config.json for a PII and Content Filter Setup

{
  "guardrails_config": {
    "guardrail_providers": [
      {
        "id": 1,
        "provider_name": "bedrock",
        "policy_name": "Enterprise PII and Content Filter",
        "enabled": true,
        "timeout": 15,
        "config": {
          "guardrail_arn": "env.BEDROCK_GUARDRAIL_ARN",
          "guardrail_version": "1",
          "region": "env.AWS_REGION",
          "auth_type": "iam_role"
        }
      }
    ],
    "guardrail_rules": [
      {
        "id": 1,
        "name": "Block PII and Prompt Attacks in User Inputs",
        "enabled": true,
        "cel_expression": "request.messages.exists(m, m.role == \\"user\\")",
        "apply_to": "input",
        "sampling_rate": 100,
        "timeout": 15000,
        "provider_config_ids": [1]
      },
      {
        "id": 2,
        "name": "Filter PII and Harmful Content in Responses",
        "enabled": true,
        "cel_expression": "true",
        "apply_to": "output",
        "sampling_rate": 100,
        "timeout": 15000,
        "provider_config_ids": [1]
      }
    ]
  }
}

This configuration uses IAM role auth (no credentials in config), targets user messages for input scanning, and applies output filtering to all responses. The Bedrock guardrail itself controls which policies are active (PII detection, content filtering, denied topics) based on how it was configured in the AWS console.

Layering Bedrock with Native Guardrails

For teams that need both broad credential detection and PII redaction, combining the Bedrock profile with Bifrost's native secrets detection and custom regex profiles on the same rule gives defense-in-depth. The Gitleaks-backed secrets detection runs in-process with no outbound call, and Bedrock handles the semantic PII and content categories:

curl -X POST <http://localhost:8080/api/guardrails/rules> \\
  -H "Content-Type: application/json" \\
  -d '{
    "name": "Full Input Scan: Secrets + PII",
    "enabled": true,
    "celExpression": "request.messages.exists(m, m.role == \\"user\\")",
    "applyTo": "input",
    "samplingRate": 100,
    "timeout": 20000,
    "selectedGuardrailProfiles": ["secrets:2", "bedrock:1"]
  }'

Bifrost evaluates profiles in sequence. The in-process secrets check runs first (sub-millisecond), and if it passes, the Bedrock API call fires. This ordering keeps the fast native check as the first gate, with the external API call reserved for traffic that passes the cheap local filter.

Compliance Evidence and Audit Logs

Every guardrail evaluation creates an entry in Bifrost's audit log with the rule name, profile, guardrail ARN, evaluation outcome, and full request metadata. For teams operating under HIPAA, GDPR, or SOC 2 requirements, this log provides the real-time enforcement evidence that policy documents cannot.

Log exports deliver guardrail evaluation records to S3, GCS, or BigQuery for retention and analysis. The Bifrost governance resource hub covers the full audit and observability stack for teams building a compliance evidence pipeline.

Next Steps

With Bedrock Guardrails running at the gateway level, every application using Bifrost inherits PII detection and content filtering without any code change. The two-rule setup above (user input scanning plus response filtering) is the right starting point for most deployments.

For teams on AWS infrastructure, Bifrost can run entirely within your VPC so guardrail API calls never cross the public internet. The Bifrost Enterprise page covers in-VPC deployment, vault integration for AWS Secrets Manager, and the full enterprise governance stack.

To see how the Bedrock Guardrails integration fits your specific threat model, book a demo with the Bifrost team.