OpenAI's New Agents API Has No EU Residency Option — A GDPR Transfer Guide for Builders

OpenAI shipped its new Agents API in public beta on September 10, 2026 — a managed layer for building multi-step, tool-calling agents without hand-rolling your own orchestration loop. It's a genuinely useful product. It's also, according to OpenAI's own documentation, a step backward on data residency compared to what OpenAI already offers for its core API. The Agents API overview page states it plainly: "The Agents API currently supports data residency only in the United States," and — this is the part worth reading twice — it "does not support Zero Data Retention (ZDR). Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible."

That second sentence is the actual news. It's not that OpenAI forgot to build EU residency into a beta product; plenty of betas launch US-only first. It's that OpenAI anticipated the obvious workaround — "I'll just run the code-execution sandbox myself, in the EU, and keep my compliance story intact" — and pre-empted it in writing. Running your own sandbox changes where your tools execute. It does not change where the orchestration state that drives them lives. If you're building an agentic product that will touch personal data of people in the EU, that distinction is the whole ballgame.

This isn't OpenAI being unable to do EU residency — it already does, elsewhere

The frustrating part is that OpenAI solved this exact problem for its core API months ago. On January 16, 2026, OpenAI expanded data residency in Europe for eligible customers, and the API data residency help article confirms the mechanism: approved projects can route requests through eu.api.openai.com, with both storage and processing kept in-region. Zero Data Retention is available on that path too — but, notably, it requires separate sign-off from the regional-residency approval itself. Regional storage and ZDR are two different switches, not one.

So the underlying model-serving infrastructure OpenAI runs absolutely can keep data in Europe. What the Agents API adds on top — server-managed conversation threads, tool-call orchestration, session state, sandbox lifecycle management — is a new product surface that, as of this beta, simply hasn't been wired up to that same regional-residency control plane yet. That's a scoping gap in a beta product, not a technical wall. It's reasonable to expect OpenAI extends residency to the Agents API eventually. It's not reasonable to build a compliance program today on the assumption that it already has.

Why "the sandbox is self-hosted" doesn't rescue you

The instinct to reach for a self-hosted sandbox is understandable — it's the pattern that works for plenty of other residency problems: keep the compute where you control it, and the data problem mostly resolves itself. It doesn't work here because of what the Agents API actually is. An "agent" in this product is a stateful object that OpenAI's backend tracks across turns: it stores the conversation thread, decides which tool to call next, records the tool call and its result, and manages retries and hand-offs. Your sandbox executes the tool, but the agent — the record of what was asked, what was decided, and what came back — lives in OpenAI's orchestration layer the entire time, in the US, with standard retention. Moving the sandbox to Frankfurt changes where a shell command runs. It doesn't change where the prompt that requested it, and the personal data that prompt might contain, is stored.

The GDPR question this actually raises: it's a transfer question, not a residency preference

It's tempting to talk about this as a "nice to have" — EU residency as a feature some customers prefer. That undersells it. If any personal data of an EU data subject (a user's message, a customer record your agent looks up, an email your agent drafts) passes through the Agents API's US-based orchestration layer, you've triggered Chapter V of the GDPR. Article 44 sets the baseline: "any transfer of personal data... to a third country... shall take place only if... the conditions laid down in this Chapter are complied with," and those conditions must ensure "the level of protection of natural persons guaranteed by this Regulation is not undermined" (GDPR Art. 44). Being convenient, or being what a beta API happens to support, is not one of the recognized conditions.

There are three routes Chapter V recognizes to satisfy Article 44: an adequacy decision (Art. 45), appropriate safeguards such as Standard Contractual Clauses (Art. 46), or Binding Corporate Rules (Art. 47). Here's the detail that actually changes the risk calculus for this specific product: OpenAI is not certified under the EU-US Data Privacy Framework, the adequacy mechanism that would otherwise let you skip straight past this analysis. A compliance review of OpenAI's vendor posture found no active or inactive DPF listing for OpenAI as of September 8, 2026, and confirmed OpenAI's own transfer mechanism is Standard Contractual Clauses, not adequacy (CompanyScope, OpenAI vendor review). OpenAI's own Data Processing Addendum confirms the SCC-based structure directly: EEA and Swiss customer data is instructed to OpenAI Ireland Limited, and onward transfers out of the EEA — including to US infrastructure — run on the EU Commission's June 2021 Standard Contractual Clauses. That routes you straight into Article 46 territory, which is a materially higher bar than adequacy.

