客户安全审查很少是因为团队完全没有做安全工作而失败。更常见的原因是证据太分散：一个工程师知道工具权限，另一个工程师知道 RAG 流程，产品经理知道审批流，创始人知道对客户的承诺。等客户要求看证据时，团队才在会议中临时拼答案。
这对销售或上线 AI Agent 都很危险。生产级 Agent 往往靠近客户数据、内部文档、浏览器会话、客服队列、财务流程和具备写入能力的 API。客户不只需要听到 Agent 很有用，也需要看到团队是否理解 Agent 的边界，并且能证明这些边界如何被执行。
这篇文章整理一份客户会议前应该准备的 AI Agent 安全审查材料包。它不是认证材料，也不能替代完整安全评估。它是一份严肃客户、安全负责人或内部审批委员会在信任生产工作流里的 Agent 前，通常会期待看到的最小结构化证据。
先明确材料包要支持什么决策
材料包应该回答一个决策：这个 Agent 能否在拟定的生产范围内被批准？如果材料包试图证明 Agent 在所有情况下都安全，它会变得很空。如果它明确具体范围，审查就清晰得多。
建议在第一页写清楚拟定范围。例如：Agent 可以总结客服工单、起草回复、搜索批准的帮助中心文章、建议账户动作，但不能在没有审批的情况下发送回复、退款、修改权限、导出客户数据或更新账单。这个段落会成为后续所有控制的参照点。
1. 架构图
架构图应该展示用户请求从哪里进入，哪个模型或编排层处理它，查询哪些检索系统，可以调用哪些工具，日志写到哪里，以及人工审批在哪里可以中断流程。图可以简单，但必须写出真实组件。
避免使用 “AI layer” 或 “backend” 这种泛泛盒子。客户需要看到信任边界。标清哪些输入是可信指令，哪些是用户请求，哪些是检索内容，哪些是工具输出，哪些系统可能产生副作用。
好的证据包括架构图、组件列表、数据存储、外部服务、租户边界，以及 Agent 无法访问某个系统时会发生什么。如果 Agent 使用浏览器会话，也要说明会话是否隔离、哪些动作被阻止。
2. 工具清单
任何使用工具的 AI Agent 都需要工具清单。它应该列出每个工具、用途、读写状态、权限范围、允许参数、禁止参数、审批要求、日志行为和负责人。这通常是材料包里最有用的一部分，因为工具风险非常具体。
关键区别不是“安全工具”和“不安全工具”，而是这个工具在当前产品上下文里能做什么。只能读取公开文档的搜索工具，和 CRM 导出工具的风险完全不同。浏览器点击工具，和只能起草邮件的工具也不是一个风险等级。
至少放一个被拒绝的工具调用示例。比如尝试把数据发到未批准目的地、修改权限，或在没有审批时调用写入 API。拒绝 trace 能证明控制真实存在，而不是营销文案。
3. 数据流向图
材料包应该说明数据可以流向哪里。客户会关心 Agent 是否能把信息发送到邮箱、webhook、表格、第三方工具、浏览器表单、分析系统、模型供应商或长期 memory。
有用的数据流向图应该列出 source、destination、data class、policy、approval requirement、retention rule 和 logging behavior。如果敏感值会脱敏，要展示示例。如果某些目的地有 allowlist，要说明 allowlist 如何强制执行。
不要隐藏未解决风险。如果当前实现对某些数据流动依赖人工 review，就直接说明，并解释临时限制。诚实的边界比“数据绝不会泄露”这种无法验证的说法更容易被客户接受。
4. Prompt Injection 和不可信内容测试
Prompt injection 必须进入材料包，因为越来越多客户已经知道 Agent 可能被文档、网页、工单、邮件和工具返回结果影响。材料包要证明团队测试过间接 prompt injection，而不只是明显恶意的聊天消息。
准备一小组 fixtures：包含隐藏指令的 RAG 文档、伪装成系统消息的工具响应、要求 Agent 点击审批按钮的浏览器页面，以及把正常任务和数据导出混在一起的用户请求。每个 fixture 都要展示预期行为和实际 trace。
最好的结果不一定总是拒绝。有时正确行为是忽略敌意指令、只基于可信来源回答、请求审批、脱敏敏感内容或升级给人工。材料包应该把每个结果连接到一个具名控制。
5. 审批策略和审批记录
如果 Agent 可以触发动作，材料包必须解释审批。审批应该绑定到具体动作、payload、目的地和风险等级。笼统的 “approved by human” 对有写入能力的 Agent 来说太弱。
展示审批人看到的内容。审批记录应包括请求动作、受影响账户或对象、工具名、参数、数据目的地、策略原因、请求者、审批人、时间戳和最终决策。如果审批人可以在批准前编辑动作，也要展示这个编辑如何被记录。
同时展示一个被拒绝的审批。拒绝证明流程能真的停住 Agent，而不只是盖章。
6. 日志和事故复盘
客户经常会问：如果 Agent 做错了会怎样？材料包应该用一个事故复盘示例回答。选择一个现实失败场景：错误检索、被阻止的工具调用、敏感数据脱敏、审批拒绝或策略来源冲突。
展示可以让 reviewer 复盘事件的 trace 字段。常见字段包括用户请求、retrieved source IDs、trust labels、tool calls、tool arguments、policy checks、approval records、final answer 和 redaction decisions。避免记录原始密钥或不必要的个人数据。
这一部分对企业客户尤其重要。他们通常不期待零事故，但期待团队能发现、解释、控制并从事故中改进。
7. 已知限制和风险决策
一份声称所有问题都解决了的材料包，通常不如一份清楚列出剩余风险的材料包可信。已知限制能帮助客户理解真实运行边界。
列出开放风险，包含 severity、mitigation、owner、decision date 和 review date。例如：浏览器自动化限制在批准域名内；超过阈值的退款必须人工审批；受监管账户禁用 memory；导出目的地限制在 allowlisted domains；模型和工具变更前运行 prompt injection 测试。
每个限制都应该有 owner。没有 owner 的限制会变成背景噪音。有 owner 的限制才是被治理的风险。
8. 发布和回归流程
材料包还应该解释客户会议后如何持续保持安全。模型变化、prompt 编辑、检索更新、新工具和审批 UX 调整，都可能改变 Agent 行为。安全审查者会想知道团队如何在生产前抓住回归。
准备一份 release checklist，包括 guardrail regression tests、prompt injection fixtures、工具权限测试、数据流出测试、审批范围测试和日志检查。保存 last-run date 和 release decision。这会把安全从一次性声明变成运营流程。
会议前应该发送什么
不要发送一份巨大的内部文档。发送一份简洁材料包，包含架构图、范围声明、工具清单、数据流向图、prompt injection 测试摘要、审批样例、trace 样例、已知限制和审查联系人。更深的证据可以放在链接或附录里。
材料包应该让客户感觉团队已经提前做过困难思考。如果客户必须在会议中一点点发现所有边界，审查会显得很不成熟。如果材料包清楚写出边界并展示证据，对话就可以聚焦在适配、例外和下一步。
相关资源
- AI Agent Readiness Audit 样例报告
- 客户批准前会问的 AI Agent 安全审查问题
- 面向客户安全审查的 AI Agent Guardrail 证据包
- AI Agent Guardrail 测试示例
- AI Agent Readiness Audit
如果你的团队需要在客户安全会议前做独立审查，可以运行 AI Agent 就绪度自评，或申请 AI Agent Readiness Audit。