PII Protection for AI APIs: How to Sanitize Sensitive Data at the Gateway

Every API call to an LLM is a potential data leak. A customer types their full name, email address, and account number into a support chatbot. A retrieval-augmented generation (RAG) pipeline pulls employee records to answer a question. An MCP tool returns a database row containing a Social Security number. In every case, personally identifiable information (PII) is flowing through your AI infrastructure — and unless something intercepts it, that data reaches the model.

LLMs don’t understand privacy. They can’t tell the difference between a harmless sentence and a prompt containing a patient’s medical history. Worse, models can memorize and later regurgitate sensitive data from their training sets. Agentic AI compounds the problem — autonomous agents making multi-step decisions, calling tools, and accessing data sources multiply the number of points where PII can leak.

This isn’t a theoretical risk. According to IBM’s Cost of a Data Breach Report, 53% of data breaches involve customer PII, and 40% of organizations report AI-related privacy incidents. The question isn’t whether your AI APIs handle sensitive data — they do. The question is whether you have a systematic way to catch it before it causes a compliance violation or a breach.

Why LLMs are a PII risk

Large language models present unique challenges for data privacy that traditional API security doesn’t fully address.

Models memorize training data. Research has repeatedly demonstrated that LLMs can memorize and reproduce verbatim snippets from their training sets — including names, phone numbers, email addresses, and other PII that appeared in the training corpus. When a model has seen sensitive data during training, it can surface that data in responses to seemingly unrelated prompts.

Models don’t understand privacy boundaries. An LLM processes tokens. It has no concept of “this is a Social Security number and should not be included in the output.” If a prompt or context window contains PII, the model will use it freely — to generate completions, answer questions, or provide summaries that include the sensitive data verbatim.

Agentic AI multiplies exposure vectors. When AI agents operate autonomously — calling APIs, reading databases, executing multi-step workflows — every tool call is a potential PII touchpoint. An agent retrieving customer records from a CRM, querying a healthcare database, or reading emails through an MCP server can pull sensitive data into the conversation context without any human review.

In-context learning creates new risks. Even models that weren’t trained on your data can be exposed to PII through prompts, system messages, and RAG context. This data may persist in provider logs, be used for model improvement (depending on the provider’s data policy), or leak through the model’s responses.

The compliance case for gateway-level PII protection

PII handling in AI systems isn’t just good practice — it’s a regulatory requirement across multiple frameworks.

GDPR requires that personal data processing have a lawful basis and follow data minimization principles. Sending unnecessary PII to a third-party LLM provider violates both. Article 25 mandates “data protection by design and by default,” which means PII should be stripped before it reaches systems that don’t need it.

HIPAA governs protected health information (PHI) in healthcare contexts. Any AI system processing patient data must ensure that PHI is not transmitted to unauthorized parties — and most LLM providers are not covered entities or business associates under HIPAA.

SOC 2 Trust Service Criteria require organizations to demonstrate controls over how sensitive data is processed, stored, and transmitted. An API gateway that automatically redacts PII from AI traffic provides exactly the kind of demonstrable, auditable control that SOC 2 assessors look for.

The EU AI Act classifies AI systems by risk level and imposes requirements for high-risk systems — including those processing biometric data, health data, or data used in employment and education decisions. PII sanitization at the infrastructure level helps demonstrate compliance with these requirements.

The common thread across all these frameworks is that the best place to enforce PII protection is at a centralized enforcement point — before data reaches the model, before it leaves your infrastructure, and in a way that’s auditable and consistent. An API gateway is exactly that enforcement point.

PII exposure vectors in AI APIs

Understanding where PII enters and exits your AI stack is the first step toward protecting it. There are four primary exposure vectors.

User prompts

The most obvious vector. Users type sensitive information directly into prompts: names, email addresses, phone numbers, account numbers, medical symptoms, financial details. In a support chatbot, this happens in nearly every conversation. The data flows through your API to the LLM provider — and unless you intercept it, the provider receives it in full.

RAG context injection

Retrieval-augmented generation (RAG) systems pull documents from your knowledge base and inject them into the model’s context window. If your document store contains employee records, customer profiles, contracts with personal details, or medical records, that data gets sent to the LLM as part of every relevant query. The user who asked the question may not even know what data the RAG system retrieved.

MCP tool responses

