OpenAI Zero Data Retention 怎么用？AI Agent、Responses API 与 MCP 数据保留边界

如果你在企业项目里看到 OpenAI Zero Data Retention（ZDR），最容易犯的错误是把它理解成：

“打开 ZDR 以后，这个 AI Agent 从用户输入到 MCP、Memory、日志、向量库，所有地方都不再保存数据。”

这个理解不对。

截至 2026 年 8 月 20 日，OpenAI 当前 Data Controls 官方文档 对 ZDR 的定义要窄得多，也专业得多：符合资格并获得批准的客户，可以在 API Organization 或 Project 级配置 Zero Data Retention；启用后，客户内容会从符合条件的 abuse monitoring logs 中排除，并且 /v1/responses、/v1/chat/completions 的 store 会始终按 false 处理。

但一个真实 Agent 的数据路径通常是：

User / Enterprise Data
        ↓
Application / Agent Runtime
        ↓
OpenAI Responses API        ← ZDR 主要控制这里的一部分 retention
        ↓
Remote MCP / Tools          ← 第三方 retention policy
        ↓
SaaS / Database / Files     ← 业务系统自己的 retention
        ↓
Agent Memory / Vector DB    ← 你的应用状态
        ↓
Trace / Audit / SIEM        ← 你的审计策略

因此这篇真正要解决的问题不是“ZDR 好不好”，而是：启用 ZDR 以后，企业 Agent 还有哪些地方会保留数据，以及你应该怎样设计端到端的数据边界。

先区分三个经常被混在一起的概念

1. store=false

这是 endpoint/request 行为的一部分。对 Responses API 来说，默认或 store=true 时会产生 application state；OpenAI 当前文档写明，在组织启用 ZDR 后，store 即使显式传 true，也会按 false 处理。

2. Zero Data Retention

ZDR 是需要 OpenAI 事先批准的数据控制能力，不是所有 API Key 默认自带的开关。获批后可以在组织级或项目级配置。

OpenAI 文档把数据存储至少拆成两类：

• Abuse monitoring logs：默认可能包含 prompts、responses 及相关 metadata，通常最长保留 30 天；
• Application state：为了实现某些 API feature 而持久化的数据。

ZDR 会影响前者，也会改变一部分 ZDR-eligible endpoint 的 application-state 行为，但并不会让所有 endpoint 和所有外部工具自动变成零留存。

3. Data Residency

Data Residency 解决的是“数据在什么区域存储/处理”；ZDR 解决的是“数据是否以及多久被保留”。

这两个概念不能互相替代。一个系统可以有区域化处理要求，同时仍需要定义 retention；也可以有 ZDR 要求，却仍然要审计第三方 MCP、业务数据库和内部日志的位置与生命周期。

OpenAI 当前哪些边界最值得 Agent 开发者注意？

下面这张表比一句“支持 ZDR”更有用。

Agent 组件 / API 能力	当前关键边界	对架构的影响
/v1/responses	ZDR 下 store 强制为 false	适合无 OpenAI 持久状态的主推理链路，但仍要看所用工具
/v1/chat/completions	ZDR 下 store 强制为 false	不能据此推断外部系统零留存
/v1/conversations	官方表格标记为 ZDR 不可用，状态保留到删除	严格 ZDR 架构不要把 Conversations 当无状态存储
/v1/vector_stores	ZDR 不可用，application state 保留到删除	向量知识库必须独立纳入 retention policy
/v1/files	ZDR 不可用，文件可保留到删除/到期	上传文件要显式 TTL/删除策略
Remote MCP	第三方服务	由 MCP Server 自己的 retention policy 决定
Background Mode	为 polling 会把 response data 写盘约 10 分钟	严格零持久化需求要单独评估
Hosted Shell / Code Interpreter Container	活跃期间可能写临时 application state，容器到期/删除时清理	Sandbox 的生命周期也是数据生命周期
Prompt Caching	可能在 GPU-local storage 保存加密 KV tensors，文档给出最长 24 小时的应用状态边界	“没有数据库落盘”不等于没有临时状态
第三方网络服务	受第三方 retention policy 约束	ZDR 无法替你约束外部 SaaS

