PII Redaction at the Gateway Before Data Reaches Providers

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 proxy 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 proxy 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. The open-source Bifrost gateway applies redaction to every provider call passing through it. 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 is the only option that removes the data while keeping the workflow usable.

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 Bifrost 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.

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.

Four detection engines 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.

Redaction Modes and Strategies for LLM Requests

Redaction mode decides where the rewrite is applied, and the Bifrost AI gateway 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.

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.

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

Setting up PII redaction at the gateway 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.
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"
        }
      ]
    }
  }'

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 adds latency. For an output or both rule, the full response is accumulated and checked before delivery. 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.

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.

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.

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.

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