Model Context Protocol (MCP) servers give AI agents access to external tools and data sources — databases, CRMs, ticketing systems, file storage. When an agent calls a tool, the response may contain PII from the underlying system. A get_customer tool might return a full name, address, and payment details. A search_tickets tool might surface support conversations containing personal information. Every tool response is a potential PII vector.

LLM response leakage

Models can leak PII in their responses — either by reproducing data from the current context window, hallucinating plausible-looking personal data, or regurgitating memorized training data. Response-side PII leakage is harder to predict because it depends on the model’s behavior rather than your inputs.

Gateway-level PII sanitization

The API gateway sits at the intersection of all these data flows. Every prompt, every RAG context injection, every MCP tool response, and every LLM output passes through it. This makes the gateway the single most effective place to enforce PII sanitization.

Gateway-level sanitization works by intercepting requests and responses in transit and applying detection and redaction rules before the data continues to its destination. Instead of relying on every application team to implement their own PII handling, you enforce it once, at the infrastructure level, and every AI interaction benefits.

Detection approaches

There are two main approaches to PII detection, and most production systems use a combination of both.

Pattern-based detection uses regular expressions and structured patterns to identify known PII formats: email addresses (user@domain.com), phone numbers, Social Security numbers (XXX-XX-XXXX), credit card numbers (Luhn-validated digit sequences), API keys (vendor-specific prefixes like sk-, ghp_, zpka_), and private key blocks. Pattern-based detection is fast, deterministic, and has near-zero false positives for well-defined formats.

ML-based detection uses named entity recognition (NER) models to identify unstructured PII like personal names, physical addresses, medical conditions, and other context-dependent sensitive data. ML-based detection catches PII that doesn’t follow a fixed format but requires more computational resources and may produce false positives.

What to do with detected PII

Once PII is detected, there are several strategies for handling it:

• Redaction replaces PII with a placeholder like [REDACTED] or ****. Simple, effective, and irreversible — the downstream system never sees the original data.
• Tokenization replaces PII with a reversible token that maps back to the original value in a secure vault. The LLM receives [USER_TOKEN_42] instead of “Jane Smith,” and the application can de-tokenize the response before showing it to the user.
• Pseudonymization replaces PII with consistent fake values — “Jane Smith” becomes “Alice Johnson” throughout the conversation. This preserves the structure and context that LLMs need to reason effectively, while preventing real data from reaching the model.

Implementing PII protection with Zuplo

Zuplo’s AI Gateway and MCP Gateway provide multiple layers of PII protection that work together to create a comprehensive data sanitization pipeline.

Secret masking for known patterns

The Secret Masking policy automatically detects and redacts sensitive secrets from responses before they reach downstream consumers. Out of the box, it catches:

• Zuplo API keys (zpka_*)
• GitHub tokens and Personal Access Tokens (ghp_*)
• Private key blocks (BEGIN PRIVATE KEY … END PRIVATE KEY)

You can extend coverage to domain-specific PII patterns using the additionalPatterns option. Here’s a configuration that adds patterns for email addresses, Social Security numbers, and credit card numbers:

{
  "name": "pii-masking-policy",
  "policyType": "secret-masking-outbound",
  "handler": {
    "export": "SecretMaskingOutboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "mask": "[REDACTED]",
      "additionalPatterns": [
        "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}\\b",
        "\\b\\d{3}-\\d{2}-\\d{4}\\b",
        "\\b\\d{4}[- ]?\\d{4}[- ]?\\d{4}[- ]?\\d{4}\\b"
      ]
    }
  }
}

This policy runs as an outbound policy, meaning it intercepts data after your handler processes it but before it leaves the gateway — whether that data is heading to an LLM provider, being returned to an AI agent, or flowing back to a client application.

Prompt injection detection as a complementary layer

PII leakage and prompt injection are closely related threats. A malicious prompt injection could instruct the model to “list all customer names and email addresses from the context” — turning a prompt injection into a PII exfiltration attack.

The Prompt Injection Detection policy uses a lightweight agentic workflow to analyze content for prompt poisoning attempts. It blocks malicious content with a 400 response before it can reach a model:

{
  "name": "prompt-injection-detection",
  "policyType": "prompt-injection-outbound",
  "handler": {
    "export": "PromptInjectionDetectionOutboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "apiKey": "$env(OPENAI_API_KEY)",
      "model": "gpt-3.5-turbo"
    }
  }
}

Note that the Prompt Injection Detection policy is available as part of Zuplo’s enterprise plans and is free to try on any plan for development purposes.

