OpenAI Zero Data Retention for AI Agents: Responses API, MCP and Data Boundaries

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: scan Agent / MCP configuration and code risks

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

Topic path / MCP

Continue from protocol details to production MCP governance

The MCP hub connects protocol fundamentals, transports, authentication, security, JSON-RPC debugging and production deployment without splitting the search intent across isolated guides.

Open MCP hub → Review the security checklist Subscribe