Zero data retention does not mean nothing is stored: what the arrangement actually covers.
Important takeaways.
- Zero data retention is an arrangement over specific endpoints for a specific organisation, not a property of a vendor. It covers inference: prompts and responses are not stored at rest once the API response is returned.
- The seat-based chat interfaces most fund staff actually use are generally not covered. On Anthropic's platform the Console, the Workbench and the Claude Teams and Claude Enterprise product interfaces sit outside the arrangement, with a documented exception for Claude Code used through Enterprise.
- Stateful features are ineligible by design. The Files API keeps uploads until they are deleted, batch processing stores requests and responses for up to 29 days, and code execution containers retain data for up to 30 days.
- Nothing blocks a developer from calling those endpoints under the arrangement. The documentation is explicit that using one is a choice to step outside zero data retention for that data, so the arrangement can be intact while a specific workflow is not covered by it.
- Some models require retention and cannot run under the arrangement. Claude Fable 5 and Claude Mythos 5 are designated Covered Models with a 30 day retention requirement, and a request from a zero retention organisation returns an error.
- Retention required by law, or triggered when automated trust and safety systems flag content, survives the arrangement. The published figure is up to two years for flagged inputs and outputs.
"Zero data retention" is one of the few phrases that reliably ends an AI security review inside a fund. It should not. The arrangement is real and it is worth having, but it is scoped to particular endpoints, particular models and particular products, and the gaps sit exactly where a credit fund's most sensitive material tends to go: borrower packs, credit papers, portfolio extracts.
This is a contract and architecture question rather than a jurisdictional one, so the mechanism reads the same in Melbourne, London or Singapore. What changes by market is what you are then obliged to do about it.
What the arrangement actually covers.
On the Claude API, a zero data retention arrangement means the provider does not store customer prompts or responses at rest after the API response is returned. It is enabled per organisation, by contract, and it does not extend automatically to a new organisation created under the same account. Other major providers publish their own version. Ask for theirs in the same form.
Two limits are already visible in that sentence. It covers inference, not everything the product does. And it attaches to an organisation someone has to keep track of, not to the vendor's brand.
The second one is where funds are most often caught out, because the seat-based chat interface most staff actually use is not the same thing as the API. Usage through the Console and the Workbench sits outside the arrangement, and the Claude Teams and Claude Enterprise product interfaces are not eligible for it, with a documented exception for Claude Code used through Enterprise with zero data retention enabled. A fund can hold a zero retention arrangement for its integration and still have analysts pasting a credit paper into an interface the arrangement never touched.
The stateful features that sit outside it.
Some features cannot work without storing something, and the published eligibility table marks them ineligible for that reason.
- Files API. Uploads persist until you delete them. They are scoped to the workspace rather than to a user, a conversation or a session, so any API key in that workspace can read any file uploaded there.
- Batch processing. Request and response data is stored for up to 29 days after batch creation.
- Code execution. Container data, including artefacts, uploaded files and outputs, is retained for up to 30 days, and containers expire 30 days after creation.
- Managed agent sessions. Transcripts are stateful resources and persist until you delete them.
- The MCP connector and agent skills. Data is retained under the standard policy rather than the arrangement.
The load-bearing sentence is not in the table but in the notes beneath it. Under zero data retention the API does not block these features. Using one is a choice to step outside the arrangement for that specific data. Nobody receives an error, nothing surfaces in a report, and the fund's answer to "do you have zero data retention" is still technically yes.
That is the realistic failure mode, and it is not a vendor being slippery. It is a developer reaching for the Files API because a 300 page information memorandum is easier to upload once than to send with every request.
The carve-outs that outlast the arrangement.
- Some models require retention. Claude Fable 5 and Claude Mythos 5 are designated Covered Models carrying a 30 day retention requirement, so the arrangement is not available for them at all. A request from an organisation configured for zero retention returns an error rather than quietly downgrading, and a zero retention organisation that wants those models has to enable 30 day retention on a specific workspace.
- Flagging and legal obligations survive. Even with the arrangement in place, a provider may retain data where required by law or where its automated trust and safety systems flag it. The published figure is up to two years for flagged inputs and outputs.
- Where you buy changes who holds it. On Amazon Bedrock and Google Cloud's Agent Platform the cloud provider is the data processor rather than the model vendor, so the vendor's retention page stops being the document that answers the question.
Zero retention and a reconstructable record pull in opposite directions.
This is the part that gets missed, and for a credit fund it is the one that matters most.
The same platforms that offer zero retention also offer compliance and audit surfaces, and those run on much longer clocks. The Compliance API's Activity Feed retains data for six years, and session transcripts are retained for six years by default. The same documentation states that the Compliance API does not capture local sessions for which zero data retention is in effect.
Read those together and the trade is explicit. Switching on zero retention removes the vendor's copy of the conversation, and it removes the vendor side record of what was asked and answered along with it. A fund that later needs to reconstruct how an AI assisted covenant test or credit summary was produced cannot take that record from a surface it has just turned off.
The call we would make is that the record belongs on the fund's side of that boundary rather than the vendor's, because a record that can be switched off in a settings page is not one to rely on at audit. It is a decision to take deliberately and once, not to discover in the middle of a review. The shape is the same as the diligence an APRA regulated investor now runs on a manager under CPS 230: the question is not whether the vendor is careful, it is whether the fund can say what happened.
What to ask, and what to record yourself.
Four questions produce a usable answer. Ask them of every provider, and ask for the per feature table rather than the marketing page.
- Which endpoints and products does the arrangement cover, and which of our people are working outside it today?
- Which features are stateful, and what is the documented retention period for each one?
- Which models are excluded, and what happens when someone requests one?
- What is retained regardless of the arrangement, for how long, and on what trigger?
Then the part no vendor can do for you. Retention is set per endpoint, so a fund can only answer the question if something on its own side records which workflow used which endpoint, with which model, on whose behalf. Where AI use grew workflow by workflow, that mapping does not exist, and the honest answer to an investor is "we have a zero data retention arrangement" followed by silence about what it covers. Where AI runs through a single layer, the same question is answered by reading the fund's own records.
Primary sources: API and data retention, zero data retention for Claude Code, batch processing data retention, code execution data retention and the Compliance API. This guide is general information, not advice. It describes published vendor documentation as at the date above; retention terms change, so confirm the position against your own contract and the provider's current documentation.
Questions this guide answers.
Does zero data retention mean our prompts are never stored?
No. It means prompts and responses are not stored at rest after the API response is returned, on the endpoints and products the arrangement covers, for the organisation it was enabled for. Stateful features such as file storage, batch processing, code execution and managed agent sessions store data under their own documented retention periods. Data required to be kept by law, or flagged by automated trust and safety systems, is retained regardless of the arrangement.
Which features are not covered by zero data retention?
The stateful ones, because they cannot function without storage. On the Claude API that includes the Files API, where uploads persist until deleted and are scoped to the whole workspace rather than to a user or session; batch processing, which stores request and response data for up to 29 days; code execution, where container data is retained for up to 30 days; managed agent sessions, whose transcripts persist until deleted; and the MCP connector and agent skills, which follow the standard retention policy. The API does not block these calls, so a fund can hold the arrangement and still be storing data through them.
Does zero data retention stop a legal hold or a law enforcement request?
No. Providers reserve the right to retain data where required by law, and that reservation sits alongside the arrangement rather than under it. Content flagged by automated trust and safety systems can be held for up to two years. Deployment route matters here as well: on Amazon Bedrock and Google Cloud's Agent Platform the cloud provider is the data processor, so the model vendor's retention terms are not the document that governs the answer.
Can we have zero data retention and an audit trail at the same time?
Not from the same vendor surface. Compliance and audit surfaces run on much longer clocks, with the Compliance API's Activity Feed and session transcripts retained for six years, and the Compliance API does not capture local sessions for which zero data retention is in effect. Turning on zero retention removes the vendor's copy of the conversation and the vendor-side record of it together, so a fund that needs to reconstruct how an output was produced has to hold that record on its own side.
Working with Levercon.
Levercon builds the AI operating system for credit funds: Fund OS connects a fund's own data into a knowledge layer, and Custom Agents run repetitive work across origination and monitoring. To talk to us, email info@levercon.ai.
This guide is general information, not advice. Factual claims that rely on public sources link to those sources in the text. Practical guidance also draws on patterns Levercon observes across Australian credit funds. No client is named and no figure is attributed to one. Written by Levercon, reviewed before publication and revised in place as the facts change.