PII Redaction at the Gateway Before Data Reaches Providers

TL;DR

• PII redaction at the gateway detects personal data in LLM requests and responses and rewrites it before a model provider or a log store receives it.
• Bifrost-managed redaction works with five guardrail providers: Custom Regex, Secrets Detection, Microsoft Presidio, Azure AI Language PII, and Check Point's AI Agent Security.
• Three redaction modes (runtime, logs_only, runtime_reversible) decide whether the provider, the logs, or both see placeholders instead of raw values.
• The same redaction rules cover MCP tool arguments and tool results, not only LLM prompts and completions.
• Custom Regex defaults to block and Presidio defaults to detect_only, so redaction requires setting action: "redact" explicitly.

The Cisco 2025 Data Privacy Benchmark Study reported that nearly half of surveyed privacy and security professionals enter employee or non-public company data into generative AI tools, while 64% worry about that information being exposed. Once a prompt reaches a provider API it sits outside the boundary the organization controls, which is why PII redaction at the gateway matters: one gateway inspects every request, detects sensitive text, and rewrites it before the call leaves for OpenAI, Anthropic, Bedrock, or anything else. Bifrost, the open-source AI gateway written in Go by Maxim AI, is built for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. This post covers how Bifrost detects personal data, which redaction modes and strategies are available, and how to configure redaction without changing application code.

What Is PII Redaction at the Gateway

PII redaction at the gateway is a control that detects personally identifiable information in LLM requests and responses at the gateway layer, then rewrites the detected text before it reaches a model provider. The policy is written once and applies to all traffic, regardless of which team wrote the calling code.

Under the GDPR definition of personal data, the scope is wider than most teams assume. Bifrost applies redaction to every provider call passing through it, and to MCP tool calls routed through the gateway. A gateway redaction layer typically covers:

• Direct identifiers: names, email addresses, phone numbers, and government ID numbers such as US Social Security Numbers.
• Financial identifiers: credit-card-like numbers and account references.
• Network identifiers: IPv4 addresses and device identifiers that can be linked back to an individual.
• Credentials: API keys, access tokens, and private keys that engineers paste into prompts while debugging.
• Organization-specific values: internal project codenames, customer IDs, and record numbers that only your business recognizes as sensitive.

Detection, blocking, and redaction are three different outcomes. Detection records a finding and lets the request through. Blocking rejects the request. Redaction rewrites the sensitive span and lets the rest of the prompt proceed, which removes the data while keeping the workflow usable. For a comparison of platforms offering these controls, see this overview of AI governance platforms for PII redaction and guardrails.

Why Application-Layer PII Redaction Breaks Down

Application-layer redaction puts the control inside each service that calls a model. That works for one service and degrades as the number of services grows. The failure modes are structural rather than technical:

• Coverage gaps: a redaction library imported by three of your eleven AI services leaves eight unprotected, and nobody tracks which eight.
• Policy drift: each team tunes its own patterns, so the definition of "customer identifier" differs across the codebase.
• Retrieval blind spots: in a RAG pipeline the personal data often arrives from your own index rather than the user's message, after the input was already sanitized.
• No central evidence: when an auditor asks what was sent to a provider last quarter, the answer has to be assembled from several application logs.
• Uneven enforcement: coding agents, notebooks, and internal tools call providers directly and never reach the library.

Moving the control to the Bifrost AI gateway collapses these into one enforcement point. Applications change a base URL rather than their prompt-construction logic, and the redaction stage lands in the path of every call automatically. The same pattern extends to other risks covered by LLM guardrails at the gateway layer, such as prompt injection and leaked credentials.

How Bifrost Redacts PII Before Requests Reach Providers

Bifrost implements PII redaction through guardrails, a Bifrost Enterprise capability built from two objects: rules and profiles. Profiles define how content is evaluated. Rules define when and what gets evaluated, using Common Expression Language (CEL) expressions and an apply_to value of input, output, or both. A single rule can attach several profiles for layered protection, and profiles are reusable across rules.

Rules target either LLM traffic or MCP tool execution. For an LLM rule, input redaction rewrites request content before the model call and output redaction rewrites the model response. For an MCP rule, input redaction rewrites parsed tool arguments before the tool runs, and output redaction rewrites text-bearing tool results.

Five guardrail providers produce findings with byte ranges and entity types, which is what makes Bifrost-managed redaction possible:

Custom Regex runs locally with no external call, which makes it the cheapest option for structured identifiers. Secrets Detection uses the embedded default rule set from Gitleaks v8.30.1 and covers cloud credentials, source-control tokens, registry tokens, and AI provider keys, including OpenAI and Anthropic keys pasted into a prompt.

