数据外泄是 AI Agent 安全里最现实的风险之一，因为它会把抽象的模型失败变成具体业务事故。Agent 可能被允许读取客户记录、客服工单、源代码、内部文档、分析导出、凭证或事故记录。如果同一个 Agent 还能发邮件、发 Slack、调用任意 URL、上传文件、创建工单、写评论或把内容总结到公开位置，私有数据到外部暴露之间的路径就会很短。
这份清单面向准备把 AI Agent 用到真实工作流的团队，重点是降低 prompt injection、工具误用、检索错误、权限过高、日志薄弱或审批界面混乱导致私有数据离开系统的概率。
1. 定义哪些数据算敏感数据
先写一份产品和工程团队都能理解的数据分级列表。敏感数据可能包括客户姓名、邮箱、支持历史、合同条款、内部备注、源代码、API key、secret、凭证、日志、分析导出、安全发现、法律文件和未发布产品计划。
这份列表应该使用操作语言，而不只是合规语言。Agent 构建者需要知道：检索到的客服工单、debug log、CSV 导出或代码片段，是否可以展示给用户、总结、存储或发送给另一个工具。
2. 映射所有读取路径
数据外泄从访问开始。列出 Agent 可以读取的所有位置：RAG 索引、数据库、文件系统、浏览器页面、内部 API、SaaS 工具、CRM 记录、知识库、工单系统、代码仓库、日志和 memory store。对每个来源记录数据负责人、敏感级别、访问方式和保留行为。
这张图经常会暴露意外的权限过大。客服 Agent 可能只需要公开帮助文档和当前工单，却能访问所有工单。编程 Agent 可能只需要仓库目录，却能看到开发者 home 目录。研究 Agent 可能只需要公开网页，却也能读取同步的私有文档。
3. 映射所有写入和发送路径
读取路径之后，要映射出站路径。Agent 能不能发邮件、发聊天消息、创建公开评论、更新 issue tracker、上传文件、调用 webhook、发 HTTP 请求、创建 pull request、写文档或导出报告？每一条出站路径都是潜在外泄路径。
团队应该区分内部写入和外部发送。更新内部草稿不同于给客户发邮件。创建私有工单不同于发布到公开 GitHub issue。安全设计应该让最高风险的出站动作清晰可见、可审查。
4. 让检索范围匹配任务
RAG 系统经常因为检索范围过宽而泄露数据。Agent 提出的是一个窄问题，却检索出大量包含无关客户信息、内部备注或敏感示例的文档。模型随后可能总结出用户不该看到的内容。
应该按租户、用户角色、项目、工作区、文档类型和任务做 scoped retrieval。检索过滤必须由后端强制执行，而不是交给模型自觉遵守。如果用户不能直接访问某文档，Agent 也不应该代表用户检索它，除非存在明确批准的委托规则。
5. 把工具输出当成不可信数据
工具输出可能包含敌对指令。网页、PDF、issue 评论、客服工单或文档，都可能告诉 Agent 泄露 secret、忽略策略、编码数据或把上下文发送到别处。Agent 应该把这些文本当成数据，而不是更高优先级的指令。
Prompt 模板应该明确标记检索内容和工具返回内容是不可信的。系统应该防止工具输出改变工具权限、目标白名单、审批要求或 Agent 的核心目标。浏览型 Agent 和 MCP 连接工具尤其需要这一点。
6. 使用目的地白名单
如果 Agent 能调用任意外部 URL，外泄会更容易。目的地白名单可以降低风险。Agent 只能把数据发送到与工作流匹配的已批准域名、API、邮箱目的地、聊天工作区、存储桶或内部系统。
未知 webhook、新注册域名、公开 paste 服务、公开文件托管和未评审 callback URL 应该默认阻止。如果工作流需要新增目的地，应该通过明确评审添加，而不是让模型自己决定。
7. 在审批界面展示数据移动
如果审批界面隐藏真实数据移动，审批就很弱。用户不应该只看到“发送摘要”这种模糊提示。审批界面应该显示目的地、将发送的数据类型、工具名、记录或文件 ID，以及 payload 的简短预览。
对于高风险动作，还应该显示目的地是内部还是外部、动作是否可回滚，以及敏感字段是否已脱敏。用户审批的应该是真实操作，而不是对操作的简化叙述。
8. 在暴露给模型和工具前脱敏 secret
Secret 不应该依赖模型自觉保护。API key、token、密码、private key、session cookie、数据库 URL 和签名 secret，应该在进入 prompt、日志、memory 或不需要它们的工具前被脱敏。
对检索文档、工具输出、上传文件和 Agent 日志运行自动 secret 扫描。发现 secret 时，阻止动作、脱敏数值、在可能暴露时轮换凭证，并记录事故说明。
9. 分离总结和发送
常见模式是让 Agent 总结敏感内容，然后发送到某处。应该把两步分开。先让 Agent 在内部生成草稿，再要求明确审查后才能对外发送。这样人和策略检查都有机会发现私有细节。
草稿应该带来源信息：使用了哪些文档、包含了哪些字段、做了哪些脱敏。没有 provenance，审查者很难判断摘要是否意外包含受限内容。
10. 监控异常数据量
外泄通常会在数据量上留下痕迹。一个通常只读一条工单的 Agent，突然读取数百条记录、导出大文件、发送大量消息或调用异常 endpoint，就值得关注。
应该追踪读取记录数、检索字节数、触碰文件数、外部请求、上传大小、消息数量、token 消耗和重复失败的策略检查。当攻击者使用被盗凭证或 Agent 权限运行大任务时，成本异常也可能是安全信号。
11. 记录日志但不要制造第二个泄露点
审计日志是必要的，但如果永久保存原始敏感内容，也可能变成另一个泄露点。日志应该足够支持调查：来源 ID、工具名、参数摘要、目的地、策略决策、审批人、时间戳和结果。
对于敏感 payload，可以保存 hash、脱敏预览或受控证据链接，而不是完整原文。还要定义 Agent 日志的保留周期和访问控制。安全团队需要证据，但不是每个操作者都需要在日志里看到完整客户数据。
12. 上线前测试外泄尝试
准备一个小测试集，尝试诱导 Agent 泄露数据。包括恶意检索文本、被污染的工具输出、要求 secret 的假客服工单、要求外部上传的文档、要求编码数据的 prompt，以及指向未批准目的地的工具调用。
测试应该确认 Agent 会拒绝、要求审批、脱敏敏感内容、阻止目的地或限制检索。每次 prompt、工具、检索过滤、模型版本或审批策略变化后，都应重复测试。
13. 准备控制步骤
如果怀疑发生数据外泄，团队需要快速路径：禁用 Agent、撤销工具凭证、阻止出站目的地、保留日志、识别受影响记录、轮换暴露的 secret、通知内部负责人，并在必要时准备客户沟通。
不要等到严重事故发生后才定义负责人。数据外泄 runbook 应该明确事故负责人、安全评审人、产品负责人、法律/合规联系人和客户沟通负责人。
实用上线规则
如果 AI Agent 能读取私有数据，并能与当前可信边界之外通信，就需要明确的数据外泄控制。最低配置包括 scoped retrieval、destination allowlists、visible approvals、secret redaction、outbound logging、volume monitoring 和 regression tests。
相关资源
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
- AI Agent 的 MCP 安全检查清单
- AI Agent 工具风险登记表模板
- AI Agent 数据治理清单
如果要做更完整的上线评审，可以先使用 AI Agent 就绪度自评。