Long-document content
Contracts, transcripts and support histories pasted in full for summarization or analysis, carrying identifiers throughout rather than in one field.
Solution
Protect customer data before it reaches Claude
Anthropic Claude data privacy for AI applications.
Detect and mask identifiers in the prompt — including long-context documents and retrieved passages — forward only masked text to the Anthropic API under your own credentials, and restore the original values in the response.
How can an AI application protect customer data before sending prompts to Claude?
Place a privacy layer between the application and the Anthropic API. The layer detects sensitive values across the entire assembled prompt — including long-context documents and retrieved passages — replaces them with deterministic placeholders, forwards only the masked text to Claude under your own credentials, and restores the protected values in the response.
Summary
The short version
What is the problem?
Claude's typical workloads — long-document analysis, agentic and internal tooling, large retrieved context — put more raw material into a single request than short-context use cases, and that material often carries customer or employee identifiers the model does not need.
How is it solved?
Detect and mask those values at a gateway before the Anthropic call, then rehydrate the response in memory so the application still sees real data.
When should this approach be used?
When Claude prompts routinely include full documents, chat histories or retrieved context, when an enterprise buyer asks what leaves your systems, or when you run Claude alongside other providers and want one control point.
What are the limitations?
Masking is best-effort over a supported entity set, does not certify compliance, does not prevent prompt injection, and cannot govern what Anthropic does with what it still receives.
Problem
The data-exposure problem, at Claude's scale
Claude is frequently chosen for exactly the workloads that carry the most raw data per request: summarizing a long contract, reasoning over an entire support history, driving an agent that pulls several internal documents into context, or answering a question against a large retrieved passage. A large context window is a genuine capability advantage — and it is also the distinctive risk compared with short-context calls. Where a short prompt might carry one or two identifiers, a long-context prompt can carry dozens, embedded in material nobody individually reviewed before it was pasted in.
The practical consequence usually shows up commercially before it shows up as an incident: an enterprise prospect asks what data your Claude-powered features send to Anthropic, and the honest answer is "whatever document or thread the feature was pointed at". See enterprise-ready AI for what buyers expect instead.
The question a security reviewer asks is not "is Claude secure?" — it is "how much of that document did your application actually need to send, and how do you know?"
Exposure surface
What data may appear in Claude prompts
Retrieved context (RAG)
Large retrieved passages that carry identifiers from the source document even when the user's own question contains none.
Agentic / internal tooling
Multi-step agents and internal copilots that assemble context from several systems, compounding what any single request contains.
Account and transaction references
Customer ids, ticket numbers, invoice and payment references embedded in the documents being analysed.
Financial and national ids
Card numbers, IBANs and national identifiers appearing inside pasted records or forms.
Developer secrets
API keys, tokens and connection strings pasted into debugging or internal-tooling prompts.
Common misconception
Why provider settings alone are not application-level privacy
Anthropic's own privacy, security and enterprise controls are worth configuring, and for some organisations they are a necessary part of the answer. They are a different control from data minimization, and they answer a different question.
Framework
What each control can and cannot govern
- 01
Provider settings govern the provider
They describe what Anthropic does with data it has already received. They cannot reduce what your application chose to send.
- 02
Scope is per provider and per surface
Settings, defaults and contractual terms differ between providers and between product surfaces, and have to be re-verified whenever either changes.
- 03
Intermediate hops are out of scope
Logs, traces, analytics and prompt-debugging tools sit between your application and Anthropic and are governed by neither.
- 04
Verification is contractual, not observable
You are relying on a stated policy. Masking before egress produces evidence you can demonstrate from your own side of the boundary.
- 05
Minimization survives provider changes
If you add a second provider alongside Claude, controls applied before the call still apply. Provider-specific settings do not transfer.
The two are complementary: configure Anthropic's controls correctly, and also reduce what has to be trusted to that configuration.
Provenance
About Anthropic-specific claims
Control 1
Detecting sensitive data before transmission
Minimization starts with detection: you cannot mask what you have not identified. Privian scans the assembled prompt — every message and every block of retrieved or pasted context, not just the latest user turn — for the supported entity set on each request, with no cross-request state.
- Personal identifiers: names, emails, phone numbers, IP addresses
- Financial and national ids: card numbers, IBANs, US SSN, Canadian SIN
- Developer secrets: JWTs, provider API keys, GitHub tokens, AWS keys
- Env-style assignments and prefixed secret tokens
The current catalog and its known gaps are listed on the PII masking page. Detection is best-effort and should be evaluated against your own data — including your longest documents — before you rely on it.
Control 2
PII masking before the Claude call
Each detected value is replaced with a deterministic, type-aware placeholder for the duration of the request — PERSON_1, EMAIL_2, ACCOUNT_1. In a long document-analysis prompt the same value maps to the same placeholder everywhere it recurs, so Claude can still track who did what across the document while the identifying value never crosses the boundary.
Application sends to Privian
Summarize the key obligations in this
support escalation thread and flag any
open risk.
---
From: Sarah Chen (sarah.chen@example.com)
Account: ACC-88213
"Following up on invoice INV-4821 —
please confirm the refund to card
ending 4242 by Friday."
---Privian sends to Anthropic
Summarize the key obligations in this
support escalation thread and flag any
open risk.
---
From: PERSON_1 (EMAIL_1)
Account: ACCOUNT_1
"Following up on invoice INV-4821 —
please confirm the refund to card
ending CREDIT_CARD_1 by Friday."
---Control 3
Prompt privacy as a request-path property
Prompt privacy means the controls live in the request path rather than in each feature that happens to call Claude. A new document-analysis or agent feature added six months from now inherits the same treatment as the first one, because the control is attached to the egress point and not to the code that assembled the prompt. The concept is described in more depth under prompt privacy.
Control 4
A controlled, documented data path
Because every Claude call goes through one place, the data path is describable hop by hop: what enters, what is transformed, what is forwarded, what is stored. That description is what a security reviewer actually asks for, and it is published per-hop on the data path page.
Control 5
Rehydration on the way back
If masking were one-way, every consuming feature would have to be rewritten to handle placeholders. Instead the mapping is held in memory for the life of the request, applied in reverse to Claude's response, and then discarded. Your application receives the reply with real names, accounts and addresses; Anthropic never saw them. Unknown placeholders in a response pass through untouched. See rehydration for the mechanics.
Control 6
Retention considerations
Retention has to be answered at each hop, not once. Three of them are usually in scope for an AI feature built on Claude:
Your application
Prompt logs, traces and analytics are often the largest retained copy of long-context content, and they are entirely under your control.
The privacy layer
Privian does not persist raw prompts or responses. Only structural counters are retained for billing and observability.
The model provider
Governed by Anthropic's own terms and your configuration — check Anthropic's current documentation rather than a summary.
Multi-provider reality
Claude is rarely the only provider
Most teams that run Claude in production also run at least one other model provider — a second model for a different task, a fallback for availability, or a cheaper model for high-volume calls. Provider-level privacy configuration does not transfer between them: settings, defaults and contractual terms are reviewed and applied per provider, and a control configured for Anthropic says nothing about what a second provider receives.
A gateway-level control applied before the call is the one piece that does transfer, because it sits in front of every provider rather than inside any one of them. See the LLM gateway product page for how routing and masking work across providers, and compare Privian against other gateway approaches.
Commercial impact
What this changes in an enterprise security review
Reviewers rarely ask whether you use Claude. They ask what you send, who holds the credentials, what is retained and how you would prove it — and for long-context use cases, how much of a document actually left your systems. Masking before egress changes the answers from intentions to architecture:
Framework
Answers a reviewer can verify
- 01
What leaves our systems?
Masked prompts containing placeholders for the supported entity set, rather than raw documents or records.
- 02
Who holds the provider credentials?
You do — BYOK, encrypted at rest, decrypted in-process at request time.
- 03
What does the vendor retain?
No raw prompts or responses; structural counters only.
- 04
How is this enforced?
At one egress point that every Claude-calling feature passes through, rather than per feature.
- 05
What is out of scope?
Compliance certification, prompt-injection defence, and anything the detector does not support.
The document set buyers usually request is collected in the enterprise trust package.
Architecture
Implementation architecture
- 1
Application — Your code calls the OpenAI Chat Completions shape as usual, with the base URL pointed at Privian and a Privian gateway key.
- 2
Privian privacy layer — The full assembled prompt — including retrieved and pasted context — is scanned, supported entities are replaced with deterministic placeholders, and the request-scoped mapping is held in memory.
- 3
Anthropic — The masked request is forwarded to Claude using your own encrypted credentials; usage bills against your own Anthropic account.
- 4
Privian rehydration — Placeholders in the response are replaced with the original values from the in-memory mapping, which is then discarded.
- 5
Application — Your code receives an ordinary OpenAI-shaped response containing real values — no placeholder handling required downstream.
In practice the integration change is the base URL, the key and the model prefix:
from openai import OpenAI
client = OpenAI(
base_url="https://api.privian.io/v1",
api_key=os.environ["PRIVIAN_GATEWAY_API_KEY"],
)
resp = client.chat.completions.create(
model="anthropic/claude-<model>",
messages=[{"role": "user", "content": prompt}],
)The model id above is illustrative — check supported models for which Claude models are currently addressable, and the API reference for full request and response shapes.
Fit
When this pattern is useful — and when it isn't
Useful when
- Claude features analyse long documents, threads or retrieved context
- Agentic or internal tooling assembles prompts from several systems
- Enterprise buyers are asking what your Claude features transmit
- You run Claude alongside another provider and want one control point
- Internal tools risk pasted keys and tokens reaching the provider
Less useful when
- The task genuinely requires the literal identifying value
- Your prompts contain no personal or sensitive data at all
- You need native streaming, tool calling or multimodal input today
- Your requirement is prompt-injection defence rather than data minimization
- You need a certification rather than a technical control
Scope
What this does NOT solve
FAQ
Frequently asked questions
- How can an AI application protect customer data before sending prompts to Claude?
- Route Claude calls through a privacy layer that detects sensitive values in the assembled prompt — including any retrieved documents or long-context material — replaces them with deterministic placeholders, forwards only the masked text to the Anthropic API under your own credentials, and restores the original values in the response.
- Is Claude safe for customer data?
- That depends on your agreement with Anthropic, your account configuration and the sensitivity of the data — not something a vendor can answer generically. What you can control architecturally is how much identifying data has to leave your boundary in the first place, regardless of how that provider question resolves.
- Does Anthropic retain API data?
- Retention behaviour depends on the product surface, your account configuration and your commercial terms, and it changes over time. Check Anthropic's current privacy policy and commercial terms rather than a third-party summary, including this one.
- Why does Claude's long context window matter for data exposure?
- A larger context window means each request can legitimately carry far more raw material — full documents, long chat histories, large retrieved passages — than a short-context call. More content per request means more identifiers per request, even when the user's own question contains none.
- Do Anthropic's enterprise or trust center settings remove the need for application-level controls?
- No. Those settings govern what Anthropic does with data it receives. They cannot govern what your application decides to include in a prompt, they do not apply to intermediate hops such as logging and analytics, and they have to be reconfigured and re-verified per provider.
- What data typically ends up in Claude prompts?
- Names, emails, phone numbers and account identifiers inside pasted documents or support threads; identifiers embedded in retrieved context for RAG and agentic tools; and, in internal engineering tools, API keys, tokens and connection strings pasted in for debugging.
- Does masking degrade Claude's document-analysis quality?
- Placeholders are deterministic within a request, so the same value maps to the same token throughout a long document and Claude can still reason about relationships between entities. Tasks that depend on the literal value — validating a specific account number's format, for example — are affected.
- How does this work with the OpenAI-shaped SDK if I'm calling Claude?
- Privian exposes an OpenAI Chat Completions-compatible, non-streaming endpoint at https://api.privian.io/v1. Point an OpenAI-shaped SDK's base URL there, use a Privian gateway key, and address models as anthropic/<model>. Check supported models before relying on a specific one — streaming, tool calling, JSON mode, multimodal input and the Responses API are not supported in the current beta.
- Who holds the Anthropic API credentials?
- You do. Privian uses BYOK: your Anthropic key is stored AES-GCM encrypted at rest and decrypted in-process at request time, and usage bills against your own Anthropic account.
- Does Privian store the prompts sent to Claude?
- No. Raw prompts and responses are not persisted. Only structural counters are retained for billing and observability.
Enterprise review
Built for enterprise review
Trust assets procurement and security teams routinely request.
Plans & pricing
Pricing for Claude-bound prompt privacy
BYOK, zero retention and masking before the provider call — including long-context and agentic workloads. Beta plans may change as the product matures.