For semantic detection rather than pattern matching, Microsoft Presidio analyzes text through a Presidio Analyzer service you host yourself, with a configurable score_threshold and entity list. Azure AI Language PII covers similar ground through an Azure resource, with category filtering and a logging_opt_out flag. Running Custom Regex alongside a semantic engine is the practical pattern: regex handles formats you can specify exactly, and the analyzer handles names and free-form references.

Check Point's AI Agent Security also uses Bifrost-managed redaction. It returns message-content spans for PII, profanity, and custom regular-expression findings, and Bifrost maps those spans back to the original text before applying the configured strategy and mode. A flagged result without safely mappable spans fails closed rather than forwarding the original content.

Redaction Modes and Strategies for LLM Requests

Redaction mode decides where the rewrite is applied, and Bifrost supports three. Runtime redaction keeps sensitive text away from the provider. Logs-only redaction lets the model see the original text but keeps raw values out of stored logs. Reversible redaction does both and preserves a controlled path back to the originals.

The three modes answer different questions. Use runtime when the provider must never see the value. Use logs_only when the model genuinely needs the original text to produce a useful answer, but your log exports to S3, BigQuery, or a data lake should not carry raw personal data. Use runtime_reversible when both constraints apply and an on-call engineer still needs a way to inspect what a user actually submitted.

The full redaction behavior matrix, including reveal permissions and connector export behavior, is worth reading before a rollout. Log-side redaction is also a useful criterion when evaluating AI governance platforms with PII guardrails.

Reveal is scoped narrowly by design. Reversible placeholders such as [EMAIL-1] map back to original values only inside Bifrost logs, only for users holding the Logs:Reveal permission, and only within the rows that user is entitled to see. The mapping is stored with the log row, is encrypted when an encryption key is configured, is deleted when the row is deleted, and is never sent to a connector. Data access control still applies when a log is fetched or revealed, and if content logging is disabled there is no stored mapping to reveal.

The redaction strategy controls the replacement value in non-reversible runtime mode:

• replace: alex@example.com becomes [EMAIL]. The default, and usually enough for a model to understand that an email was present.
• mask: alex@example.com becomes [EMAIL:****************]. Preserves approximate length, which helps when the prompt concerns formatting or field width.
• hash: alex@example.com becomes [EMAIL:8c7dd922ad47494f]. Uses a deterministic short hash, so the same value produces the same token and the model can tell two references apart without seeing either one.

Entity types keep the output readable to the model rather than opaque. A Custom Regex pattern carries an entity_type such as EMAIL, US_SSN, or CREDIT_CARD, and that token is what the model receives, so a support-summarization prompt still knows a customer supplied a phone number even though the digits are gone. Redaction preserves that signal where deletion would remove it, which is why governance at the gateway does not have to cost output quality.

Configuring PII Redaction at the Gateway

Configuring PII redaction at the gateway means creating a guardrail profile with redaction actions, attaching it to a rule, and scoping that rule to the right traffic. It can be done in the Web UI, through the management API, or in config.json and Helm values, and it requires no change to application code. Setting it up takes four steps:

1. Create a profile. Add a Custom Regex configuration and select the PII Detection template, which pre-fills patterns for email, US phone, US SSN, credit-card-like numbers, and IPv4 addresses.
2. Set the action per pattern. Choose detect_only, block, or redact, then set redaction_strategy and redaction_mode for anything set to redact. Set action: "redact" explicitly: Custom Regex and Secrets Detection default to block, and Presidio and Azure AI Language PII default to detect_only.
3. Attach the profile to a rule. Write the CEL expression, set apply_to, and set a sampling_rate if you want to evaluate a percentage of traffic while tuning.
4. Scope it with virtual keys. Bind the rule to the teams and applications that need it through virtual keys, so a customer-facing service and an internal analytics job can run different policies.

The same profile can be created through the management API:

curl -X POST http://localhost:8080/api/guardrails/regex \
  -H "Content-Type: application/json" \
  -d '{
    "name": "pii-detection",
    "enabled": true,
    "config": {
      "timeout": 5,
      "patterns": [
        {
          "pattern": "\\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}\\b",
          "description": "Email address",
          "entity_type": "EMAIL",
          "flags": "i",
          "action": "redact",
          "redaction_strategy": "replace",
          "redaction_mode": "runtime_reversible"
        },
        {
          "pattern": "\\b\\d{3}-\\d{2}-\\d{4}\\b",
          "description": "US Social Security Number",
          "entity_type": "US_SSN",
          "action": "redact",
          "redaction_strategy": "replace",
          "redaction_mode": "runtime_reversible"
        }
      ]
    }
  }'

To attach the profile through the API, fetch its generated ID with GET /api/guardrails/regex, then reference it in selectedGuardrailProfiles on POST /api/guardrails/rules. Access to guardrail configuration can be limited to platform or security administrators with role-based access control.

