OpenAI previews a way to police API misuse without reading the prompts

OpenAI said on 19 August that it is previewing Private Safety Processing, a system meant to catch misuse spread across a customer's API traffic without giving OpenAI's staff access to the prompts and responses involved. The company paired it with a restatement of its Zero Data Retention commitment for eligible API customers. The timing is not incidental: the two largest frontier labs are now publicly on opposite sides of the question of whether their most capable models can be sold with a no-logs guarantee at all.

What OpenAI says the system does

The entry in OpenAI's news feed describes two things: that Zero Data Retention — ZDR — remains available to eligible API customers, and that Private Safety Processing is being previewed as a route to what the company calls advanced AI safety without compromising data privacy. The mechanics come from TechCrunch's reporting, published the same day: rather than inspecting one session at a time, automated agents look for patterns across related interactions. The scenario it is built for is a user who splits a prohibited request into fragments distributed over many conversations, so that no single exchange trips a classifier. When a pattern matches, the system emits what TechCrunch describes as a narrowly defined signal identifying the type of activity, and OpenAI decides from that signal alone whether enforcement is warranted. The underlying text is not surfaced.

This is a preview to selected customers, not general availability. OpenAI's announcement page itself refuses automated clients, so everything below the feed summary — eligibility, which models are covered, how the signal is defined and bounded, when it ships — is reported rather than documented. Read it accordingly.

What ZDR actually covers today

OpenAI's data controls documentation is considerably more precise than the announcement language, and it is worth reading before assuming what the word 'zero' is doing. By default, every API request generates abuse-monitoring logs that may contain prompts, responses and classifier outputs, retained for up to 30 days. Approved customers can move to Modified Abuse Monitoring, which excludes customer content from those logs, or to Zero Data Retention, which does the same and additionally forces the `store` parameter on `/v1/responses` and `/v1/chat/completions` to `false` regardless of what the request asks for. Both require prior approval from OpenAI and acceptance of extra contractual terms, and both leave the customer responsible for policing their own users.

The same page spells out two overrides that matter here. Under Eyes Off, OpenAI reserves the right to make specific models ineligible for ZDR or Modified Abuse Monitoring for a specific customer, with advance written notice; content is then retained but excluded from human review unless the law requires otherwise. Under Safety Retention, the same override applies where it is, in the documentation's words, reasonably necessary to investigate or prevent severe risk activity — and in that case OpenAI may retain and have humans review content its classifiers flag as potentially violating the usage policies. Private Safety Processing is most usefully read as an attempt to reduce how often those overrides have to be invoked, not as a replacement for them.

Why Anthropic went the other way

Anthropic's API and data retention documentation takes the opposite position for its strongest models, and states it without hedging. Claude Fable 5 and Claude Mythos 5 are designated Covered Models, require 30-day data retention, and are not available under ZDR. The enforcement is mechanical rather than contractual: a request to Fable 5 from an organisation whose retention configuration does not meet the requirement returns a `400 invalid_request_error`. An organisation with a standing ZDR arrangement can enable 30-day retention for a single workspace to unlock those models there, while every other workspace stays at zero.

The practical result is that a buyer with a hard no-retention requirement can use Claude, but not Anthropic's frontier tier. TechCrunch frames OpenAI's announcement as an attempt to one-up that position; that is TechCrunch's framing of the competitive timing rather than something OpenAI said. Anthropic's answer in the same piece is that its human review runs through a controlled access path, with tamper-proof logs of every review session — an argument about the integrity of retention rather than its avoidance.

What changes for people building on these APIs

• If you are procuring under a no-logs requirement, model choice and data policy are now one decision, not two. On Anthropic's side that is already enforced in code — the API returns 400 rather than degrading quietly. Check the retention configuration of the workspace, not just the organisation.
• Cross-session pattern detection changes what a benign workload can look like from outside. An agent that decomposes a task into many small independent calls is, structurally, the same shape as the evasion this is designed to catch. No lab has published how it distinguishes the two.
• 'Zero retention' has never meant 'no monitoring' on OpenAI's platform, and the documentation says so plainly. If your compliance story depends on that phrase, read the Eyes Off and Safety Retention clauses rather than the marketing page.
• Nothing here is available to build against yet. There is no shipped feature, no configuration flag, and no published specification for the signal.

The claim underneath all of this — that you can detect coordinated misuse across sessions while learning nothing about the content of any of them — is a strong one, and it is exactly the kind of claim that needs a technical description and outside review before it means anything. OpenAI has published neither. Until it does, the honest summary is that OpenAI has stated an intention that would be significant if it holds, and that Anthropic has, for now, decided the same problem is not solvable that way for its frontier models.