Skip to content
CLAUDEXIA
enru
SECURITY

Claude API Security and Compliance in 2026: PII, Logging, and Data Residency

Where do your prompts actually go? Anthropic's data policy, gateway logging, PII handling, and how Claudexia's EU presence helps with GDPR — practical patterns.

"Is it safe to send this to Claude?" is the question every security review eventually lands on. The honest answer is: it depends on what this is, what path it takes, and what you do on your side. This guide walks through the real data flow when you call Claude through a gateway like Claudexia, what Anthropic's commercial data policy actually says in 2026, and the practical patterns teams use to keep PII, secrets, and regulated data under control.

The actual data flow

When your application calls Claude through Claudexia, the request takes a specific path:

  1. Your client (server, edge function, mobile app) builds the request body.
  2. Claudexia gateway receives it over TLS, authenticates the API key, applies budget and rate limits, logs metadata for billing, and forwards the request to Anthropic.
  3. Anthropic processes the request on its inference infrastructure and returns the response.
  4. Gateway streams the response back, records token usage for billing, and your client receives the output.

Two important things to note. First, the request body — your prompt and any attachments — passes through the gateway in plaintext (inside the TLS tunnel). Second, both the gateway and Anthropic write logs. What ends up in those logs is the heart of the compliance question.

Anthropic's commercial data policy

For paid API traffic, Anthropic's published commercial terms in 2026 say three things that matter for compliance:

  • No training on API data. Inputs and outputs from commercial API calls are not used to train Anthropic's models. This is contractual, not a setting you toggle.
  • 30-day default retention. Requests and responses may be retained for up to 30 days for abuse monitoring and operational debugging, then deleted.
  • Zero data retention (ZDR) available. Eligible enterprise customers can request ZDR, which removes the 30-day window. Eligibility and configuration are negotiated through Anthropic's enterprise sales motion.

ZDR matters when you're handling highly regulated data (HIPAA-like records, financial PII at scale, legal privilege). For most product teams, the default 30-day commercial retention is acceptable as long as you're not piping unredacted secrets into prompts.

Gateway logging — minimize what you log

Claudexia logs request and response metadata for billing accuracy: model used, input/output tokens, latency, status code, and the API key fingerprint. Full prompt bodies are not retained beyond what's needed for short-term debugging, but you should still treat the gateway as a system that briefly sees your data.

Practical implications:

  • Don't put credentials, raw OAuth tokens, or live session cookies into prompt bodies. If your agent needs them, fetch them server-side and use them in tool calls without echoing them into the model context.
  • If you're sending customer data, redact before the request leaves your service. The gateway is a transport layer, not your DLP boundary.
  • Your own application logs are usually the bigger leak. Many teams log the full prompt for debugging and then forget those logs exist for years. Audit your own log retention before worrying about anyone else's.

PII redaction — two-layer pattern

The pattern that holds up in production is layered: a cheap deterministic pass first, an LLM pass second when the deterministic pass isn't enough.

Layer 1: regex pre-pass. Before the prompt leaves your service, run regex over the input for the obvious things:

const REDACTORS: [RegExp, string][] = [
  [/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi, "[EMAIL]"],
  [/\b(?:\d[ -]*?){13,19}\b/g, "[CARD]"],          // PAN-shaped digits
  [/\b\d{3}-\d{2}-\d{4}\b/g, "[SSN]"],              // US SSN
  [/\b\+?\d{1,3}[\s-]?\(?\d{2,4}\)?[\s-]?\d{3,4}[\s-]?\d{3,4}\b/g, "[PHONE]"],
];

function scrub(input: string): string {
  return REDACTORS.reduce((acc, [re, tag]) => acc.replace(re, tag), input);
}

This catches 80% of accidental PII for almost zero cost.

Layer 2: LLM redaction with Haiku. For free-text fields where users paste arbitrary content (support tickets, contract clauses, medical notes), call Claude Haiku as a cheap pre-pass:

const redacted = await anthropic.messages.create({
  model: "claude-haiku-4.5",
  max_tokens: 2000,
  system: "Replace any names, addresses, account numbers, dates of birth, and medical identifiers with [REDACTED-NAME], [REDACTED-ADDRESS], etc. Preserve everything else verbatim. Output only the redacted text.",
  messages: [{ role: "user", content: userInput }],
});

