Zero Data Retention AI Agents: Where Vendor Forgetting Meets Agent Memory
Zero data retention AI agents need memory to finish overnight jobs. What Anthropic's Covered Models and OpenAI's endpoint table retain, plus a boundary table.
Go deeper. Build your own.
The procurement file says zero data retention. The overnight job that started at 1 a.m. needs to remember at 4 a.m. which migration it already ran, which test it already fixed, and which approval it is still waiting on. Both sentences are about memory, and they are about different copies of it.
Zero data retention AI agents are a procurement fiction until someone draws the line between the memory the job needs and the copy the vendor keeps. By September 2026 the vendors have drawn part of that line for you, in plain language: Anthropic’s Covered Models carry a 30-day retention window by default and exclude zero data retention wherever those models can be reached, apart from a time-limited transition, with a customer-held alternative arriving in phases this fall; OpenAI’s data page lists which endpoints can be zero-retention and which cannot, and the agents endpoint cannot. None of that stops an agent from finishing a night’s work. It does decide where the record of that work lives.
This piece is the boundary: the three memories an agent job actually has, a table that says which stays local, which the vendor holds for a window and which the vendor must forget, the primary-source lines behind each cell, a configuration shape for the local side, and a procurement checklist with the answers that count as yes.
What Anthropic and OpenAI wrote down, and when
On September 1, 2026, alongside Claude Fable 5.1, Anthropic announced Enterprise Frontier Safeguards. The post describes EFS as “a solution that combines the privacy of zero data retention (ZDR) with state-of-the-art safeguards for detecting misuse” that “works by storing data in cloud infrastructure controlled by the customer, not Anthropic,” and says it “will be rolling out to customers in phases, starting later this fall.” In the meantime, “eligible customers will receive ZDR on Fable 5 and Fable 5.1 until EFS is ready” (Anthropic).
Screenshot: Anthropic, “Developing Enterprise Frontier Safeguards with our customers” (Sep 1, 2026), captured Sep 19, 2026.
The same post explains why retention exists at all, and this is the sentence to keep: “because the most sophisticated misuse can involve many tasks spread across multiple sessions and accounts, it is not sufficient to run automated analysis on each interaction separately and then instantaneously discard the data. Effective detection requires storing data for a meaningful period of time so that it can be correlated across time and accounts.” Then: “For this reason, we introduced 30-day data retention starting with Fable 5. This policy was not motivated by a desire to train on enterprise data: Anthropic has never trained on enterprise data without explicit permission, and never will.”
The retention rule itself lives on the Covered Models page. A Covered Model is one whose capabilities “represent a substantial step up from prior generations and create elevated risk if misused,” and the table lists Claude Fable 5.1 and Claude Mythos 5.1 with an August 31, 2026 date, after Fable 5 and Mythos 5 on June 9, 2026.
The policy: “30-day minimum retention by default. Prompts and model completions are retained for at least 30 days and then automatically deleted, unless they are subject to a safety investigation or we are legally required to maintain them. Accordingly, zero data retention is not available in workspaces, Claude Enterprise organizations, or third-party platforms (e.g., Azure Subscriptions) where Covered Models can be accessed.” And: “These policies follow the model. They apply wherever Covered Models are offered, including third-party cloud platforms” (Claude Help Center).
Screenshot: Claude Help Center, “Covered Models” (undated; table entries Jun 9 and Aug 31, 2026), captured Sep 19, 2026.
OpenAI’s data page is a table rather than a policy essay, and the table is the point. Abuse monitoring logs are “retained for up to 30 days, unless longer retention is required by law,” and eligible customers can be approved for Zero Data Retention or Modified Abuse Monitoring. Under ZDR, “the store parameter for /v1/responses and v1/chat/completions will always be treated as false.” The row that matters for agents: /v1/agents carries 30-day abuse monitoring, keeps application state “Until deleted,” and is ZDR-eligible “No” (OpenAI).
Why a job that acts needs memory a chat never did
A chatbot’s memory is a convenience. An agent’s memory is its working state: what it ran, what came back, what it decided, what it still owes. Take that away mid-job and the job repeats itself or stops, which is the opposite of what the @ClaudeDevs post above is selling.
The collision is narrower than ZDR against memory in the abstract: an agent’s memory is a prompt, and a prompt is what the vendor’s safety window retains. Every time the harness re-injects yesterday’s notes, they cross the line again. The replay-tax piece prices that crossing in tokens; this one prices it in retention.
Three memories, one line
Name them before you negotiate anything; the vendor page and the procurement clause are usually talking about different ones.
- Working context. The live transcript inside the job: system prompt, tool calls, tool results, replies, the notes the agent writes to itself. It crosses the line on every turn, by design, and it is what the vendor’s safety window retains.
- Your archive. The transcript, tool log, approvals and cost record you keep after the job ends, on disk you control, for as long as your policy says. It never has to cross the line. The evidence-export runbook covers pulling it off a vendor-hosted harness before the session page rotates.
- The vendor’s safety window. The copy of prompts and completions the vendor holds to correlate misuse across sessions and accounts: at least 30 days on Anthropic’s Covered Models, up to 30 days in OpenAI’s abuse-monitoring logs. ZDR, where it exists, removes this copy. EFS lets you keep it in your own cloud account.
The mistake in most procurement files is treating all three as one thing called data.
Illustrative. An operator model built against the Covered Models page and OpenAI’s endpoint table, not a vendor specification.
The boundary table for zero data retention AI agents
Everything in this table is the operator’s default position, drawn from the primary lines quoted above.
| Artifact | Stays local (your archive) | Vendor retains by default | Under ZDR / EFS |
|---|---|---|---|
| Session transcript (prompts and completions) | Yes, the full copy, on your retention period | Anthropic Covered Models: at least 30 days; OpenAI: abuse-monitoring logs up to 30 days | ZDR: not retained (eligible customers and endpoints); EFS: the window can sit in your cloud account |
| Tool-call log with arguments | Yes; the copy an auditor asks for | As far as it appeared in prompts and completions | Same as the transcript |
| Approvals, who and when | Yes, only here | Not a vendor artifact | Not applicable |
| Agent memory notes that get re-injected | Yes, as files you can read and prune | Every replay is a new prompt inside the window | Same as the transcript; the note never had to live at the vendor |
| Secrets and credentials | Vault only, redacted before any prompt | Must never arrive | Must never arrive |
| Safety classifier results | Not yours to hold | Retained | Anthropic: “still retains User Safety classifier results” under ZDR |
Hosted agent state (OpenAI /v1/agents) |
An exported copy, on your cadence | “Until deleted” | Not ZDR-eligible; deletion is yours to trigger |
| Final diff and pull request | Yes, plus the git host | Not a vendor artifact | Not applicable |
Two cells deserve a second look. The classifier row comes from Anthropic’s own ZDR scope article: “Under these arrangements, Anthropic still retains User Safety classifier results in order to enforce our Usage Policy” (privacy.claude.com). Zero retention was never zero; it was zero content. The hosted-state row catches teams moving from a chat integration to a hosted agent: same vendor, same model, different retention answer, because the endpoint changed.
Read the retention pages like a contract
The primary pages are short. Record the lines, not your summary of them.
Anthropic, the window. The data-retention page for Covered Models says prompts and outputs “are retained for 30 days to support our safety work, on every platform where these models are offered,” effective June 9, 2026. Access is gated: “By default, no Anthropic personnel can read your retained conversations,” and “Every instance of access is recorded in a tamper-proof log that reviewers cannot suppress or modify” (privacy.claude.com). Two operational lines on the same page matter for a fleet: Claude Code’s data handling practices “are governed by the workspace it operates in,” so a Covered Model in Claude Code inherits the workspace’s retention, and on Azure, “If you have zero data retention configured, then you will need to create and use a separate Azure Subscription to access these models.”
Anthropic, the exceptions. The Covered Models page offers eligible customers “the option to use ZDR with Fable 5 and Fable 5.1 for their own internal business applications,” and calls it “available for a limited time, and intended to be a transition to EFS.” The ZDR scope article names the products a ZDR agreement covers: “eligible Anthropic APIs, Anthropic products that use your Commercial organization API key (including Claude Code accessed via the API), and Claude Code for Enterprise plans.”
Anthropic, the replacement. EFS keeps the window and moves it. “Activity data used for monitoring can be stored in the customer’s own cloud account (such as Amazon S3, Azure Blob Storage, or Google Cloud Storage).” The three controls, “Customer-owned storage, Customer-Managed Encryption Keys, and fully automated review are each opt-in,” and “None of them change model behavior, API pricing, or rate limits.”
Anthropic “doesn’t charge for Enterprise Frontier Safeguards”; your cloud bills the storage, reads, writes and egress. The launch page lists the surfaces: “Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google’s Agent Platform, and Microsoft Foundry” (Anthropic).
OpenAI, the endpoint decides. The your-data table is the whole policy for agents; read the row for the endpoint you call, not the model page. GPT-6 Astra’s launch page says “Astra supports Zero Data Retention for eligible API customers” (OpenAI), and the table says /v1/agents is not ZDR-eligible; both are true, and the endpoint you pick is what reconciles them. The page also reserves the right “to make models ineligible” for ZDR “for specific customers, as notified in advance”.
| OpenAI endpoint (your-data table) | Abuse monitoring | Application state | ZDR-eligible |
|---|---|---|---|
/v1/responses, /v1/chat/completions |
up to 30 days by default | store forced to false under ZDR |
Yes, with limitations |
/v1/agents |
30 days | Until deleted | No |
/v1/conversations |
up to 30 days by default | Until deleted | No |
/v1/vector_stores, /v1/files, /v1/threads* |
up to 30 days by default | Read the row for each | No |
Configure the local side first
The vendor side is a contract you sign once. The local side is a configuration you own every night, and it is what makes the boundary real. Build the archive before you negotiate the window; the negotiation goes better when you can say what you already keep.
# illustrative: retention.yaml, the operator's side of the line
archive:
root: /srv/agent-archive # disk you control; never a vendor store
keep:
transcript: 365d # full prompts, completions, tool calls with arguments
approvals: life-of-code + 365d # who said yes, to what scope, when
cost_record: 365d # tokens, cache fields, dollars per job
memory_notes: 90d # the agent's own notes, versioned, prunable
export_from_vendor:
cadence: on-session-end and every 6h # well inside any vendor window
include: [events, usage, final_diff, environment]
vault:
redact_before_prompt: true # secrets never cross; the vault holds the real values
block_patterns: [api_key, bearer, private_key, connection_string]
memory_loop:
inject_from: /srv/agent-archive/memory_notes # not from a vendor memory store
max_injected_tokens: 2000 # the replay-tax cap
review: weekly # a human reads what the agent remembers
vendor:
anthropic:
covered_model_window: 30d # default minimum per the Covered Models page
zdr_status: transition | efs | none
efs_bucket: s3://your-org-efs-activity # when EFS is live: your account, your keys
openai:
endpoint: /v1/responses # ZDR-eligible; /v1/agents is not
zdr_approved: trueFour rules follow from that file.
- Archive first, inject on demand. The agent’s memory notes are files in your archive, read into a prompt when a job needs them, capped in size. That is the cross-CLI session memory pattern; the memory stays yours even though each injection crosses the line as a prompt.
- Redact before the prompt, not after the job. The local-first vault exists so that secrets never make that trip; a credential in a re-injected memory note lands in a fresh retention window every night it replays.
- Export on a cadence that beats the window. The vendor’s 30-day window says nothing about how long your archive keeps anything. Pull events and usage at session end and on a timer; a session page that rotated before the export is not evidence.
- Choose the endpoint, then the model. On OpenAI the endpoint row sets the retention answer before the model does; on Anthropic the workspace sets it for Claude Code. Write both down per job class.
The archive stays left. Prompts cross right and sit in a window. Secrets never cross.
The procurement checklist
Nine questions, each with the source line that answers it and what a yes looks like. Take the answers in writing.
- Which models in our workspace are Covered Models today? The table names Fable 5.1, Mythos 5.1, Fable 5 and Mythos 5. A yes is a dated list and a commitment to notify on additions.
- Is ZDR available on this workspace at all? The page says it is not “where Covered Models can be accessed.” A yes means either no Covered Models in the workspace or the transition arrangement, in writing, with its end condition.
- If we have the transition ZDR, what ends it? Anthropic calls it “a limited time” and “a transition to EFS.” A yes names the trigger and the notice period.
- Under ZDR, what is still retained? The scope article says “User Safety classifier results”. A yes lists every retained category, even the small ones.
- When EFS reaches us, which of the three opt-ins do we take? Customer-owned storage, customer-managed keys, fully automated review. A yes is a decision per opt-in, with the cloud account and key behind it.
- On Azure, is our ZDR subscription separate from the Covered Model subscription? The retention page requires “a separate Azure Subscription”. A yes is two subscription ids.
- On OpenAI, which endpoint does each agent job call?
/v1/agentsand/v1/conversationsare not ZDR-eligible. A yes is a per-job-class endpoint list, and a deletion cadence for application state held “Until deleted”. - Where is our archive, and who can read it? Not a vendor question, and the one legal asks first. A yes is a path, a period and an access list.
- Who receives the safety flags? Under EFS they “go directly to the customer”. A yes is a named queue and a person on rotation, which is the same queue the misalignment evidence piece wants for the vendor’s own disclosures.
Four signals the retention boundary has moved
| Failure | The signal | First move |
|---|---|---|
| A Covered Model landed in a ZDR workspace | Settings > Privacy Controls > Data retention period no longer shows ZDR where the file says zero | check the Covered Models table against the model list; move the job or amend the file |
| An agent job moved to a hosted endpoint | your gateway or client logs show /v1/agents calls under a ZDR-approved key |
the row says not eligible; route through /v1/responses or change the retention answer in the file |
| Memory notes carry a secret | the vault’s scanner fires on memory_notes/ |
redact, rotate, and count the nights it replayed; each one is a 30-day window |
| The archive is thinner than the vendor’s window | a session id in a PR has no local pack | shorten the export cadence; the 30 days is theirs, not yours |
The line is an operating-layer decision
Neither vendor can draw this line for you, because neither can see your archive, your approvals or the memory files your agents read at 3 a.m. Anthropic’s answer is to move the window into your cloud; OpenAI’s is a table that tells you which door has a window. Both leave the operator the same job: decide what is retained where, write it down per job class, and enforce it in configuration rather than in a slide.
That is fleet policy work, the kind the restricted-mode piece does for what agents may touch, and it sits next to two other September decisions: which cyber-tier models a workspace may reach, since the Covered Models definition names cybersecurity among the capabilities that trigger it, and what the cache you keep warm costs, since warm context and retained context are the same tokens. Draw the line once. Then let the job remember whatever it needs.
FAQ: zero data retention AI agents
Can AI agents run under zero data retention?
Yes, with two conditions. The endpoint or workspace must be ZDR-eligible, which excludes OpenAI’s /v1/agents and, outside the transition arrangement, any Anthropic workspace where a Covered Model can be accessed, and the agent’s memory must live in your own archive, re-injected per job rather than stored at the vendor.
Does zero data retention mean the vendor keeps nothing?
No. Anthropic’s ZDR scope article says it “still retains User Safety classifier results,” and OpenAI’s page reserves the right to make models ineligible for specific customers. ZDR removes the content copy; it does not remove the safety signal, and it never covers the copy you keep yourself.
Sources
- Anthropic: “Developing Enterprise Frontier Safeguards with our customers” (Sep 1, 2026)
- Claude Help Center: “Covered Models” (30-day retention, ZDR exclusion, transition arrangement)
- Claude Privacy Center: data retention practices for Covered Models (effective June 9, 2026)
- Claude Privacy Center: what products a zero data retention agreement applies to (June 9, 2026)
- Anthropic: “Claude Fable 5.1 and Mythos 5.1” launch page, data retention and EFS sections (September 2026)
- OpenAI Developers: your-data guide, endpoint retention and ZDR table
- OpenAI: GPT-6 Astra launch page, ZDR line (Sep 3, 2026)
