In brief: Zero Data Retention, or ZDR, means that an approved API environment does not retain client requests and responses after processing in the provider’s logs or compatible application state. But that does not mean there is “no data” anywhere in the enterprise system: state may be stored in other functions, content may flow to third-party tools, and the company itself still needs a minimal activity log. The right architecture separates payload, application state, safety signals, and audit evidenceinstead of copying every prompt “just in case.”
This article is intended for executives, CTOs, CISOs, AI product owners, architects, and data teams. It explains OpenAI’s product announcement from August 19, 2026, and proposes a technical design approach. This is not legal advice, not a confirmation of compliance with 152-FZ, GDPR, HIPAA, or any other regulation, and not an independent OpenAI security certification.
Contents
- What OpenAI announced
- What Zero Data Retention is
- Four data flows in an AI system
- What ZDR is not
- What limitations are visible in the documentation
- Why audit logs should not store the full prompt
- What audit record is actually needed
- The RAZDEL method
- How to test the architecture in a pilot
- What metrics to measure
- Limitations and open questions
- Frequently asked questions
- How AI Dawn helps build a private AI environment
- Conclusion
What OpenAI announced
On August 19, 2026, OpenAI introduced a preview Private Safety Processing. The company describes the problem this way: some risks show up not in a single message, but in a sequence of related interactions—for example, when someone repeatedly tries to bypass safeguards or when an AI agent keeps acting after being told to stop. A standard check of an individual request does not see that pattern as a whole.
Private Safety Processing, or PSP, is designed to detect patterns across related interactions without OpenAI staff having access to the original prompts and responses. In ZDR deployments, the content remains in the customer’s infrastructure. OpenAI is also developing an option for storage in its own infrastructure with encryption using keys controlled by the customer and with no copies available to OpenAI employees.
If a risk is detected, the provider, according to OpenAI’s description, receives a narrow safety signal about the type of activity, but not the original content. The customer investigates the event using information in its own systems and decides whether to share additional data for an appeal or a confirmed investigation.
It is important to preserve the boundary of evidence. PSP is being tested with early customers, and a technical white paper is planned for September 2026. The public announcement does not disclose the full threat model, cryptographic protocol, measured detector accuracy, false positive rate, or an independent audit. So today this is an architecture direction and a product preview, not a basis for writing in company policy that “the risk is solved.”
What Zero Data Retention is
Zero Data Retention is a mode for approved API customers in which customer content is excluded from abuse-monitoring logs, and compatible endpoints do not store that content as application state. In the official OpenAI documentation it is stated that ZDR requires prior approval and additional terms; the setting is available at the organization and project levels.
The documentation distinguishes two types of storage:
- Abuse-monitoring logs — logs used to monitor policy compliance and abuse. By default, they may include prompts, responses, and derived metadata and may be retained for up to 30 days unless a longer basis applies.
- Application state — data that features store in order to complete a task: conversation, file, vector store, batch, background response, or another object.
For ZDR, the store parameter in the Responses API and Chat Completions is forcibly treated as false. But that setting alone does not make every feature compatible with ZDR. The mode must be checked for each endpoint, tool, model, project, and data path.
The article’s core formula is:
Zero retention at the provider does not mean zero memory across the entire system. It means a limited mode for a specific processor under the stated conditions.
Four data flows in an AI system
The debate over whether to store prompts or not is too coarse. In a production agent, there are at least four different flows, and each needs its own owner, purpose, and retention period.
| Flow | Examples | Why it is needed | Main risk |
|---|---|---|---|
| Payload | prompt, document, image, model response | to complete the user’s task | exposure of content and personal data |
| Application state | conversation, file, vector store, cache, background result | to continue or complete the function | hidden long-term storage beyond ZDR expectations |
| Safety signals | risk category, policy decision, alert | to detect abuse or agent overreach | signal that is too broad or an opaque enforcement decision |
| Audit evidence | request ID, version, tool call, approval, effect, hash | to reproduce a decision and investigate an incident | log becomes a shadow copy of the payload |
These flows cannot be handled under one policy. The content of a contract may be needed by the model for a few seconds, while the record that an agent tried to change payment details without confirmation may need to be kept longer. But for an investigation, an action ID, a hash of the parameters, the policy check result, and the business effect are often enough; the full contract in the audit log is not required.
This approach is consistent with the NIST Privacy Framework: data processing includes not only storage, but also collection, logging, transmission, and deletion. Minimization should cover the entire lifecycle, not just the model provider’s database.
What ZDR is not
Four concepts are often mixed up in procurement and internal policy.
| Concept | What it confirms | What it does not confirm |
|---|---|---|
| No training | the content is not used to train the model without opt-in | that it is not stored anywhere for operations or safety |
| Zero Data Retention | The compatible API path does not retain customer content after processing in the stated categories | that a third-party MCP, an internal logger, or an incompatible function retains nothing |
| Data residency | certain data is stored and sometimes processed in the selected region | that the retention period is zero or that there is no system data |
| Customer-managed keys | the customer controls the encryption key for a specific layer | that plaintext never appears during processing or that the entire chain uses this key |
| Internal audit | the company can investigate actions and manage accountability | that the full content of every request must be stored |
From this, a practical rule follows: in the contract, architecture, and privacy notice, you cannot replace an exact description with the word ZDR. You need to list which data, at which stage, by whom, for what purpose, and for how long is processed.
For the Russian context, it is useful to separately review Federal Law 152-FZ and the use of foreign AI systems. ZDR by itself does not resolve questions of the legal basis for processing, data localization, cross-border transfers, the controller's role, the contract with the vendor, or the deletion policy. These conclusions should be confirmed by a lawyer for the specific organization and data category.
What limitations are visible in the documentation
OpenAI's table shows why verification should be based on capability, not the vendor logo.
| Scenario | Observed behavior | Practical takeaway |
|---|---|---|
| Responses / Chat Completions | store is forcibly set to false under ZDR |
check the project configuration and do not rely only on the request parameter |
| Conversations, Assistants, Threads, Vector Stores | marked in the table as not ZDR-eligible | do not use as hidden persistent state in a ZDR environment |
| Files | are retained until deleted; expires_after is supported within the stated limits |
set an expiry and verify actual deletion separately |
| Background response | a temporary result may appear on disk for polling | include the temporary state in the data map and deletion test |
| Prompt caching | encrypted key/value tensors may exist in GPU-local storage for a limited time | do not promise the literal absence of any temporary state |
| Remote MCP | data is sent to a third-party service and is subject to its retention policy | include every MCP in the subprocessor registry and data-flow review |
| Hosted containers / skills | temporary files live for the container lifecycle | define who deletes the container and how expiry is verified |
| Image/file safety scan | potential CSAM may be retained for manual review even under ZDR | document the legal exception and do not make an absolute promise |
Documentation changes. The states listed above were observed on August 23, 2026 and do not replace current pre-launch verification. It is especially important to check the model version, region, tool, and project mode: compatibility of one endpoint does not automatically carry over to another.
An external tool is a separate trust boundary. If the agent sent content to a CRM, search service, or MCP, the model's ZDR does not control deletion at that recipient. Similar to the risks of prompt injection in AI agents, the security boundary runs through the entire tool call chain.
Why audit logs should not store the entire prompt
Security teams often compensate for an agent's lack of transparency by logging everything. This is convenient for debugging: you can open the prompt, the response, the chain-of-thought surrogate, and the tool arguments, and see the error. But a production log quickly becomes a second repository of sensitive data—sometimes with broader access rights and a longer retention period than the source system.
Three contradictions arise:
- minimization versus investigation: the more payload you store, the easier the retrospective review and the larger the privacy attack surface;
- integrity versus availability to the agent: if the agent can modify the log, it is not reliable evidence;
- reproducibility versus confidentiality: the full text is enough for replay, but it may contain personal data, keys, contracts, and trade secrets.
NIST AI RMF recommends documenting intended context, privacy risk, production behavior, emergent risks, and incident response processes. This does not require storing every input in the same way. The requirement is to have a traceable basis for decisions and controls that is proportionate to the risk.
Therefore, it is better to design a two-layer audit:
- A persistent or longer-lived event layer without raw payload: identifiers, versions, policies, actions, approvals, and effects.
- A short, isolated payload buffer only for permitted risk classes, if it is truly needed and justified; the agent itself should not have access to it.
If the process does not legally allow storing content even briefly, the investigation is built on deterministic identifiers, cryptographic hashes, snapshots of the source business system state, and reproducible test fixtures.
What audit record is actually needed
The minimum format depends on risk, but a production agent event can usually be described without the full text.
| Field | Example | Why it matters | Need payload? |
|---|---|---|---|
| Correlation IDs | request, session, workflow, parent action | link the steps of a single task | no |
| Identity | user, service account, agent role | set permissions | no |
| Configuration | model snapshot, prompt version, policy version | reproduce the logic | the prompt text can be stored separately in a versioned registry |
| Data classes | internal, confidential, restricted | verify the allowed route | no |
| Tool event | tool name, operation, target system | restore the action | raw arguments are not always needed |
| Argument digest | canonicalized hash + selected redacted fields | prove immutability without copying the content | no, if there is a source with controlled access |
| Decision | allow, deny, require approval, escalation | check the policy engine | no |
| Human control | approver ID, reason code, timestamp | show the transfer of responsibility | minimize the comment |
| Effect | created/updated/deleted object ID, status | verify the actual result | no |
| Safety signal | category, confidence band, enforcement state | investigate the protective decision | the source content separately and only on a need basis |
| Lifecycle | retention class, expires_at, legal hold | perform deletion | no |
Not every process requires every field. But any irreversible tool call should be linked to who initiated the task, which agent and policy were in effect, what was allowed, which object changed, and how to roll back the result.
The log itself should be written to storage that the agent cannot edit or delete. The OWASP AI Agent Security Cheat Sheet recommends clear audit trails, data classification, and retention/deletion policies; this is useful implementation guidance, but not certification of any specific system.
The RAZDEL Method
RAZDEL — an original AI sunset framework for designing a private and auditable environment. It is a practical synthesis of OpenAI, NIST, and security guidance, not an industry standard.
- R — mode. Document the actual data-control mode at the organization and project level: default, MAM, ZDR, or another mode. Verify it through administrative control, not by a contractual label.
- A — assets. Classify prompts, files, outputs, tool arguments, and business effects. For each class, specify the owner, the processing purpose, and forbidden routes.
- Z — zones. Draw the path
user → application → model → hosted tool/MCP → business system → audit store. At each boundary, record the storage operator and the deletion policy. - D — evidence. Define the minimum audit record: IDs, versions, policy decision, approvals, tool/action digest, and effect. Include raw payload only on a separate basis.
- E — expiry. Set the TTL, deletion trigger, legal-hold exception, and a way to verify that derived files, cache, vector entries, and backups also disappeared.
- L — limits. Document incompatible functions, temporary state, safety/legal exceptions, third-party retention, and the inability to prove what the vendor has not yet disclosed.
The method ends not with a document, but with a test. The team must show that the same request ID can be traced to a business effect, and that the full payload is truly inaccessible after the retention period in all declared zones.
How to test the architecture in a pilot
1. Choose one process and one data class
For example, preparing a response from an internal knowledge base without sending a message to the customer. Capture the current baseline, sources, permissions, constraints, and acceptance criteria. Do not start with an agent that reads email, changes the CRM, and sends payments at the same time.
2. Build a data-flow map
List the API endpoint, model, store, caching, files, hosted tools, MCP, application logs, APM, SIEM, backups, and assignment system. For each arrow, assign an owner and a retention class.
3. Introduce canary data
Use synthetic markers that are not real personal data or secrets. After the request, look for these markers in all permitted logs and storage systems. Absence from one vendor log does not prove absence across the entire chain.
4. Simulate four events
- a normal successful request;
- a forbidden tool call;
- a stop command in the middle of a long agentic task;
- a call to a third-party MCP with a confidential field.
Check that the policy blocks or escalates the required step, and that the log explains the decision without extra content.
5. Test time-based deletion
After the TTL, repeat the canary search in files, caches, vector stores, hosted containers, app logs, and backups. Record not only the delete call, but also the observed result or a truthful Unknown for the zone that cannot be verified.
6. Conduct a blind investigation
Give the engineer only the minimal audit record and the business system state. They must reconstruct the sequence, identify the owner, and determine whether the action was authorized. If that’s not possible, add a specific field rather than the entire payload.
7. Check appeals and legal exceptions
Simulate a false safety alert and a lawful storage exception. Who sees the content? Who issues the key? Who approves the legal hold? How is the event closed, and how are temporary copies removed after the decision?
8. Roll out in a limited scope
Start with read-only or shadow mode, then move to reversible actions with confirmation. Increase autonomy only after passing deletion, audit reconstruction, and incident response tests.
What metrics to track
| Metric | Formula or rule | What it shows |
|---|---|---|
| Payload replication rate | zones with a found canary / verified zones | where content is copied outside the intended path |
| Audit sufficiency | reconstructed events / test events | whether the minimum evidence is enough |
| Sensitive-field exposure | unmasked sensitive fields / audit records | whether the log has become a source of leakage |
| Deletion verification | confirmed cleared zones / zones with TTL | whether the lifecycle is actually being enforced |
| Unknown-zone count | zones without a verifiable retention state | where the promise cannot yet be confirmed |
| Policy interception | blocked risky actions / all risky tests | whether control works before the business effect |
| Orphan effect rate | effects without a linked request/approval / all effects | whether responsibility can be assigned |
| Appeal reconstruction time | time to reproduce the safety event | whether the log is usable for investigation |
These metrics do not predict safety or legal compliance. They measure observable properties of the selected pilot. The threshold is set by the process owner together with the security, privacy, and legal functions based on the risk class.
Limitations and open questions
As of the date of this article, Private Safety Processing remains in preview. OpenAI plans to begin rollout and publish a technical white paper in September 2026. Until then, the exact cryptographic design, the composition of cross-interaction state, false-positive/false-negative rates, independent tests, threat model, availability by model and region, cost, latency, and migration path for each customer have not been publicly established.
The mechanism description and product characteristics are taken from OpenAI sources. These are primary sources on the product’s stated behavior, but not independent confirmation of implementation. The data controls documentation was viewed on August 23, 2026, and may change.
NIST AI RMF and the Privacy Framework are voluntary risk management frameworks, not certifications for this architecture. OWASP is practical security guidance. None of these sources confirm compliance by a specific company with Russian or foreign law.
The article does not measure abuse frequency, production incidents, PSP effectiveness, ROI, storage cost, latency, the likelihood of leakage, or company outcome. Search volume, keyword difficulty, rankings, traffic, CTR, and the page’s AI citations also Unknown.
Frequently Asked Questions
Does OpenAI store prompts with Zero Data Retention?
For an approved ZDR environment, OpenAI states that customer content is excluded from abuse-monitoring logs and that compatible endpoints have no application state after processing. But temporary state, incompatible features, files, third-party services, and lawful safety exceptions must be checked separately.
How is ZDR different from a no-training promise?
No-training limits the use of content for model improvement. ZDR applies to storage of customer content in specific categories and endpoints. Data may not be used for training but may still be retained to perform a function or for monitoring — these are different promises.
Do you need to turn off the AI agent audit log when using ZDR?
No. A managed agent needs an audit trail of actions, decisions, and effects. But the log does not have to copy the entire prompt: often identifiers, versions, redacted metadata, the policy decision, argument hashes, approvals, and object IDs are enough.
Are MCP servers compatible with ZDR?
The model provider’s ZDR policy does not define a third-party MCP’s policy. OpenAI’s official documentation explicitly states that data sent to an MCP server is subject to that service’s retention policy. Each MCP should be reviewed as a separate recipient.
Does store: falsemean the data is not stored anywhere?
No. This parameter controls the behavior of a specific API, but not the application’s own logs, files, caches, hosted tools, SIEM, backups, MCP, or the target business system. A complete data-flow map is required.
What is the first test a company should run?
Choose one read-only process, add a synthetic canary, trace it through all zones, verify TTL, and try to investigate a prohibited action using only the minimal audit record. This test reveals hidden copies and gaps in evidence.
How AI startup helps build a private AI environment
AI startup can connect data requirements with a real business process and technical stack:
- audit the process, sources, current baseline, and data classes;
- design an enterprise AI workspace, RAG, or a local LLM deployment with zone and access separation;
- build an AI agent MVP with integrations, a minimal log, policy checks, and action confirmation;
- run testing, launch, team training, and lifecycle control support.
A safe first step is to choose one process, document its baseline, data sources, constraints, and acceptance criteria. Discuss the project.
Conclusion
Zero Data Retention is useful not as a marketing label, but as a verifiable property of a specific data path. OpenAI’s recent preview shows a possible tradeoff: analyze risky patterns across interactions without giving provider staff access to the original content. But until the technical white paper and independent review are available, implementation details remain open.
For business, the main question is more precise: which data must disappear, and which minimal evidence must remain so the agent’s action can be explained and challenged? The method SECTION turns the answer into an architecture: mode, assets, zones, evidence, expiry, and limits. If the team cannot draw these six elements and validate them with a canary test, the promise of “we store nothing” has not yet been proven.
Useful to read together: local AI agent and security, AI agent incident investigation and 152-FZ and Foreign AI.