# 让智能体解释，让控制机制决策。 **安全设计笔记 · 2026 年 9 月 7 日 · 这是拟议架构，不是安全认证。** 智能体可以解释为什么一份报告看起来符合请求。这种说明可能确实有帮助。但它不等同于检查报告经过认证的字节、比较确切交易字段或授权转账。如果系统让有说服力的文字代替这些操作，就把决策边界放错了位置。 Proof21 的拟议角色是提供证据，而不是托管资产或不受限制地执行。报告应让具体检查更容易复现。独立的使用方策略决定证据允许什么后续步骤。这样既能发挥智能体的能力，也不必让语言模型成为资金、凭证和生产设置的唯一守门人。 ## 检索内容即使语气权威，也仍是数据 检索到的文档、工具响应或铭文，可能包含看似指令的文字。自信语气或格式不会赋予它凌驾于用户任务之上的权限。OWASP 的提示注入指南把间接内容和工具相关影响视为重要攻击面，并建议分层控制，而不是依赖一句令人安心的提示。[1] 拟议检查工作流中，生成方的说明属于被评估的证据。它不能改变使用方可信的收款方、策略阈值、允许访问的主机列表或审批要求。原始用户指令与配置策略应单独保留，与被评估方提供的材料分开。 CaMeL 等研究探索控制流与数据流的架构分离，以及模型工具使用周围基于能力的限制。这是有用的研究参考，不代表 Proof21 已实现该系统，或继承其评估中的保证。设计必须以自己的实现和测试来判断。[2] ## 分开读取、检查、批准与行动 设想一个合成的应付账款助手。第一步读取发票及相关证据；检查器随后将受支持字段与已授权指令比较；控制器评估结果是否充分；获得授权的执行系统只能在必要批准之后行动。即使用户看到的是简洁界面，这些仍是不同阶段。 读取阶段不应需要支付签名密钥。检查阶段不能因为发现不匹配就悄悄获得发送资金的权限。说明阶段不应能修改原始指令。在可行时分离凭证与进程，使边界由系统执行，而不只是用文字请求。 行动本身也应保持精确。批准某个收款方、资产、网络和整数金额，不能变成批准后来修改的载荷。把已审阅的操作及其到期或时效条件绑定到最终动作。相关状态可能在审查与执行之间变化时，应重新检查。过时批准不能成为无限期通行证。 ## 未解决结果不是临场发挥的许可 必需证据不可获得时，检查器应返回 `INDETERMINATE`，并指出缺失依赖。下一步可以是等待、请求补充证据或升级给获授权人员，而不是智能体为了得到好看的正面结果，悄悄更换提供者、修改策略或重试不可逆行动。 同样，真实有效的负面报告也可能有用。控制器可以接受它用于监控或调查，同时拒绝后续金融行动。产物完整性、主张评估与本地接受之间的区分，不是繁文缛节；它防止有效签名变成意外授权。 网络访问也需要类似边界。获取证据 URL 时，不应携带不受限制的环境凭证。限制目的地、重定向、响应大小和超时，并避免把秘密放入日志或模型可见材料。MCP 安全指南讨论了令牌透传和中间方风险；集成必须保留凭证预期的接收方与权限。[3] ## 人工批准应展示决策，而不是隐藏它 有用的批准界面应指明确切行动，以及相对原始指令的重要差异。以审核者能检查的形式显示收款方、网络、资产、金额、证据状态与策略结果。不要让人批准“完成工作流”这类模糊陈述，却把真实载荷藏在友好的摘要后面。 批准也需要范围。读取报告不等于批准发布报告。运行离线演示不等于批准连接钱包。审阅发布版本不等于批准修改 DNS、计费、仓库可见性或生产部署。良好的控制器应把这些区分一直传递到实际执行工作的工具。 拒绝路径应可用。审核者必须能拒绝或要求澄清，而不是应用反复把同一个动作展示为不可避免。记录决策及上下文，同时避免不必要地保留敏感数据。只有描述真实发生之事的审计记录才有价值。 ## 测试边界，而不是销售口号 试点应把误导性指令放入合成证据，确认它们不能改变配置策略或行动范围。测试批准后收款方被修改、批准过期、操作标识错误、报告版本不支持和证据获取失败。同时加入合法成功案例，避免把拒绝一切的系统误认为有用方案。 衡量阻止了多少未授权行动、完成了多少合法任务、升级了多少未解决案例，以及理解决定所需的工作。区分样例测试结果与生产观察。有限测试集不能建立对所有提示注入的普遍免疫；基于模型的护栏本身仍需要独立威胁模型。 当前 Proof21 离线演示有意避开钱包、网络调用与真实付款。这使它成为较安全的教育起点，而不是已经完成的生产控制平台。下一步实现应保留明确边界，一次增加一项经过审查的能力，同时提供可复现证据，并让使用方保留权限。 ## 常见问题 ### 大语言模型应该是密码学产物的唯一验证器吗？ 不应该。确切主张应使用受支持的确定性解析、密码学验证和策略检查。模型可以解释结果并帮助浏览证据，但其叙述不能替代这些检查。 ### 检查失败会授权智能体修复付款吗？ 不会。不匹配是证据，不是授权。任何纠正动作都需要应用自己的授权、精确载荷审阅，以及防止重复或非预期动作的保护。 ### 这些控制能保证提示注入不可能发生吗？ 没有这样的保证。它们定义可测试的边界与分层防御。效果取决于实际实现、部署、所支持的威胁模型和持续审查。 ## 原始与学术参考资料 - [1：OWASP — 大语言模型提示注入防御指南](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) - [2：Debenedetti 等 — 从设计上防御提示注入](https://arxiv.org/abs/2503.18813) - [3：MCP — 安全最佳实践](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices) - [Proof21 安全边界](https://proof21.xyz/zh-hans/docs/protocol/security/) - [离线演示及其限制](https://proof21.xyz/zh-hans/docs/start/offline-demo/)