Article 46 SCCs aren't a checkbox. Since the CJEU's Schrems II ruling (Case C-311/18, judgment of 16 July 2020), relying on SCCs for a US transfer requires a case-by-case transfer impact assessment: you have to confirm the data subject is actually afforded "essentially equivalent" protection in practice, including supplementary technical or organizational measures where US surveillance law creates a gap SCCs alone don't close. "No Zero Data Retention, and self-hosting doesn't change that" is exactly the kind of fact a transfer impact assessment has to weigh — it means one of the most common supplementary measures (minimizing what the vendor retains, and for how long) isn't available to you on this product surface at all. You can still do the TIA and reasonably conclude the transfer is defensible for a given use case; you just can't skip doing it because "it's just an API call."

Article 28 adds the processor-side half of the same obligation: a processor must "process the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country" (GDPR Art. 28). If you're the controller here — the party who decided to route your users' data through the Agents API — that instruction is yours to document, and yours to be able to defend.

Three ways to actually build agentic workflows without inheriting this gap

1. Keep the orchestration yourself, use the EU-resident endpoint only for the model call. You don't need OpenAI's managed Agents API to build an agent loop. A self-rolled orchestrator — even a straightforward state machine, or an open-source framework like LangGraph running on your own EU infrastructure — that calls eu.api.openai.com for each model inference keeps conversation state, tool-call records, and session history inside infrastructure you control and can document under your own Art. 30 records of processing. You lose some of the convenience of managed retries and hand-offs; you keep full control of where personal data actually lands. This is the same trade-off we walked through for migrating off the Assistants API — owning your agent's memory instead of renting it.

2. If you use the Agents API anyway, minimize before it reaches the orchestration layer, not after. If the convenience of managed orchestration is worth it for a given feature, apply data minimization (GDPR Art. 5(1)(c)) at the boundary: strip or pseudonymize direct identifiers before they enter the agent's tool-calling loop, and keep the mapping back to a real identity in your own EU-hosted store. Our tool-calling data minimization pattern for MCP-style agent architectures applies here directly — the boundary just moves from "before the tool call" to "before the orchestrator," since the orchestrator is now the thing retaining data in the US.

3. Use an EU-hosted or self-hosted model stack entirely for personal-data-bearing agent workloads. For agents that will routinely handle sensitive categories of data, or where your risk appetite for a Schrems II-style TIA is low, the cleanest answer is not sending the data to a US-based orchestration layer in the first place — run an open-weight model, self-hosted, on EU infrastructure, with your own orchestration on top. That's a bigger architectural commitment, but it removes the transfer question entirely instead of managing it.

A five-item audit for your current agent stack

1. Inventory which of your agent features route through the Agents API specifically (not the Chat Completions/Responses API — they have different residency options), and flag any that could plausibly touch an EU data subject's personal data.
2. For each flagged feature, check whether a self-hosted sandbox is doing any of the compliance work you think it's doing. Per OpenAI's own documentation, it isn't — treat the orchestration layer as US-resident regardless.
3. Confirm which transfer mechanism your own Art. 30 records currently cite for this vendor. If it says "Data Privacy Framework," that's the single most common documentation error CompanyScope's review flags — correct it to SCCs (Art. 46) plus a transfer impact assessment.
4. Run or refresh the transfer impact assessment for this specific product surface, explicitly noting the absence of a ZDR option as a factor against relying on retention-minimization as a supplementary measure.
5. Decide, feature by feature, which of the three architectures above you're using — managed orchestration with EU-only model calls, minimize-then-orchestrate, or fully self-hosted — and document why, before a regulator or an auditor asks first.

None of this means the Agents API is unusable for EU-facing products. It means the convenience of a managed orchestration layer and the compliance posture of your agent are, right now, two separate decisions that this particular product bundles together without telling you. OpenAI added EU residency to its core API in January; there's no technical reason it can't do the same for the Agents API before it leaves beta. Until it does, "the sandbox is self-hosted" is not an answer to where your users' data actually lives — and OpenAI has said so, in its own documentation, in exactly those words.