Haiku at gateway pricing is cheap enough that running it as a redaction filter in front of Sonnet or Opus is economically reasonable for sensitive workloads. The base URL stays the same:

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic({
  apiKey: process.env.CLAUDEXIA_API_KEY,
  baseURL: "https://api.claudexia.tech/v1",
});

Combine the layers: regex first (deterministic, audit-friendly), Haiku second only when the field is free-text and high-risk. Log the redaction itself so you can prove what was removed.

EU presence and GDPR

For teams with European users, transit and processing geography matters. Claudexia maintains EU-resident gateway infrastructure, which means:

  • Requests from EU clients hit an EU edge first instead of bouncing across the Atlantic before any policy is applied.
  • Gateway-side logs (billing metadata, rate-limit counters) stay in EU storage.
  • Your DPA chain is shorter — one processor agreement with Claudexia covering the gateway layer, plus Anthropic's terms covering inference.

This doesn't make Anthropic itself an EU-only processor — inference still runs on Anthropic's infrastructure, which is primarily US-based. What EU presence does is reduce transit hops, simplify your records of processing activities, and give you a contractual counterparty in your jurisdiction. For most B2B SaaS GDPR posture, that's sufficient. For data that genuinely cannot leave the EU, you need a different architecture (on-prem inference, EU-only models from other vendors, or a hybrid) — no commercial Claude deployment solves that today.

Key rotation hygiene

The single highest-leverage operational control is good key discipline:

  • One key per environment. Production, staging, CI, local dev, each batch job — separate keys. Never share.
  • Monthly rotation, automated. Generate the new key, deploy it, deactivate the old one after a 24-hour overlap. If rotation hurts, your secrets management is the problem to fix.
  • Virtual keys with budget caps. Claudexia supports per-key budget limits, model whitelists, and rate limits. Use them. A virtual key that can spend at most $50/day and only call Haiku is a much smaller blast radius than a master key with no limits.
  • Scope by purpose. The key your support bot uses should not be allowed to call Opus. The key your batch enrichment job uses should not be allowed to make low-latency requests. Encode the policy in the key configuration, not in your application code.

Audit logging on your side

Gateway logs are for billing and abuse. They are not your audit trail. On your side, log:

  • Which user or service initiated each request (correlation ID, user ID, tenant ID).
  • What model and which key was used.
  • Token counts and cost (pulled from the response headers Claudexia returns).
  • Whether redaction was applied and which redactors fired.
  • The hash of the input, not the input itself, if your retention policy forbids storing prompt bodies.

This gives you a complete record without storing sensitive content. When a regulator or auditor asks "did user X's data get sent to Claude on date Y", you can answer from your own logs without depending on anyone else's retention.

Threat model: stolen key

Assume a key will eventually leak — into a git commit, a CI log, a contractor's machine. The question is what an attacker can do with it before you notice.

With a master key and no caps: rack up four-figure bills overnight calling Opus on a loop, or worse, exfiltrate context if the key is used by an agent with tool access.

With a virtual key scoped to Haiku, capped at $50/day, rate-limited to 100 RPM, and tied to a specific source IP range: the worst case is a $50 bill and an alert that fires when the daily cap is hit. The blast radius is bounded by configuration, not by how fast you noticed.

This is the entire argument for virtual keys with caps: they convert "credential leak" from a critical incident into a routine alert.

Bottom line

Cloud LLM security is defense in depth, not a single switch:

  • Anthropic's commercial policy (no training, 30-day retention, ZDR available) handles the upstream layer.
  • Claudexia gateway with EU presence handles transit and policy enforcement.
  • Your redaction pipeline (regex + Haiku) handles what leaves your service.
  • Per-environment virtual keys with budget caps handle credential blast radius.
  • Your own audit logs handle the regulator question.

Each layer is cheap on its own. Stacked, they get you to a posture that survives a security review without theater. Pair this with the cost discipline from our Claude API pricing guide and you have both the unit economics and the compliance story in one shape.

← Back to all posts