Agent 安全为何必须成为 Runtime Contract

原始论文：Albus W Ng 等，Agent Safety Should Be a Runtime Contract，arXiv:2608.11274v1，2026-08-11。

从回答安全走向行动安全

传统大模型安全主要处理回答层问题：模型会不会生成危险内容、泄露敏感信息或违背人类偏好。这套方法在对话产品中十分重要，但 Agent 的风险已经超出回答本身。

一个拥有 Shell、Browser、数据库和企业 API 的 Agent 可以修改代码、发送邮件、发布服务、调整权限、删除资源或触发支付。此时，语言输出只是行动链的一部分，真实风险发生在 Runtime 产生副作用的时刻。

训练阶段的安全方法在这里面临五类错配：

错配	典型表现	Runtime 需要补充的能力
统计偏好与明确规范	模型倾向谨慎，但无法替代确定的权限规则	Policy、Approval、Default Deny
训练分布与开放环境	工具、依赖和攻击面持续变化	沙箱、最小权限、持续监测
内部推理与可复现事实	模型声称执行过某项操作	轨迹、日志、外部状态证据
可信表达与真实完成	回答听起来完整，实际测试或提交缺失	Evidence-gated Completion
单层对齐与纵深防御	单个保护机制失效后缺少补偿	预防、检测、恢复、审计

核心变化是：Agent 安全不能只问“模型是否倾向做正确的事”，还要问“系统是否只允许合规行动发生，并能证明行动结果”。

Runtime Contract 的两个面

论文把 Agent 安全定义为一种运行时契约，由预防性约束和证据性约束共同组成。

预防性契约：限制行动如何发生

预防性契约借鉴计算机安全中的成熟原则：

最小权限：任务只获得完成当前目标所需的工具、数据和作用域。
失效安全默认值：未知动作、缺失身份和无法解析的高风险请求进入拒绝或人工确认。
完整中介：每一次敏感动作都经过策略检查，不能依赖首次授权长期放行。
纵深防御：权限、沙箱、网络边界、动作审批、监控和回滚形成多层保护。
可审计性：策略判断、批准对象、实际执行对象和执行结果保持可关联。

证据性契约：限制何时可以宣布完成

论文提出 Evidence-gated Submission：Agent 只有在提供足够、可验证的外部证据后，才可以把任务状态提交为完成。

flowchart LR Intent["任务意图"] --> Plan["Agent 规划"] Plan --> Gate{"动作契约"} Gate -->|"允许"| Execute["工具执行"] Gate -->|"拒绝或确认"| Replan["修正或人工批准"] Replan --> Plan Execute --> Trace["轨迹与外部状态"] Trace --> Verify{"完成契约"} Verify -->|"证据合格"| Deliver["交付结果与回执"] Verify -->|"证据不足"| Replan

这里的“证据”必须区分强弱：

类型	内容	能证明什么
硬证据	测试重跑、提交哈希、文件差异、数据库快照、引用查验、截图差异	某个外部事实在特定状态下成立
软证据	模型解释、总结、自我评价、Chain-of-thought	提供线索和语义背景

模型关于自身行为的陈述可以帮助调查，但不能单独承担完成证明。

安全对象从模型转向轨迹

论文提出一个重要重构：安全评估的基本单元应是“带有可检查证据的执行轨迹”，而不是孤立的模型。

轨迹可以记录：

指令来源
→ 计划与重规划
→ 工具调用及参数
→ 权限与审批结果
→ 文件、数据库和外部系统变化
→ 测试与验证结果
→ 最终交付物

论文进一步使用哈希链连接轨迹事件，使记录具备篡改可见性。这可以证明事件链在记录后保持完整，但语义正确性仍要依赖外部验证：一条完整的日志可能记录了错误操作，一次通过的测试也可能使用了错误断言。

论文证据说明了什么

作者分析了 52 起公开 Agent 事故，反事实判断其中 40 起可以由功能性 Harness 直接预防，11 起可以缓解。对 32 个错误完成案例的分析表明，引用核验、日志捕获、测试运行、人工批准、外部状态检查和截图即可覆盖大多数失败类型。

作者还检查了 12 个公开 Agent 或 Harness 系统。多数系统已经生成文件变化、工具输出或结构化日志，但只有 2 个明确把这些材料设置为提交门槛。这说明行业并不缺执行证据，缺少的是把证据提升为完成条件的制度设计。论文正文

这些结果适合视为方向性证据。事故能否被某种 Harness 阻止来自研究者的反事实编码，论文也没有通过长期生产实验测量误拦截率、维护成本和用户接受度。

对 Agent 平台架构的启发

企业 Agent Runtime 可以把一次任务拆成两个独立契约。

Action Contract

action:
  operation: repository.push
  target: service/main
  actor: release-agent
  risk: high
  required_scope: repository.write
  approval: release-owner
  reversible: false

Action Contract 回答：谁可以在什么上下文中，以什么权限，对哪个目标执行什么动作。

Completion Contract

completion:
  required_evidence:
    - non_empty_diff
    - commit_hash
    - test_exit_code_zero
    - approved_action_receipt

Completion Contract 回答：交付状态必须引用哪些证据，哪些验证器负责检查这些证据。

两者共同构成 Runtime 的可信边界：前者降低危险行动发生的概率，后者降低虚假完成进入业务流程的概率。

用户体验：把审批变成风险与证据的界面

Runtime Contract 并不意味着所有操作都增加确认步骤。合理的产品设计应让安全成本与风险匹配：

读取、分析和可恢复修改保持连续执行；
外发、删除、支付、权限变更和生产发布触发明确审批；
审批界面展示动作、目标、影响范围、可逆性和证据；
任务进度展示已经完成并验证的步骤；
交付结果附带测试、变更和外部状态回执。

用户真正需要的不是更多弹窗，而是更准确的信任校准：什么时候可以让 Agent 自主行动，什么时候必须介入，完成声明为何可信。

一种程序性的安全哲学

这篇论文连接了两条历史经验。

计算机安全从“可信组件必然正确”转向最小权限、零信任和纵深防御；现代科学从权威陈述转向实验装置、方法公开、可复现证据和同行验证。两者都把信任从行动者的内在品质转移到外部制度与可检查产物。

Agent Runtime 因而具有类似“宪法”的作用：模型拥有提出方案的自由，系统规定哪些行动可执行、哪些事实可被接受、哪些决定必须获得额外授权。

这种制度同样需要防止官僚化和 Verifier Goodhart。验证器可能错误，测试可能不稳定，固定证据目标也可能被优化利用。成熟实现需要多源证据、验证器版本、异常申诉、人工复核和持续回归，让契约服务于真实任务目标，而不是取代真实目标。

结语

Agent 安全的下一阶段，是建设一个能够限制行动、记录事实、验证完成并支持恢复的 Runtime。

模型决定“下一步可以做什么”；Runtime 决定“什么可以真正发生，以及什么可以被称为完成”。这将成为企业 Agent 平台区别于单次模型调用的核心工程边界。