Guillaume Lebedel · · 6 min read 
Why the OpenAI Agents API is not ZDR eligible
Table of Contents
Why the OpenAI Agents API is not ZDR eligible
OpenAI’s documentation lists /v1/agents among its ZDR-ineligible endpoints, and the Agents API supports data residency only in the United States. A self-hosted sandbox does not change that, because the API keeps session state on OpenAI’s side between turns. Workloads that require Zero Data Retention or European processing have to stay on ZDR-eligible endpoints.
Is the OpenAI Agents API ZDR eligible?
The OpenAI Agents API is not ZDR eligible. The Agents API overview in OpenAI’s developer documentation states that it “currently supports data residency only in the United States and does not support Zero Data Retention (ZDR)”. That applies to every call, in every workspace, for as long as the beta terms hold.
OpenAI opened the Agents API in public beta on 10 September 2026. It runs the same agent loop OpenAI uses for Codex behind one managed endpoint, with sessions, context compaction and multi-step recovery handled server side. The documentation is direct about the trade that comes with it: “The Agents API retains session state so you can continue work across turns without rebuilding the conversation context.” Retained state is the feature. Retained state is also the reason the endpoint cannot offer Zero Data Retention.
For a platform team, the useful way to read this is that eligibility at OpenAI is granted per endpoint, not per account. A security sign-off on the model endpoint your prototype used does not carry over to the endpoint your production agent will call.
Which OpenAI endpoints are ZDR eligible, and which are not?
The ZDR-eligible endpoints are /v1/responses and /v1/chat/completions. Everything on OpenAI’s ZDR-ineligible list stores an object on OpenAI’s side, and that list covers conversations, assistants, threads, vector stores, files, batches, evaluations, videos and /v1/agents itself. Checking it endpoint by endpoint is the fastest compliance check available to you.
| Endpoint | ZDR eligible | What it covers |
|---|---|---|
/v1/responses | Yes | Model calls, with store forced to false under ZDR |
/v1/chat/completions | Yes | Chat-style model calls, same store behaviour |
/v1/agents | No | The Agents API session runtime |
/v1/conversations, /v1/conversations/items | No | Stored conversation objects |
/v1/assistants, /v1/threads | No | Assistants API objects, messages, runs and run steps |
/v1/vector_stores, /v1/files | No | Retrieval corpora and uploads |
/v1/batches, /v1/evals, /v1/videos | No | Batch jobs, evaluations and video generation |
Source: OpenAI’s data controls documentation on retention and residency, read on 14 September 2026.
Does a self-hosted sandbox make the Agents API ZDR eligible?
A self-hosted sandbox does not make the Agents API ZDR eligible. The Agents API documentation states it plainly: “Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible.” The sandbox covers where tool code executes, on OpenAI’s infrastructure or on yours. It does not cover the session state the API keeps between turns.
This is the point most teams get wrong, and the cost of getting it wrong is high, because self-hosting is expensive work. An engineer who spends a sprint standing up a self-hosted sandbox to satisfy a compliance requirement finishes the sprint no closer to satisfying it.
Does the OpenAI Agents API support EU data residency?
The OpenAI Agents API does not support EU data residency today. It is limited to the United States while it is in beta. The wider platform supports regional storage in ten regions, and only two of those support processing as well as storage, so account-level residency does not settle the question at the endpoint level.
| Region | Regional storage | Regional processing |
|---|---|---|
| United States | Yes | Yes |
| Europe (EEA + Switzerland) | Yes | Yes |
| Australia, Canada, India, Japan, Singapore, South Korea, United Kingdom | Yes | No |
Source: OpenAI’s data controls documentation on regional storage and processing, read on 14 September 2026.
If your agent programme is scoped against an EU obligation, the residency answer belongs in the design, not in the review that happens after the build. We made a similar argument about timing when the EU AI Act deadline moved and agent access controls did not: the date changed, the work did not.
What does the Agents API retain, and for how long?
The Agents API retains session state across turns so that a long-running task can continue without you rebuilding context. Separately, OpenAI’s data controls documentation says abuse monitoring logs are generated “for all API feature usage” and retained “for up to 30 days”, unless the law or harm prevention requires longer.
The same page sets out how long stored objects live. Objects created through the Assistants family are deleted 30 days after you delete them through the API or the dashboard, and are retained indefinitely if you never do.
None of that is unusual for a managed runtime, and none of it is hidden. It only becomes a problem when the retention profile of the endpoint you shipped differs from the retention profile of the endpoint you got approved.
This is the part we spend most of our time on at StackOne. A production agent touches two layers, and reviewers ask the same two questions about both: where does the data sit, and how long does it stay. The model endpoint is one layer. The other is whatever reads and writes in Workday, Salesforce or Greenhouse on the user’s behalf, and that layer has its own answer to both questions. We built ours so that customer data is only stored if you choose to, in the processing region you pick, with full control over retention, because a review that clears the model and skips the acting layer has only done half the job.
What should you do if your agent workload needs ZDR or EU residency?
Check eligibility per endpoint before you write the code, not at the review that blocks the launch. The work is a spreadsheet column rather than an architecture change, and it takes about five minutes against a design you already have. Five steps, in order:
- List every OpenAI endpoint your design calls, including the ones your framework calls on your behalf.
- Check each one against OpenAI’s ZDR-ineligible list, and record the result next to the endpoint name.
- Keep regulated workloads on
/v1/responsesor/v1/chat/completionswith ZDR enabled, and carry session continuity in your own store. - Where an EU obligation applies, confirm the region supports processing and not only storage.
- Put the endpoint list in the architecture doc, so the next reviewer can repeat the check in a minute.
That check is cheap, and it is the difference between an agent you can put in front of regulated users and one you can only demo. Teams that skip it are the ones described in why AI agent pilots stall before production, where the blocker is never the model. If you are further along and thinking about controls in production, we set out a staged approach in rolling out AI agent permission policies, monitor first.
Facts in this post were verified against OpenAI’s documentation on 14 September 2026. Beta terms change, so re-read the endpoint list before your next design review.
If you want the same two questions answered for the business systems your agents act in, our documentation covers how StackOne handles regions, retention and audit logging.