当客户问你的 AI Agent 是否安全时，一句 “we use guardrails” 已经不够了。买家听过太多类似说法。他们知道 guardrail 可能只是一个 system prompt，也可能是一套真正包含测试、日志、审批和负责人的控制体系。如果客户要把 Agent 放到客户数据、内部系统、浏览器会话或可写工具旁边，他们需要看到证据。
Guardrail 证据包，就是在客户安全审查中可以安全分享的一组材料。它不暴露密钥、完整 prompt、token 或可被利用的内部细节。它要说明团队知道 Agent 可以做什么、不能做什么，这些边界如何测试，模型尝试越界时会发生什么，以及上线后谁负责这些控制。
这篇文章面向准备企业试点或付费交付的 founder、产品负责人、安全审查者和工程团队。目标很简单：把模糊的安全承诺变成可审查证据。
1. 从控制摘要开始
证据包第一页应该是一份简短控制摘要。保持朴素，说明 Agent 的角色、可访问的数据、可调用的工具、能自动完成的动作，以及需要人工审批的动作。如果 Agent 是只读的，要说明只读在实践中是什么意思。如果它可以写入或发送数据，要说明审批点在哪里。
这份摘要帮助买家在读细节前先理解边界。它不应该像营销文案。有效的控制摘要会具体说明，例如 Agent 可以基于已批准知识库起草客服回复，不能未经审批发送回复，不能访问支付明细，也不能浏览批准域名之外的网站。
2. 加入 guardrail 清单
把 guardrail 当作控制项列出来，而不是产品口号。好的类别包括 prompt injection 处理、工具权限执行、数据脱敏、检索源边界、浏览器 origin 限制、审批门、memory 范围、租户隔离、日志、速率限制和事故回滚。每个控制项都应包含负责人、执行层和最近审查日期。
执行层很重要。有些控制在 prompt 里，有些在编排层，有些在工具 wrapper 里，有些在身份和访问管理里，还有一些在人工审查中。客户更容易信任一份能区分“模型指导”和“系统强制限制”的证据包。
3. 展示测试用例和预期结果
客户不需要看到所有内部测试，但应该看到有代表性的例子。用一个小表格列出测试场景、预期行为、最新结果和证据链接或 trace ID。场景应覆盖正常任务和对抗任务：文档里的敌对文本、试图发出指令的工具结果、要求把数据发送到新目的地的请求、要求 Agent 跳过策略的浏览器页面，以及需要审批的用户请求。
预期行为要精确。“安全”太模糊。更好的结果是拒绝、脱敏、请求审批、忽略不可信指令、停止浏览器动作、升级人工，或只基于有依据引用回答。精确会让证据包更可信，因为它说明团队已经定义了成功是什么。
4. 增加审批证据
如果 Agent 使用人工审批，要证明审批是有意义的。加入一份去敏后的审批 payload 或截图。审查者应该能看到 proposed action、受影响记录、数据将去哪里、命中了哪条策略、Agent 的建议是什么，以及人工有哪些选项。
弱审批门只显示 approve 或 reject。更强的审批门会在动作前展示上下文，并允许 reviewer 批准、编辑、拒绝或升级。对客户审查来说，这通常比长篇解释模型行为更有说服力，因为它展示了人工控制真正进入工作流的位置。
5. 提供不泄露内部细节的 trace 示例
Trace 证据很有用，但必须脱敏。不要分享原始 prompt、密钥、完整客户记录、私钥或敏感日志。可以提供去敏示例，展示决策路径：输入类别、信任标签、命中的策略、工具请求、被检查的参数、审批状态、脱敏结果和最终结果。
重点是证明系统能解释为什么允许或阻止一个动作。客户不需要全部实现细节。他们需要足够证据，相信失败可以被调查，并且这个控制不只是隐藏在 prompt 里。
6. 记录数据移动边界
很多买家问题本质上是数据移动问题。Agent 可以从哪里读？可以写到哪里？能不能发邮件？能不能上传文件？能不能调用外部 API？能不能把客户数据放进日志、分析事件、模型 memory 或支持工单？好的证据包应该直接回答这些问题。
加入一份简单的数据移动图。图太重的话，用文字也可以。列出批准的数据源、批准的目的地、禁止目的地和需要审查的目的地。如果敏感数据在离开某个边界前会被脱敏，要说明脱敏发生在哪里、如何被测试。
7. 写明已知缺口和修复日期
看起来完美的证据包，反而不如诚实的证据包可信。真实系统通常都有缺口：浏览器测试不完整、负向 fixture 较少、trace 需要人工复查、保留策略不完整、内部角色过宽，或审批界面上下文不足。客户可以接受缺口，只要团队清楚命名并有计划。
用一个小表格列出缺口、风险、当前缓解措施、负责人和目标日期。这会把弱点变成被管理的事项，也能避免销售流程过度承诺。如果某个控制只是计划中但未部署，要直接说明。安全买家更喜欢准确边界，而不是模糊自信。
8. 上线后保持证据包更新
证据包不应该写一次就丢掉。Prompt、模型、工具、检索源、浏览器控制器、审批流、数据源和客户群变化时，guardrail 都会变化。给证据包加版本号和更新时间。让最近一次测试日期可见。记录哪些变化触发了新审查。
对早期团队来说，每月复查通常足够，除非 Agent 变化很快。对高风险 Agent，每次企业 rollout 或重大工具扩展前都应该更新证据包。维护习惯很重要，因为过期证据会制造虚假的信任。
9. 决定什么不能分享
客户安全审查不要求暴露所有东西。不要分享原始 system prompt、认证密钥、利用说明、内部漏洞细节、完整日志、个人数据，或足以帮助攻击者的架构细节。证据包应该证明控制质量，而不是变成攻击手册。
当客户要求更多细节时，可以在 NDA 下做 live walkthrough，或提供去敏摘录。保留一份内部证据包和一份客户安全版本。内部包可以包含更深的 trace 和修复细节，客户包则应该具体但谨慎。
10. 把证据连接到购买决策
证据包应该回答买家的实际问题：这个 Agent 能访问我们的客户数据吗？能执行不可逆动作吗？会不会通过工具或网页泄露信息？审批如何被强制执行？Guardrail 失败时会发生什么？谁审查日志？多快可以关闭高风险工作流？
如果证据包能清楚回答这些问题，它就不只是安全附件，而是销售资产。它减少审查摩擦，避免模糊承诺，并在完整采购流程开始前给买家一个信任团队的理由。
最低客户安全证据包
至少准备这些材料：控制摘要、guardrail 清单、代表性测试用例、最新测试结果、去敏审批示例、去敏 trace 示例、数据移动图、已知缺口、修复日期、负责人列表，以及事故/回滚联系路径。它应该足够短，买家愿意读；也要足够具体，让安全审查者能提出有质量的追问。
相关资源
- AI Agent Guardrails：能抓什么、漏什么、如何测试
- AI Agent Guardrail 回归测试清单
- AI Agent 信任边界审查清单
- AI Agent 权限漂移审查清单
- OWASP Top 10 for Large Language Model Applications
如果要做更完整的就绪度审查，可以使用 AI Agent 就绪度自评，或申请 AI Agent Readiness Audit。