Security · Zero data retention
MixedSecurity & complianceWhat happens to your data when an AI model reads it
Every prompt sent to a model is data leaving your hands for a moment. Here is what zero data retention means, what the switch in Agent Serve does, and how to choose settings team by team.
Valnora & Elric team5 min read
When someone pastes a customer complaint into an AI chat, or a workflow sends an invoice to a model for extraction, that text leaves your systems for a moment. The model provider receives it, processes it and sends an answer back. The security question is what happens to the text after that.
Most teams do not need to stop using AI to answer that question well. They need to decide, team by team, which models may see which data, and to have settings that enforce the decision. This post explains the settings in Agent Serve and how to choose them.
Zero data retention, in plain English
A model has to read your prompt to answer it. There is no way around that. What differs between providers and endpoints is what happens next.
Some keep prompts and answers for a period, for example to check for abuse. Zero data retention (ZDR) means the provider does not store the prompt or the answer once the request is finished. Nothing is left on the provider’s side to be reviewed or reused later.
ZDR is a property of a specific model endpoint and your agreement with the provider, not of AI in general. That is why it is shown per model. In the Chat model picker, More models tags the reasoning models that are ZDR.
The switch that enforces it
In Access policies, each permission group has a switch called Models Without Zero Data Retention. When it is on, the team can use any allowed model. When it is off, only ZDR models run.
There is one trade-off to know in advance. Image, video, speech and music models do not have ZDR endpoints. Turning the switch off therefore also withholds media generation for that group. For a claims or finance team that is usually fine. For a marketing team it is not, which is one reason to set this per team rather than once for everyone.
The layers between your data and a model
Policy · Before a request
- 01Allowed providersOnly providers your organisation has agreed to are offered to the team.
- 02ZDR-only switchWith "Models Without Zero Data Retention" off, only ZDR models run. Media generation is withheld.
- 03Your own keysBYOK sends calls under your provider account and agreements.
Workflow · During a run
- 04Guardrails blockDetects personal data and blocks or masks it before the next step.
- 05ApprovalsRelays ask before sending email or booking meetings.
- 06Run logs and auditBlock inputs and outputs, with PII redaction, plus an exportable audit log.
Narrowing who the data can reach
ZDR answers what a provider keeps. Three more settings answer who can receive the data at all:
- Allowed model providers. Only providers your organisation has agreements with appear for the team.
- Denied models and denied tools. Remove a specific model, or tools such as web research, for groups that handle sensitive records.
- Bring your own keys. Under Settings → Model API keys, calls go through your organisation’s provider account, under the terms you negotiated. Without your own key, the platform key is used.
If data must not leave your environment at all, self-hosting runs Agent Serve in your own cloud or data centre, with your own keys or self-hosted models.
Keeping personal data out of prompts and logs
The safest personal data is the data that never reaches a model. Two controls help:
- Guardrails block. In a workflow, a Guardrails block with PII detection checks text before the next step and either blocks the run or masks the personal data.
- PII redaction. In Settings → Data retention, redaction masks personal data in logs, workflow inputs and block outputs, so the run record does not become a second copy of sensitive data.
Keeping people in charge and keeping a record
Models are only part of the risk. The other part is what an AI agent does with the answer. Relays never send email or book meetings without an approval, at any autonomy level, and an approval covers the exact message the reviewer saw. Workflows run from deployed versions, and every run is logged block by block in Logs.
Proposals, approvals, declines and executed actions go to the workspace audit log, which admins can export. SSO through SAML 2.0 or OIDC, with SCIM provisioning, keeps access tied to your identity provider.
Controls and governance
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
Bring your own keys
Use your organisation’s own model provider keys at organisation or workspace level.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
More on how Agent Serve handles access, data and audit on the security page.
Choosing settings per team
Start from the data, not the tool. For each team, ask what the most sensitive thing is that will end up in a prompt.
- Customer records, health or financial data. ZDR-only, allowed providers limited to those with agreements, BYOK, Guardrails before any model step, PII redaction on.
- Internal documents and analysis. Allowed providers limited, ZDR preferred but not enforced, PII redaction on.
- Marketing and creative work. Non-ZDR models allowed so media generation works, with a cost confirmation and a clear instruction to keep customer data out of prompts.
What the solution produces
Access policy for a claims-handling team (illustrative)
Checklist- Models Without Zero Data Retention: off. Only ZDR models run; media generation is unavailable.
- Allowed model providers: the two your legal team has agreements with.
- Model API keys: company keys for both providers (BYOK).
- Denied tools: web research tools, so case data stays inside approved systems.
- PII redaction on for logs, workflow inputs and block outputs.
- Guardrails block with PII detection set to mask, before any summary step.
Access policy for a marketing team (illustrative)
Checklist- Models Without Zero Data Retention: on, so image and video models are available.
- Media Generation: on, with default image and video models set.
- Cost confirmation (USD): 1.
- Instructions: no customer records in prompts; product and campaign data only.
Write the policy down, map it to permission groups, and review it when the model catalogue changes. For the cost side of the same settings, see keeping AI model costs low.
Questions teams ask
Does zero data retention mean the model never sees my data?
No. The model has to read your prompt to answer it. Zero data retention means the provider does not keep the prompt or the answer after the request is done.
Why does turning off non-ZDR models stop image and video generation?
Media models do not have zero-data-retention endpoints. When the "Models Without Zero Data Retention" switch is off, only ZDR models can run, so media generation is withheld for that permission group.
Is every model in Agent Serve zero data retention?
No. In the Chat model picker, More models tags the reasoning models that are ZDR. Some provider features keep data by design and sit outside zero data retention.
Does Agent Serve hold a security certification?
This post makes no certification claim. It describes the controls in the product. See the security page for current details.
What you need
- A list of teams and the most sensitive data each one puts into prompts
- The model providers your legal team has agreements with, and whether those include zero data retention
- Provider keys for BYOK, if you want calls under your own contracts
- Permission groups mapped to those teams
- A decision on which teams need media generation, since it is not available under ZDR-only
- SSO set up through your identity provider before wider rollout