Security and Privacy Concerns

Intermediate4 min

Zero data retention exists and its carve-outs are where teams get caught: some models require 30-day retention, and flagged content can be held for two years regardless. Adopting ZDR also disables CORS, so a browser-calling architecture becomes a rewrite.

#security

The questions an auditor asks

Two articles here cover attacks. Prompt injection is text arriving that should not steer the model, and context security is data sitting in the window that should not be there.

This page is the third thing, and it has no attacker. Someone asks where your customers' data goes, how long it stays, and who else touches it. The answers are mostly determined by contract terms and a few configuration choices, and they are easier to get right before launch than after.

Your provider is a subprocessor

The moment you send a prompt to a hosted model, a third party is processing your users' data. That is a fact about your architecture with consequences in whatever privacy regime you operate under.

Three things to establish and record:

What is retained, and for how long. Not the marketing summary; the terms.

Whether it trains a model. Anthropic's commitment is that "retained data is never used for model training without your express permission." Get the equivalent in writing from every provider you use.

Who the processor is. On Anthropic's own API, Anthropic. On Amazon Bedrock and Google Cloud, the cloud provider is the data processor, which changes whose terms govern and whose documentation you are relying on. Running the same model through a different platform is a different privacy answer.

Zero retention exists, with carve-outs worth reading

Anthropic offers zero data retention, and the shape of it is instructive because the exceptions are where teams get surprised.

ZDR applies to the Messages and Token Counting APIs for eligible features. It does not apply to the Console and playground, to consumer plans, to stateful resources whose transcripts persist until deleted, or to third-party integrations your request touches on the way through.

Two of the carve-outs have engineering consequences:

Some models require retention. Covered Models require 30-day retention and are unavailable under ZDR without express authorization. A request to one from an organization not configured for it returns a 400 invalid_request_error saying data retention must be enabled. So the compliance posture and the model menu are coupled, and the failure arrives as an error rather than a negotiation.

ZDR disables CORS. Organizations with ZDR cannot call the API from a browser and must route through a backend proxy. If your architecture assumed direct browser calls, adopting ZDR is a rewrite, not a setting.

Nothing is zero when something is flagged

The line to read twice: even with ZDR in place, a provider may retain data where required by law or where automated trust and safety systems flag it, and flagged content may be retained for up to two years.

So "we have zero data retention" is not a statement you can make without qualification. What you can say is that content is not retained in the ordinary course, and that flagged content and legal holds are exceptions.

Say it that way to your own customers. A promise you cannot keep is worse than a narrower one you can.

The copies on your side

Context security makes this point and it belongs in a compliance review too. Your provider is one of several places the data lands.

Your observability backend holds prompts and completions if you record them. LLM observability covers that tension; the compliance version is that this store inherits every obligation the data came with, and it is usually the one nobody included in the data map.

Prompt caches, memory stores and any gateway in the path are the others. A gateway in particular is a processor you added, as Helicone notes about sitting in the request path.

A short pre-launch list

Five answers to have written down:

  1. Which providers process user data, and under whose terms
  2. What each retains, for how long, and whether it trains
  3. Whether ZDR or an equivalent applies, and which of your features it excludes
  4. What your own systems store, and for how long
  5. What you tell users, and whether it matches the four answers above

The last one is the one that fails. A privacy policy written before the observability stack existed will describe a system you no longer run.

Further reading

Knowledge check

Question 1 of 3

With ZDR in place, can you tell customers nothing is ever retained?

Sign in to save your progress and pick up where you left off.

Open this article on its own page

Also in Security and Privacy Concerns

1 article