这里最重要的一句来自 OpenAI 自己的文档：MCP servers 是第三方服务，发送给 MCP server 的数据受它们自己的 data retention policies 约束。

这意味着，如果 Agent 把客户合同、财务数据、源码或内部工单发送给一个 remote MCP Server，那么“OpenAI 侧启用了 ZDR”并不能回答数据是否在那个 MCP 服务上被记录、缓存、转发或长期保存。

为什么 ZDR 必须和 MCP Security 一起设计？

MCP 官方规范本身已经把 Tool 看成高风险执行能力。

当前 MCP Specification 明确指出，MCP 可以形成任意数据访问和代码执行路径，因此实现者需要建立 consent、authorization、data protection 与 tool safety。Tools 规范进一步要求 Server 验证输入、实施 access controls、限流、清洗输出；Client 侧则应该在敏感操作前让用户确认，并记录 tool usage 以便审计。

这和 ZDR 是两个完全不同的维度：

ZDR                 → OpenAI 侧的数据保留控制
MCP Authorization   → 谁可以调用什么工具
MCP Server Policy   → 工具端怎样保存/处理数据
Sandbox             → Tool 最终能影响什么系统
Audit               → 执行后能否还原责任链

因此企业 Agent 不应该只有一个 zdr_enabled=true 的合规勾选框，而应该有完整的 data-flow inventory。

一个生产级 Agent 至少要画这张 Retention Matrix

我更建议在架构评审里直接做矩阵，而不是只写政策文档。

数据流	数据类型	处理方	是否持久化	默认 TTL	删除方式	负责人
User → Agent Runtime	原始请求	自有应用	取决于业务	自定义	DB/API	Application Owner
Runtime → OpenAI Responses	Prompt / Context	OpenAI	取决于 Data Controls / feature	见官方政策	取决于 endpoint	AI Platform
Agent → Remote MCP	Tool args / context	第三方 MCP	取决于第三方	未知时视为风险	第三方政策	Integration Owner
Agent → Vector DB	Embedding / chunk	自有/第三方	通常是	自定义	Delete / TTL	Data Owner
Agent → Audit	Tool event / approval	SIEM / Log Store	是	最小必要周期	Retention Rule	Security

如果这一张表画不出来，就不能声称“我们的 Agent 是零留存架构”。

ZDR 与审计日志并不冲突：关键是“最小必要审计”

很多团队碰到 ZDR 后会走向另一个极端：为了“零留存”，把 Tool Call、审批和执行日志全部关闭。

这同样不适合生产环境。

OpenAI 在 Running Codex safely at OpenAI 中公开的内部做法恰恰相反：它把 sandbox、approval、network policy、identity/credentials 与 agent-native telemetry / audit trails 一起设计，并使用 OpenTelemetry 记录诸如 tool approval、tool execution、MCP server usage、network allow/deny 等事件。

正确问题应该是：

哪些内容不应该保存，哪些安全事件必须保存，审计日志里需要保存到什么粒度？

对于高风险企业 Agent，一个更稳妥的 audit event 可以只保存：

{
  "actor_id": "user_or_service_hash",
  "tenant_id": "tenant_123",
  "tool": "invoice.approve",
  "resource_id": "invoice_***",
  "decision": "approved",
  "approval_id": "appr_***",
  "arguments_hash": "sha256:...",
  "result": "success",
  "timestamp": "..."
}

而不是把完整 Prompt、合同正文、客户 PII 和 Tool Response 全量复制进永久日志。

这就是 Data Minimization 与 Auditability 的平衡。

为什么我把 ZDR 放进 Agent Security Infrastructure，而不是单纯“隐私设置”？

因为行业信号已经非常清晰。

NIST 2026 年关于 AI Agent Security 的 RFI 总结指出，反馈者普遍认为 Agent 带来了新的安全威胁，而且这些安全问题已经成为采用障碍；NIST 还单独推进了 software / AI agent identity and authorization 方向。

OWASP Top 10 for Agentic Applications 2026 已经把 Tool Misuse、Identity & Privilege Abuse、Unexpected Code Execution、Memory & Context Poisoning 等问题单独整理成 Agentic 风险体系。