Start with detect_only and a low sampling rate, review what the profile finds against real traffic, then move the patterns to redact once the false-positive rate is understood. Changes to guardrail configuration are recorded in audit logs, which can be signed with an HMAC key and archived to S3 or GCS, so a reviewer can establish who changed a redaction policy and when.

What Gateway Redaction Does and Does Not Cover

Redaction only applies to text a detection engine actually finds. If an engine misses a value, that value cannot be redacted in runtime payloads, logs, or connector exports. Four limits are worth stating plainly before a rollout:

• The PII Detection template is pattern-based, not semantic. It is fast and transparent, but expect false positives and false negatives, particularly for international phone numbers and unformatted values. National IDs outside the US need regex patterns you write for the exact country and format.
• Detection evaluates text, not binaries. The guardrail engines do not inspect image pixels or binary file contents.
• Streaming output redaction depends on the rule. Runtime redaction checks buffered text segments before releasing their redacted content, while logs_only redaction does not delay client delivery. If a matched rule can also block, Bifrost holds the complete stream until the final guardrail decision, as described in streaming output guardrails. Input guardrails run before the request is forwarded and do not carry this cost.
• One rewrite owner per phase. If a phase produces both provider-managed transformed text and gateway-side redaction findings, the request fails closed with a guardrail intervention rather than merging two rewrites. This matters when an external provider such as AWS Bedrock Guardrails returns its own transformed text for the same phase; detection-only and blocking profiles can still run alongside Bifrost-managed redaction.

Gateway redaction is the final control before egress, not a substitute for classifying data at ingestion. Teams running retrieval over records containing personal data should still scrub or scope the index; the gateway catches what slips through, and it should not be the only control between a poorly governed index and a provider. For how these limits map to specific compliance obligations, see PII filtering and compliance at the AI gateway layer.

Common Questions About PII Redaction at the Gateway

Does redaction at the gateway add meaningful latency?

Custom Regex and Secrets Detection run in-process, so they add no network hop. Presidio and Azure AI Language PII add a call to the analyzer you configure, bounded by the profile timeout. Bifrost itself adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks.

Can PII redaction run entirely inside our own network?

Yes. Custom Regex and Secrets Detection execute inside the Bifrost process, and Presidio can be self-hosted. Combined with in-VPC deployment, detection and the placeholder mapping stay inside infrastructure you control.

How is PHI handled differently from general PII?

Azure AI Language PII exposes a phi domain for protected health information scenarios, and the same redaction modes apply. Teams working under HIPAA usually pair runtime redaction with in-VPC deployment; the healthcare AI infrastructure patterns cover the surrounding requirements.

Does redaction apply to model responses as well as prompts?

Yes. Set the rule's apply_to field to output or both. Response-side redaction matters when a model echoes personal data back from retrieved context or tool output.

Can we redact only in logs while sending the real prompt to the provider?

Yes, with logs_only. Runtime content stays raw and reaches the provider unchanged, while logs and trace exports receive reversible placeholders. This is the mode for teams whose concern is retention in observability systems rather than provider egress.

Does PII redaction work for MCP tool calls?

Yes. Guardrail rules can target MCP tool execution as well as LLM traffic. Input redaction rewrites parsed tool arguments before the tool runs, and output redaction rewrites text-bearing tool results after execution. Reversible modes store phase-scoped mappings on the MCP tool log, so a user with Logs:Reveal can inspect original values while everyone else sees placeholders. This covers agents that pass customer records into tools, a pattern common in coding agent deployments with PII guardrails.

Are exported traces and logs redacted too?

Yes. Trace-export connectors such as OpenTelemetry, Datadog, Kafka, Pub/Sub, and BigQuery receive redacted or placeholderized content, and the reveal mapping is never exported. Log exports to object storage carry the same redacted fields that Bifrost logs store. Prometheus metrics contain no request or response content, so there is nothing to redact there.

Getting Started with PII Redaction at the Gateway

PII redaction at the gateway turns a per-application discipline into one enforced policy: a single place to define what counts as sensitive, a single place to decide whether the provider or the log sees it, and a single place to prove what happened. The Bifrost platform pairs that control with the deployment model regulated teams need, including air-gapped and on-prem deployments with VPC isolation, alongside the governance capabilities that sit with it: virtual keys, budgets, and rate limits.

Teams in healthcare, finance, and insurance can compare this setup with the requirements in PII redaction at the gateway layer for regulated industries, and the broader enterprise AI guardrails for PII, injection, and toxicity show where redaction fits in a full guardrail policy.

To see how PII redaction at the gateway would work against your own traffic and compliance requirements, book a demo with the Bifrost team.