This article focuses on one production misconception: enabling OpenAI Zero Data Retention does not, by itself, make an entire AI Agent system zero-retention.
The easiest mistake to make with OpenAI Zero Data Retention (ZDR) is to turn a provider-level data control into an end-to-end architecture claim:
“If ZDR is enabled, this AI agent does not retain data anywhere.”
That is not what the current OpenAI documentation says.
As of August 20, 2026, OpenAI's Data Controls documentation says eligible customers can be approved for Zero Data Retention and configure it at the API organization or project level. With ZDR enabled, customer content is excluded from eligible abuse-monitoring logs and the store parameter for /v1/responses and /v1/chat/completions is always treated as false.
A production agent, however, usually has a much larger data path:
User / Enterprise Data
↓
Application / Agent Runtime
↓
OpenAI Responses API ← ZDR controls part of this retention surface
↓
Remote MCP / Tools ← third-party retention policy
↓
SaaS / Database / Files ← business-system retention
↓
Agent Memory / Vector DB ← your application state
↓
Trace / Audit / SIEM ← your audit policy
The useful question is therefore not “Does OpenAI support ZDR?” It is: after ZDR is enabled, where else can an enterprise agent still persist data, and how should those boundaries be governed?
First separate three concepts that are often conflated
1. store=false
This is part of endpoint/request behavior. For the Responses API, OpenAI documents application-state behavior around store; when organization-level ZDR is enabled, store is treated as false even if a request tries to set it to true.
2. Zero Data Retention
ZDR is an approval-based OpenAI data control, not a flag that every API key has by default. Approved customers can configure it at the organization or project level.
OpenAI separates at least two storage categories:
- Abuse monitoring logs, which can contain prompts, responses and related metadata and are retained for up to 30 days by default under the documented policy;
- Application state, which some API capabilities persist in order to perform a feature.
ZDR changes the first category and changes application-state behavior for ZDR-eligible endpoints, but it does not automatically make every API feature or external tool zero-retention.
3. Data Residency
Data Residency answers where eligible customer content is stored or processed. ZDR answers whether and how long relevant content is retained.
They are different control planes. A regulated agent deployment may need both a residency design and a retention design.
The OpenAI boundaries that matter most for agent builders
The table below is more useful than a binary “supports ZDR” label.
| Agent component / API capability | Current documented boundary | Architectural implication |
|---|---|---|
/v1/responses |
ZDR forces store=false
|
Useful for stateless model calls, but tool/state choices still matter |
/v1/chat/completions |
ZDR forces store=false
|
Does not imply downstream systems are zero-retention |
/v1/conversations |
Listed as not ZDR-eligible; state persists until deletion | Do not treat Conversations as stateless storage in a strict ZDR design |
/v1/vector_stores |
Not ZDR-eligible; application state persists until deletion | Vector knowledge needs its own retention policy |
/v1/files |
Not ZDR-eligible; files persist until deletion/expiry rules | Uploaded files need explicit TTL and deletion controls |
| Remote MCP | Third-party service | Governed by the MCP provider's own retention policy |
| Background Mode | Response data is written to disk for roughly 10 minutes for polling | Strict zero-persistence use cases need feature-level review |
| Hosted Shell / Code Interpreter containers | Temporary application state can exist while containers are active | Sandbox lifecycle is also a data lifecycle |
| Prompt Caching | Encrypted KV tensors may be kept in GPU-local storage with a documented maximum 24-hour expiration boundary | “No database record” does not mean “no temporary state” |
| Third-party network services | Third-party policy applies | OpenAI ZDR cannot govern external SaaS retention |
The most consequential sentence for agent architecture is explicit in OpenAI's guide: MCP servers are third-party services, and data sent to an MCP server is subject to that server's data-retention policy.
If an agent sends customer contracts, source code, financial data or internal tickets to a remote MCP server, OpenAI-side ZDR does not tell you whether that MCP provider logs, caches, forwards or stores the content.
Why ZDR has to be designed with MCP security
The MCP specification already treats tools as a security-sensitive execution surface.
The current MCP Specification notes that MCP can expose arbitrary data access and code-execution paths and therefore requires consent, authorization, data protection and tool-safety thinking. The Tools specification requires servers to validate inputs, implement access controls, rate-limit invocations and sanitize outputs; clients should confirm sensitive operations and log tool usage for audit.
Those controls answer different questions from ZDR:
ZDR → OpenAI-side data-retention control
MCP Authorization → who may invoke which tool
MCP Server Policy → how the tool provider processes and stores data
Sandbox → what the tool can actually affect
Audit → whether the execution chain can be reconstructed
An enterprise agent needs a data-flow inventory, not one zdr_enabled=true checkbox.
Build a retention matrix, not a marketing claim
A practical architecture review should have a table like this:
| Data flow | Data type | Processor | Persisted? | Default TTL | Delete path | Owner |
|---|---|---|---|---|---|---|
| User → Agent Runtime | Raw request | Your app | Business-dependent | Custom | DB/API | Application owner |
| Runtime → OpenAI Responses | Prompt/context | OpenAI | Feature/control-dependent | Official policy | Endpoint-dependent | AI platform |
| Agent → Remote MCP | Tool args/context | Third-party MCP | Provider-dependent | Unknown is a risk | Provider policy | Integration owner |
| Agent → Vector DB | Embeddings/chunks | First/third party | Usually yes | Custom | Delete/TTL | Data owner |
| Agent → Audit | Tool event/approval | SIEM/log store | Yes | Minimum necessary | Retention rule | Security |
If the team cannot complete this matrix, it should not describe the system as a “zero-retention agent architecture.”
ZDR and audit logs are not opposites
Another failure mode is turning “zero retention” into “turn off every useful security log.” That is not a safe production pattern.
OpenAI's Running Codex safely at OpenAI describes a deployment model that combines sandboxing, approvals, network policy, identity/credentials and agent-native telemetry and audit trails. OpenTelemetry events can cover tool approval decisions, tool execution results, MCP server usage and network allow/deny decisions.
The better question is:
Which content should not be retained, and which minimal security events must be retained so an incident can still be investigated?
A high-risk agent audit record can often store structured evidence without copying the full sensitive payload:
{
"actor_id": "user_or_service_hash",
"tenant_id": "tenant_123",
"tool": "invoice.approve",
"resource_id": "invoice_***",
"decision": "approved",
"approval_id": "appr_***",
"arguments_hash": "sha256:...",
"result": "success",
"timestamp": "..."
}
That is the design tension to solve: data minimization without losing auditability.
Why ZDR belongs inside Agent Security Infrastructure
The broader industry signal is now stronger than a single vendor feature.
NIST's 2026 analysis of responses on AI agent security says commenters widely agreed that agents introduce novel security threats and that those concerns are a barrier to adoption. NIST is also pursuing a dedicated software and AI agent identity and authorization effort.
The OWASP Top 10 for Agentic Applications 2026 treats Tool Misuse, Identity & Privilege Abuse, Unexpected Code Execution, Memory & Context Poisoning and related agent-specific risks as a distinct security domain.
The International AI Safety Report 2026 places deployment-time monitoring, human oversight, chain-of-thought monitoring and sandboxing inside the technical-safeguard toolbox and explicitly emphasizes the limitations of individual safeguards and the need for defense in depth.
That leads to a more durable infrastructure stack than model routing alone:
Identity
↓
Authorization / Policy Gate
↓
Approval
↓
Sandbox + Network Boundary
↓
Tool / MCP Execution
↓
Data Retention Policy
↓
Audit / Monitoring
↓
Incident Response / Kill Switch
ZDR is one component of the Data Retention layer.
How I would design a ZDR-aware enterprise agent
Step 1: classify data before choosing controls
At minimum, distinguish:
- Public
- Internal
- Confidential
- Regulated / PII / PHI / Financial
The classification determines whether data may enter the model, remote MCP, long-term memory or logs.
Step 2: create a data-egress record for every tool
Track at least:
- Provider
- Authentication identity
- Data categories
- Retention policy
- Region
- Write capability
- Approval requirement
- Audit event
Step 3: treat unknown third-party retention as a risk
This matters most for remote MCP. Standardized transport does not imply standardized retention. If the provider policy, contract or self-hosted boundary is unknown, do not treat it as covered by OpenAI ZDR.
Step 4: set explicit TTLs for every persistent state
Review:
- Application databases
- Agent memory
- Vector stores
- Uploaded files
- Traces
- Audit logs
- Temporary sandboxes
Every state should answer: why is it needed, how long can it exist, and who can delete it?
Step 5: make deletion verifiable
A production retention policy should be executable:
list retained objects
→ identify owner / tenant
→ delete or expire
→ verify deletion
→ retain deletion evidence
Production checklist
Before describing an OpenAI-powered agent as ZDR-aware, verify:
- [ ] Has the organization/project actually been approved for ZDR, rather than only using
store=false? - [ ] Are the endpoint and features in use ZDR-eligible?
- [ ] Are Conversations, Vector Stores or Files used anywhere in the flow?
- [ ] Is Background Mode enabled?
- [ ] Is prompt caching enabled?
- [ ] Are hosted shell or Code Interpreter containers used?
- [ ] Is remote MCP connected, and has each third-party retention policy been reviewed?
- [ ] Do application memory, databases, traces and audit stores have explicit TTLs?
- [ ] Have Data Residency and ZDR been reviewed separately?
- [ ] Do logs minimize sensitive content while preserving tool/approval accountability?
- [ ] Is there a tested deletion and credential-revocation procedure?
If a critical item is answered with “we don't know,” the architecture is not ready to be described as zero-retention.
Bottom line
Zero Data Retention is a meaningful enterprise control, but it is not a magic label that makes an entire agent stack stateless.
A production agent's data boundary has to extend from the model API through MCP, tools, memory, sandboxes, audit systems and third-party SaaS.
That is why the more durable enterprise opportunity is broader than model routing or token-cost management. It is AI Agent Security Infrastructure: the control plane for identity, permissions, execution, data, audit and incident response.
Continue with:
- AI Agent Security: moving from input filtering to action constraints
- AI Agent Tool Authorization: a per-call Policy Gate
- MCP Security: tool permissions, roots, approvals and audit
- OpenClaw / MCP Sandbox Architecture
- Agent Security Auditor: 21 production-readiness checks
Primary references
- OpenAI — Data controls in the OpenAI platform
- OpenAI — Running Codex safely at OpenAI
- International AI Safety Report 2026
- Model Context Protocol — Specification
- MCP — Authorization
- MCP — Tools security considerations
- NIST — Security Considerations for AI Agents
- OWASP — Top 10 for Agentic Applications 2026
Top comments (0)