Combining secret masking with prompt injection detection on the same route gives you defense in depth — PII is redacted from legitimate traffic, and malicious attempts to extract PII are blocked entirely.

Custom PII detection with TypeScript policies

For domain-specific PII that doesn’t follow standard patterns — medical record numbers, internal employee IDs, financial account formats specific to your industry — Zuplo’s Custom Code Outbound policy lets you write PII detection logic in TypeScript:

import { ZuploContext, ZuploRequest } from "@zuplo/runtime";

// Define your domain-specific PII patterns
const PII_PATTERNS: Record<string, RegExp> = {
  medicalRecordNumber: /\bMRN-\d{8,12}\b/g,
  internalEmployeeId: /\bEMP-[A-Z]{2}\d{6}\b/g,
  accountNumber: /\bACCT-\d{10,14}\b/g,
};

export default async function piiRedactionPolicy(
  response: Response,
  request: ZuploRequest,
  context: ZuploContext,
): Promise<Response> {
  const body = await response.text();
  let sanitized = body;

  for (const [piiType, pattern] of Object.entries(PII_PATTERNS)) {
    const matches = sanitized.match(pattern);
    if (matches) {
      context.log.warn(
        `Detected ${matches.length} instance(s) of ${piiType} in response`,
      );
      sanitized = sanitized.replace(
        pattern,
        `[${piiType.toUpperCase()}_REDACTED]`,
      );
    }
  }

  return new Response(sanitized, {
    status: response.status,
    headers: response.headers,
  });
}

This approach gives you complete control over what gets detected and how it’s handled. You can log detections for audit purposes, apply different redaction strategies for different PII types, or even route requests differently based on whether PII is detected.

Combining policies on a route

In practice, you’ll want multiple layers of protection on your AI-facing routes. Here’s how to wire secret masking, custom PII detection, and prompt injection detection together in your route definition (routes.oas.json):

{
  "policies": {
    "inbound": [],
    "outbound": [
      "pii-masking-policy",
      "custom-pii-redaction",
      "prompt-injection-detection"
    ]
  }
}

Outbound policies execute in order, so the secret masking catches known patterns first, your custom policy handles domain-specific PII, and the prompt injection detector runs last as a final safety net. This layered approach ensures that sensitive data is caught regardless of its format or origin.

Beyond redaction: complementary strategies

PII redaction at the gateway is the foundation, but a mature data protection strategy for AI APIs includes additional layers.

Audit logging

Every PII detection event should be logged for compliance and incident response. Zuplo’s policy pipeline lets you add logging alongside redaction — recording what was detected, when, on which route, and for which consumer — without exposing the actual PII in the logs.

Data residency with edge deployment

For GDPR compliance, where data is processed matters as much as how it’s processed. Zuplo runs at the edge across 300+ data centers worldwide, which means PII sanitization happens close to the user — reducing the distance sensitive data travels before being redacted. For strict data residency requirements, Zuplo’s dedicated deployment options allow you to pin processing to specific regions.

Rate limiting and access controls

Limit who can make AI API calls and how often. An attacker trying to exfiltrate PII through an AI endpoint needs volume to be effective. Combine PII detection with per-consumer rate limiting and API key authentication to reduce the blast radius of any attempted data extraction.

Request validation

Validate the structure and content of incoming requests before they reach your AI pipeline. JSON schema validation can reject requests that include fields you don’t expect — an early filter that reduces the surface area for PII exposure.

Simplifying PII protection at the gateway

Some approaches to AI data sanitization tie you to specific infrastructure decisions — requiring Kubernetes clusters, control plane deployments, and significant operational overhead just to redact an email address from a prompt.

Zuplo takes a different approach. PII protection is a policy configuration on your managed gateway. You define your redaction rules, apply them to your routes, and deploy. No infrastructure to manage, no containers to orchestrate, no clusters to maintain.

For standard patterns, it’s a single policy in your policies.json. For domain-specific PII, it’s a TypeScript function. For enterprise-scale deployments, the same policies work across your AI Gateway and MCP Gateway from a single control plane — covering every LLM interaction and every MCP tool call in your organization.

The choice is between PII protection as an infrastructure project or PII protection as a policy toggle. Your compliance team doesn’t care which approach you choose, but your engineering team will.

Start building your PII protection strategy today. Sign up for a free Zuplo account and add secret masking to your first AI route in minutes.