大多数 AI Agent 安全审查并不是从夸张的红队场景开始的。它通常从客户、Security Lead 或平台负责人提出几个很朴素的问题开始：这个 Agent 能访问什么，能修改什么，数据能流向哪里，如果出问题，有什么证据可以复盘？
这些问题听起来基础，但很多 AI Agent 项目正是在这里卡住。Demo 可以展示一个很顺的工作流，产品页也可以写上 guardrails，但这并不能证明 Agent 已经适合处理客户数据、调用工具、使用浏览器会话、检索私有知识库，或者在生产系统旁边做决策。
这篇文章整理客户在批准 AI Agent 前经常会问的安全审查问题。它适用于正在销售、部署或内部上线 AI Agent 的团队，尤其是那些使用工具、RAG、memory、客户记录、浏览器自动化、工单系统或写入动作的 Agent。目标不是做一本厚厚的合规材料，而是在审查会议开始前准备好可以支撑决策的证据。
1. Agent 能访问什么？
第一个问题通常是访问权限。审查者会想知道 Agent 可以读取哪些系统、看到哪些记录，以及这些访问权限是继承自用户、单独授予 Agent，还是通过共享 service account 获得。
比较弱的回答是：“Agent 只访问它需要的内容。” 更好的回答应该列出系统、scope、角色、租户边界，以及实际强制执行这些边界的机制。如果 Agent 可以搜索工单、读取文档、查看 CRM 记录或打开浏览器页面，审查者需要知道权限在哪里被检查。
应该准备的证据包括访问矩阵、service account scopes、用户委托规则、租户隔离测试和被拒绝访问的示例。被拒绝的示例很重要，因为它说明边界确实被执行，而不只是被描述。
2. Agent 能修改什么？
只读 Agent 通常比可以写入的 Agent 更容易通过审批。一旦 Agent 可以写入、删除、发送、发布、退款、修改权限或触发面向客户的动作，审查重点就会从内容质量转向运营控制。
客户会问：哪些动作允许，哪些动作禁止，哪些动作需要人工审批，审批是否和具体动作绑定。“Human in the loop” 本身不够。如果审批界面没有显示 payload、受影响记录、目的地和风险类别，它很难让人放心。
应该准备工具清单，并把工具按 read/write 分类，标注审批要求，提供审批记录样例和 blocked-action trace。如果 Agent 可以起草邮件但不能发送，可以建议退款但不能执行退款，这种边界要写清楚。
3. 数据可以离开环境吗？
数据流出是最快破坏客户信任的问题之一。Agent 总结客户数据是一回事。Agent 可以把数据发送到邮箱、webhook、表格、第三方应用或浏览器表单，就是另一回事。
安全审查者会问：目的地是否有 allowlist，新增目的地是否需要审批，敏感字段是否脱敏，Agent 是否可能被一个看似正常的效率请求诱导导出数据。
应该准备 destination allowlist、数据分类规则、脱敏示例、egress logs，以及对未批准邮箱或 webhook 的测试用例。对于连接客服、销售、HR、财务或内部知识库的 Agent，这一点尤其重要。
4. 你们如何处理 Prompt Injection？
客户已经逐渐意识到，prompt injection 不只是聊天窗口的问题。它可能来自检索文档、网页、工具返回结果、邮件、工单、评论或用户粘贴的内容。真正的问题是：Agent 是否把不可信内容当作数据，还是让它变成了指令。
可信的回答需要解释 system instructions、developer policies、用户请求、检索内容和工具输出之间的信任边界。它还需要测试结果。只有策略声明，没有测试证据，对严肃审查来说是不够的。
应该准备 prompt injection fixtures、RAG 攻击示例、浏览器页面注入示例、工具输出注入示例，以及 trace，证明 Agent 忽略或隔离了恶意指令。每个示例都要能对应到实际起作用的控制。
5. 系统记录了哪些证据？
一旦出现问题，客户不会只想看一段模糊的对话。他们会想知道用户问了什么，检索了什么上下文，调用了哪些工具，哪个策略生效，谁批准了动作，最终输出或副作用是什么。
好的证据不是把所有东西永久记录下来，而是在不把敏感数据泄露到分析或调试日志的前提下，保留足够结构化的信息来支持事故复盘。
应该准备 sample trace、保留策略、脱敏策略、审批日志、工具调用日志和事故复盘示例。很多时候，一条真实的 sample trace 比一大段口头解释更有说服力，因为审查者能直接看到决策是如何被记录的。
6. 证据不足时 Agent 会怎么做？
很多 Agent 失败不是攻击导致的，而是因为上下文不完整、文档过期、策略冲突、权限缺失或用户意图模糊。客户会问：Agent 是猜测、追问、说明不确定性，还是升级给人工？
应该准备几个 Agent 拒绝过度回答的示例。比如检索来源冲突的情况、缺少账户上下文的情况，以及因为证据不足而转人工的情况。这能帮助客户看到 Agent 是为生产现实设计的，而不只是为 happy path demo 设计的。
7. 模型、Prompt 和工具变化如何测试？
安全批准不是一次性事件。模型变化、prompt 重写、检索设置更新、新工具、审批 UX 调整，都可能改变 Agent 行为。越来越多客户会问：你们如何防止一个安全的 demo 在三周后变成不安全的 release？
应该为 prompt injection、工具权限、数据流动、审批范围、敏感数据处理和 grounded answering 准备回归测试。每个测试保存 last-run date、version、result、owner 和 release decision。如果测试失败，发布流程应该在上线前暴露这个失败。
8. 未解决风险由谁负责？
有些风险在上线前无法完全消除。如果风险被理解、记录、缓解并且有人负责，这可能是可以接受的。但如果没人能说清楚谁接受了风险，什么情况下会重新评估，那就很危险。
应该准备 risk register，包含 severity、owner、mitigation、residual risk、decision date 和 review date。对客户审查来说，可以把它翻译成更直白的语言。客户不需要看到所有内部争论，但需要看到风险是被治理的，而不是现场 improvisation。
9. 审查材料包应该包含什么？
一个有用的 AI Agent 安全审查材料包，通常应该包含架构图、工具清单、访问矩阵、数据流向图、审批策略、guardrail 测试结果、prompt injection 测试、sample traces、事故响应流程、发布回归流程和已知限制。
材料要具体。一个短但有真实证据的材料包，胜过一份充满承诺的长文档。如果某个控制还没有实现，要直接说明，并写清楚临时缓解措施。审查者通常更能接受诚实的限制，而不是无法验证的漂亮说法。
相关资源
- AI Agent Readiness Audit 样例报告
- AI Agent Readiness Audit
- AI Agent Guardrails Hub
- 面向客户安全审查的 AI Agent Guardrail 证据包
- AI Agent Guardrail 测试示例
如果你正在为客户安全审查准备 Agent，可以运行 AI Agent 就绪度自评，或申请 AI Agent Readiness Audit。