Are you ready for Worldwide AI Legislation?
EU AI Act enforces 2 August 2026. GDPR and UK GDPR are already biting. The penalties are real.

What AI Compliance Proxy does

The AI Compliance Proxy is a local HTTPS proxy bound to `127.0.0.1:8377`. Point your AI agent at `http://localhost:8377/<provider>/...` instead of the upstream URL; every LLM call now passes through. The proxy receives the request, scans the whole payload (text + ~23 document formats + image OCR), replaces personal data with reversible session-scoped tokens, forwards the redacted request, restores tokens in the response, and writes an Ed25519-signed receipt to its own Merkle-chained ledger. Provider API keys are held in the proxy (AES-256-GCM at rest); the agent never sees the upstream key. Multi-modal, multi-provider (Anthropic, OpenAI, Google, xAI), and offline-verifiable end to end.

How it actually works

You are running an AI coding agent. It reads a file with a customer's email in it. It sends that file to Claude or GPT-5. The personal data has left your machine, without a record, without redaction, without consent, without any technical control. The AI Compliance Proxy is the wire-layer answer to that problem: it sits between your AI agent and the LLM provider, sees everything that hits the wire, text, documents, images, and only the redacted version ever leaves the machine. Regardless of which file the agent read, which tool it called, or which format it packaged the data in.

It is a local HTTPS reverse proxy, every LLM call your agent makes goes through it. Bind your agent to http://localhost:8377/anthropic/... instead of https://api.anthropic.com/...; the proxy receives the request, scans the whole payload (text + documents + images), replaces personal data with reversible session-scoped tokens, forwards the redacted request upstream, restores the tokens in the response, and writes an Ed25519-signed receipt to its own ledger. Your agent sees the original payload; the LLM provider sees a redacted one. The wire has the redacted version recorded in a signed chain any third party can verify offline. This is what stops your agent from leaking personal data to a third-party AI provider, regardless of which file it read or which tool it called.