International AI Safety Report 2026也把 deployment-time monitoring、human oversight、chain-of-thought monitoring 与 sandboxing 放在技术安全措施中，并强调单一 safeguard 并不可靠，需要 defense-in-depth。

所以企业下一步买的不会只是一套“模型路由 + Token 成本面板”。Agent 真正进入生产后，控制层会越来越像：

Identity
   ↓
Authorization / Policy Gate
   ↓
Approval
   ↓
Sandbox + Network Boundary
   ↓
Tool / MCP Execution
   ↓
Data Retention Policy
   ↓
Audit / Monitoring
   ↓
Incident Response / Kill Switch

ZDR 只是其中 Data Retention 的一块。

企业落地：我会怎样设计一个“ZDR-aware Agent”

第一步：先做数据分类，而不是先开 ZDR

把进入 Agent 的数据至少分成：

• Public
• Internal
• Confidential
• Regulated / PII / PHI / Financial

高等级数据决定能否进入模型、能否进入 remote MCP、能否写入 Memory、日志是否需要脱敏。

第二步：按 Tool 建数据出口清单

每个 Tool 至少记录：

• Provider
• Auth identity
• Data categories
• Retention policy
• Region
• Write capability
• Approval requirement
• Audit event

第三步：把“第三方 retention 未知”当成风险，不要当成默认安全

尤其是 remote MCP。没有明确政策、合同或自托管边界时，不要因为 MCP 接口看起来标准化，就把它当成受 OpenAI ZDR 覆盖。

第四步：对持久状态显式设置 TTL

包括：

• Application DB
• Agent Memory
• Vector Store
• Uploaded Files
• Trace
• Audit
• Temporary Sandbox

每一种状态都应该知道“为什么需要、最长多久、谁能删”。

第五步：把删除能力变成可以验证的运维动作

合规设计不是 PPT 上写一句“30 天删除”，而是可以执行：

list retained objects
→ identify owner / tenant
→ delete or expire
→ verify deletion
→ retain deletion evidence

上线前 Checklist

如果你准备把 OpenAI API 接到企业 Agent，至少确认下面这些问题：

• 组织/项目是否真的获批 ZDR，而不是只设置了 store=false？
• 当前使用的 endpoint / feature 是否 ZDR eligible？
• 是否使用 Conversations、Vector Stores、Files 等持久状态？
• 是否使用 Background Mode？
• 是否使用 Prompt Caching？
• 是否使用 Hosted Shell / Code Interpreter container？
• 是否连接 remote MCP？第三方 retention policy 是否已核对？
• 应用自己的 Memory、DB、Trace、Audit 是否有 TTL？
• Data Residency 与 ZDR 是否分别评估？
• 日志是否遵循最小必要原则，同时仍能还原 Tool Call 和审批责任链？
• 是否有数据删除与撤销凭据的实际操作流程？

如果其中任何一个关键环节回答是“我不知道”，那就还不能把系统描述成“Zero Data Retention Agent”。

最后的判断

ZDR 的价值是真实的，尤其对高敏感数据、企业采购和监管场景。但它不是一张把整个 Agent 变成“无数据状态”的魔法贴纸。

生产级 Agent 的数据边界必须从模型 API 一直画到 MCP、Tool、Memory、Sandbox、Audit 和第三方 SaaS。

这也是为什么我认为接下来更有价值的 AI 基础设施，不只是模型路由和成本控制，而是 AI Agent Security Infrastructure：把权限、执行、数据、审计和事故处置放到独立控制层。

如果你正在做这类系统，可以继续看：

• AI Agent Security：从过滤 Prompt 到限制行动
• AI Agent Tool Authorization：每次 Tool Call 前做 Policy Gate
• MCP Security：Tool Scope、allowedRoots、审批与审计
• OpenClaw / MCP Sandbox Architecture
• Agent Security Auditor：扫描 Agent / MCP 配置与代码风险

主要参考资料

• OpenAI — Data controls in the OpenAI platform
• OpenAI — Running Codex safely at OpenAI
• International AI Safety Report 2026
• Model Context Protocol — Specification
• MCP — Authorization
• MCP — Tools security considerations
• NIST — Security Considerations for AI Agents
• OWASP — Top 10 for Agentic Applications 2026

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