What is intercepted. Default port 127.0.0.1:8377. Four URL prefixes route to four upstreams, /anthropic/* → api.anthropic.com, /openai/* → chatgpt.com (OpenAI / Codex API), /google/* → Google Gemini, /xai/* → api.x.ai. Pass-through TLS to the upstream (rustls with webpki roots, HTTP/1.1 and HTTP/2). Request and response bodies are buffered (not streamed) so the PII scanner can see plaintext. Body size cap 4 MB; decompressed size cap 16 MB (defends against decompression-bomb DoS); concurrent request cap 32. Inbound decompression is zstd only, the format Codex CLI sends. gzip and deflate are not supported; a non-zstd Content-Encoding fails closed with a clear error rather than risk forwarding unscanned plaintext.

API-direct authentication only. The Compliance Proxy intercepts traffic through the standard provider API endpoints (api.anthropic.com, api.openai.com, etc.) and requires your AI agent to authenticate with an API key, ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, XAI_API_KEY. It does NOT support consumer subscription authentication: Claude Pro, Claude Max 5x, Claude Max 20x, ChatGPT Plus, ChatGPT Pro.

Why the OAuth restriction. Consumer subscriptions authenticate via OAuth, your CLI does a browser login flow against claude.ai or chatgpt.com, gets back an OAuth token tied to your monthly subscription, and uses that token for every request. As of Anthropic's February 2026 Consumer Terms of Service update, routing OAuth-subscription credentials through any third-party tool or proxy is explicitly prohibited, the wording is "intended exclusively for Claude Code and claude.ai." OpenAI's subscription flow operates on a similar model. This is a Terms-of-Service restriction, not a technical limitation: even if the wire-level pathway worked, routing your Claude Max OAuth token through the Compliance Proxy would put you in breach of the upstream provider's consumer ToS.

For the AI Compliance Proxy to work, your agent must authenticate with an API key from the developer console (console.anthropic.com / platform.openai.com). This switches you to pay-per-token API billing rather than the flat-rate monthly subscription. For compliance-driven buyers this is usually already the path you want: API billing gives you predictable per-call cost attribution, organisational RBAC, retention and residency controls (data-handling addendum, BAA for healthcare, EU residency for GDPR), and the same audit trail every regulator expects. OAuth subscriptions are designed for individual developer convenience, not for organisational compliance posture.

Practical migration. If you are currently using Claude Code through Claude Max, generate an Anthropic API key, unset the OAuth login (unset CLAUDE_CODE_OAUTH_TOKEN), set ANTHROPIC_API_KEY=<key> and ANTHROPIC_BASE_URL=http://127.0.0.1:8377/anthropic, your agent now routes through the proxy. Same pattern for OpenAI / Codex CLI with OPENAI_API_KEY plus OPENAI_BASE_URL. The proxy reports any unsupported auth attempt with a clear error rather than silently failing.

Plan-name reference (May 2026). Consumer / OAuth, NOT supported by the proxy: Claude Free, Claude Pro $20/mo, Claude Max 5x $100/mo, Claude Max 20x $200/mo, ChatGPT Free, ChatGPT Plus $20/mo, ChatGPT Pro $200/mo. API-direct, supported by the proxy: Anthropic API Key (pay-per-token), OpenAI API Key (pay-per-token), Google AI API Key, xAI API Key. Team and Enterprise plans on both providers typically include API key access alongside subscription seats, check your admin console.

Provider key custody, the agent never sees the upstream key. You give the proxy your Anthropic, OpenAI, Google, or xAI API key via twira gateway keys store <provider>, the key is read from stdin so it never appears in shell history. The proxy stores it encrypted at ~/.Twira/gateway/keys/{provider}.enc using AES-256-GCM (12-byte nonce + 16-byte auth tag), with the 32-byte encryption root in ~/.Twira/gateway.secret (file mode 0600 on Unix). On every request the proxy decrypts the key in memory only long enough to inject it as the Authorization or X-API-Key header for the upstream call, then drops it. The agent never sees the upstream key, it only knows about the local proxy URL. Rotate or revoke a key by running twira gateway keys store again, no sweep across every dev machine.

PII detection depth. The wire surface is broad, text, documents in many formats, images, so the detection stack is correspondingly broad:

• ~50 text patterns, email, phone, SSN, IBAN, NHS number, passport, NINO, IP, MAC, payment card, crypto wallet, VAT, SWIFT, vehicle registration, driving licence, plus API keys for AWS, GitHub, Slack, OpenAI, Anthropic, Google.

• ONNX Named Entity Recognition, names, locations, organisations not matched by any pattern.

• GDPR Article 9 special-category classifier, health, political opinion, religious belief, sexual orientation, biometric, genetic data. Article 9 is the highest-sensitivity category under GDPR; the Standard posture tags-but-keeps Article 9 content; the Strict posture redacts it (the default for Hospital, Bank, and Government deployment profiles).

• OCR with face / handwriting / signature detection, text extraction from JPEG, PNG, TIFF, WebP, BMP, GIF embedded in payloads, plus face detection, handwriting recognition, and signature detection (face_detection and handwriting_detection default to true).

• Document parsing across ~23 formats, DOCX, XLSX, PPTX, ODT, ODS, ODP, PDF (with image-region redaction), RTF, EML, MSG, Jupyter notebooks, CSV, TSV, JSON, YAML, XML, HTML, MHTML, EPUB, plus legacy Microsoft binary formats (DOC, XLS, PPT). PDF metadata and embedded image OCR included.

• Unreadable-scan fallback, when OCR confidence is too low (handwriting in non-Latin scripts, badly degraded scans), the page is blacked out and flagged for human review. Fails closed.

• Posture profiles, Standard / Strict / Lenient × Hospital / Bank / Government / General / Dev. Posture floors the deployment profile so a Hospital deployment cannot be downgraded to Lenient.

The mapping is session-scoped and persisted with a TTL, default 90 days (pii_retention_hours: 2160). The same input token gets the same redacted form within a session, so the LLM's replies remain semantically coherent. Mappings are deleted on twira gateway gdpr-purge [session_id]. System-prompt hint: if PII was redacted, the proxy appends a confidentiality note to the upstream system prompt so the model does not over-interpret the tokens. Honest signalling rather than silent rewrite.

Signed receipts, Ed25519 per interaction. Every full request/response round-trip produces one signed receipt. Canonical 7-field JSON (alphabetically sorted): chain_hash, content_hash (request_hash:response_hash), cost_microcents, model, session_id, timestamp, tokens. Signed with the device key, the same Ed25519 key used for the audit chain manifest, with the public-key fingerprint recorded alongside. Receipts are written to a SHA-256 Merkle chain in gateway_interactions: each receipt's chain_hash depends on the previous one, so tampering with any single receipt invalidates every subsequent hash. Anyone with the public key plus a copy of gateway.db can verify the whole ledger offline. CLI: twira gateway verify.

Two parallel signed chains, by design. Twira has two separate signed ledgers and they answer two different compliance questions. The audit chain (audit_events in audit.db) answers "what did the agent do in my code?", every file read, every diff written, every diagnostic run, every tool called, with hunk-level attribution. The Gateway chain (gateway_receipts plus gateway_interactions in gateway.db) answers "what data crossed the wire to which provider?", every LLM request, every redaction, every response, with a per-interaction signed receipt. Both are Pro-gated. Both are Ed25519-signed, both are SHA-256 Merkle-linked, both verify offline. They are not cross-linked by foreign key, a deliberate design decision because the two questions are genuinely independent. An auditor asking "who wrote this code?" gets the audit chain. An auditor asking "what data left the building?" gets the Gateway chain. Together they cover both the what-happened and what-data-was-involved questions an auditor, regulator, or insurer would ask.

Body storage modes, the privacy-vs-evidence dial. GatewayConfig.body_storage has three levels, controlled per-deployment:

• None, metadata only. The receipt records the chain hash, token count, cost, and timestamps; nothing about request/response content. Most private. Use for the highest-sensitivity deployments where even hashes are too much.

• Hash (default), SHA-256 content hashes of request and response. Proves that something specific was sent without storing the content itself. Chain integrity is provable but the bodies are not retrievable. When asked "does the Gateway store my conversations?", the honest answer is: by default, only the SHA-256 hashes, never plaintext, unless you explicitly enable body_storage: redacted.

• Redacted, full request/response bodies with PII already redacted. Richest audit trail. Use when you need to reconstruct what the agent saw, but only after the proxy has removed personal data. Stored zstd-compressed in gateway_body_blobs.

Privacy mode. privacy_mode: true quantizes every timestamp to a 15-minute bucket. Defends against timing-based correlation attacks on the audit log (correlating the chain against external network traces). Useful in privacy-by-design deployments where exact-timing leakage is itself a concern.

GDPR purge, preserves chain integrity. twira gateway gdpr-purge [session_id] deletes all PII mappings for that session AND nullifies the stored bodies. The chain hashes are preserved, they were computed before the purge, so the integrity of the chain remains provable. What you can no longer do is recover the original PII (mappings gone) or the original body (nulled). This is the right-to-erasure pattern: forget the personal data, keep the proof that the data was processed properly. The purge itself is logged as a timestamped configuration entry, so a regulator asking "was this DSAR honoured?" has a record.

Posture profiles, industry presets. twira gateway config exposes deployment_profile (Hospital / Bank / Government / General / Dev) × pii_posture (Strict / Standard / Lenient):

• Hospital floors to Strict, Article 9 health data is redacted, not tagged.

• Bank floors to Strict, Article 9 plus financial data is redacted.

• Government floors to Strict, Article 9 plus classification markers redacted.

• General defaults to Standard, Article 9 is tagged-but-kept (auditable, but not removed).

• Dev defaults to Lenient, patterns only, no NER, no Article 9, for development environments where false positives are more painful than missed detections.

The posture floor means you cannot accidentally downgrade Hospital to Lenient, the profile wins.

Lifecycle commands. twira gateway start [--port 8377] [--foreground] starts the daemon. Foreground mode keeps it in the terminal; default mode detaches via direct spawn. A lease file at gateway.lease records the PID, port, nonce, started_at, and config hash. twira gateway status reads the lease, checks the PID is alive (kill(0) on Unix, GetExitCodeProcess on Windows), reports running or stopped. twira gateway ensure is an idempotent start (no-op if already running and healthy). twira gateway stop sends a nonce-authenticated POST to /__twira/shutdown on the gateway's port, waits up to 5 seconds for clean exit, cleans up the lease. twira gateway enable / disable sets auto_start: true/false in Twira.json so the gateway starts with each session (default off; explicit consent required for ToS compliance). twira gateway check is a provider-reachability test against api.anthropic.com:443, api.openai.com:443, api.x.ai:443.

ML model management. twira gateway model download / list / delete manages locally cached NER, classifier, and embedding models used by the PII engine. The actual model registry lives in the twira-redact crate; the gateway proxies model-management commands through. Feature-gated behind the "ner" build feature so deployments that do not need NER do not download multi-hundred-MB ONNX models.

Trial path. Use the standard Twira Pro trial, twira login, which unlocks the AI Compliance Proxy along with every other Pro feature for 14 days. No card — just a quick sign-in (Google, GitHub, or an email link). (Legacy: twira gateway trial <email> still exists as a CLI command for backward compatibility, but the gating no longer distinguishes a Gateway-only trial from the full Pro trial.)

Licence model. As of 2026-05-20 the AI Compliance Proxy is part of Twira Pro, no separate SKU, no separate purchase. The legacy gateway_addon boolean on the licence schema is retained for backward compatibility but is no longer consulted by the gating layer; check_gateway_licence delegates to check_feature("ai_compliance_proxy", state), which resolves to the standard Pro tier check. A Pro licence gives you Diagnose, Audit, Lore, Masterplan, multi-agent Team, and the AI Compliance Proxy, one subscription, one price.

Tier and setup. Included in Twira Pro ($29.99/mo, 14-day free trial, no card required). Setup: twira login to start the Pro trial, then twira gateway keys store anthropic (and equivalents) to give the proxy your provider keys, then twira gateway start to launch on port 8377. Point your agent at http://localhost:8377/<provider>/ and it Just Works.

What it isn’t

• ·Requires API-direct authentication. Does NOT support consumer OAuth subscriptions, Claude Pro, Claude Max, ChatGPT Plus, ChatGPT Pro, per Anthropic's Feb 2026 Consumer ToS. Generate an API key from console.anthropic.com / platform.openai.com first.
• ·Wire-layer enforcement. Catches everything your agent sends to the LLM provider, regardless of which tool read the data, which file it came from, or which format it was packaged in.
• ·Reversible tokens are session-scoped and persisted with a 90-day default TTL. `twira gateway gdpr-purge <session_id>` deletes the mappings and nullifies the stored bodies while preserving chain integrity for proof.
• ·Body storage defaults to `Hash`, SHA-256 of request and response, no plaintext. `Redacted` mode stores the redacted bodies (useful for richer audit). `None` mode stores metadata only.
• ·Inbound decompression is zstd only today. gzip and deflate fail closed with a clear error rather than risk forwarding unscanned plaintext.
• ·Included in Twira Pro, the AI Compliance Proxy ships as part of Pro $29.99/mo (full consolidation 2026-05-20). Pro users get the wire-layer PII engine, signed receipt chain, and provider-key custody as part of the same subscription that powers Diagnose, Audit, Lore, Masterplan, and the rest of the Pro toolbelt.