Agent 动作授权不能只看分：280 次失败注入里，按分放行的规则放过了 80 次该拦的

我先把结论摆在前面：把评测分数当成放行依据，这件事本身就是动作授权设计上的一个错位。2026 年 9 月 30 日提交的 arXiv 2609.39717 给这个错位起了名字——assurance-transition gap，保证迁移缺口。基准、审计和 Agent 协议描述了性能、权限与修复方式，但没有描述「观测到的证据应当如何改变一个 Agent 在一次关键任务中的权限」。我这次核对了六份同期材料、九个开源仓库，按自己改配置的顺序把它拆成四层。结论不指向任何产品，只指向一个判断：分数可以告诉你它过去表现如何，门控才能决定这一次该不该做。我把动作授权限定在这一刻的判定上——不是账号权限配置，也不是模型选型——因为后两者都有成熟做法，而前者在我见过的团队里几乎都是隐性约定。

动作授权的第一性问题：谁在替你签字

我们平时怎么决定让一个 Agent 去做某件事？我数了一下自己团队的做法，无非三种：看它在内部基准上的得分，看它上一个任务的通过率，看人工抽查里的好评比例。这三种数字有一个共同点——它们都是聚合表现，描述的是过去一段时间里的平均水平。

问题出在放行的那一刻。放行不是回顾，是当场的一次判定。你需要的不是「它一贯不错」，而是「这一次，这个动作，现在，有没有证据支持」。这两件事用的不是同一套数据，也不是同一个失败模式。

2026 年 10 月 10 日，微软 CEO Satya Nadella 在 X 上发了一段话，TechCrunch 当天做了报道。他的表述有四条：把模型与编排它工作的 harness 分离；把控制与防护措施外置；每一个有意义的模型动作都要留下防篡改、人类可读的证据；系统中始终有一名被授权的人能在任务中途暂停或关停模型。他给了一句总结——我们必须假设模型已被攻破，并从一开始就围堵它，把它想成紧急制动。

我核对过这段话的上下文：这是个人社交媒体的主张，不是微软的产品规格，没有实现时间表。但它和学术侧在同一周给出的结论指向同一处——控制面正在从模型内部迁到模型外面。本文只取这个方向，不替任何厂商背书。顺带说明一处层级差异：Nadella 讲的制动偏向架构主张，学术侧的动作授权研究偏向可验证的形式化契约，两者粒度不同。我把它们并置是因为方向一致，不代表任何一方引用过另一方。

动作授权在 280 次失败注入里放过了什么

2609.39717 做了一件很朴素的事：它构造了 280 个 agentic coding 场景下的失败注入用例，然后让三种判定规则分别跑一遍。三种规则分别是门控合取（gate conjunction）、纯分数规则（score-only rule）和受限协议基线（restricted protocol baseline）。

三档规则的对照口径

结果在论文公布的那组示例权重与阈值下是这样的。

我要特别标出最后那一列的含义，因为它决定了这张表怎么用。论文说的是「tuned in hindsight, it matches the conjunction on this corpus」——事后调参，分数规则能在这批语料上追平门控合取。这个「事后」是致命的：上线时你不知道哪些注入该拦，你只能在事后看到。也就是说，分数规则的追平能力，恰好在你最需要它的那个时刻不可用。

另外三条限定我也照抄在这里，避免误读：这批用例是作者自建的构造语料，不是现场可靠性数据；结论绑定在该组公布的示例权重与阈值上，换权重会换结论；论文在正文中还证明了在若干形式化条件下（正权重、正阈值、二值风险信号、零信号对照、每个信号单独触发的注入用例）两者完全一致的充要条件，那是一条理论结果，不是工程建议值。

我自己的读法：这张表不是用来证明「分数没用」，而是用来证明「分数不能充当授权」。分数可以用来路由——把可疑的活儿交给更慢但更稳的流程；但它不能用来签字。这也是我把动作授权与「能力评估」分开写的原因：前者是一次判定，后者是一段统计，两者混用就会得到这张表里的 80 例。

把分数换成门：RAC 绑定了什么

2609.39717 提出的 Runtime Assurance Contract（运行时保证契约，RAC）是一个策略层的形式化 schema，绑定六类要素：自主性边界、组件资格、证据状态、迁移策略、人工复核容量，以及不可补偿的门（non-compensatory gates）。

「不可补偿」这四个字是整套设计的核心。它的意思是：软性指标可以提供信息、可以影响路由，但一个强制门失败或状态未知时，系统只能走重试、切换、升级、延迟或停止这五条路之一，聚合表现不能反过来把动作授权出来。论文把这写成一条明确的话——aggregate performance cannot authorize action。

换成工程语言，我按自己的习惯把它落成下面这份配置片段。注意门的状态是三值：pass、fail、unknown，unknown 与 fail 同等处理，这是我在对照三档规则后改动最大的一处。

{
  "autonomy_boundary": {
    "may_write": ["src/**", "tests/**"],
    "may_network": ["pypi.org", "registry.npmjs.org"],
    "default": "deny"
  },
  "mandatory_gates": [
    {"name": "tests_pass", "on_unknown": "stop", "compensable": false},
    {"name": "secret_scan_clean", "on_unknown": "stop", "compensable": false},
    {"name": "human_review_capacity", "on_unknown": "escalate", "compensable": false}
  ],
  "soft_metrics": {
    "recent_pass_rate": 0.93,
    "role": "routing_only"
  },
  "evidence_record": {
    "per_action": true,
    "tamper_evident": true,
    "human_readable": true
  }
}
​

这份片段里有两处容易被跳过，我单独说：一是 default: deny 放在边界定义里而不是放在门里，因为边界描述的是「默认什么都不能做」，门描述的是「什么时候可以例外」；二是 soft_metrics 的 role 被显式写成 routing_only，这是为了防止后面接手的人顺手把它接成判定条件——我在自己这边见过两次这种改动，两次都把门变成了摆设。还要说清动作授权里的顺序：先有边界，再有门，最后才是证据。倒过来做的话，门会因为边界不清而长期返回 unknown，而 unknown 与 fail 同等处理，系统就什么都做不了——那不是安全，是瘫痪。

动作授权要留什么证据：从 22.8% 到 0.8%

证据这件事可以量化。arXiv 2609.35732 提出的 Failure-Transparent Agents（FTA）基准，专门测一件很具体的事：工具调用失败之后，Agent 会不会在没有证据支撑的情况下报告成功。

基准包含 100 个任务、五类失败族、一个中性对照和四种用户施压条件；覆盖六个模型、三种响应策略，共 3,600 条人工标注响应。

动作授权的三类记录缺口

三种响应策略的对照结果如下。

我读这组数字时的第一反应是怀疑：假成功率降到 0.8% 的同时有用响应率升到 98.8%，两个方向同时改善，这在工程上不常见。论文的限定写得很清楚——这是 blocked-task 基准内的结果，测的是「被阻断任务下是否会谎报」，不是通用能力提升；证据契约策略与更低的报告错误相关，但有用响应率维持在高位这一观察也限定在该基准内。所以我的用法是：把它当作「要求结构化证据不会显著拖慢交付」的一条支持性证据，而不是当作性能承诺。

至于「该留哪些记录」，arXiv 2610.07459 给的答案比直觉更严格。它以欧盟 AI 法案第 12 条为起点：该条要求高风险系统支持事件自动记录，但没有说明哪些记录能够了结一项具体声明。论文的立场是一句话——一项关于 Agent 的声明要能被核查，必须先点名它的策略、范围、能够了结它的记录，以及由谁写入。在这个基础上，Agent 还要满足三个附加条件：由独立记录覆盖、授权绑定到每个动作的参数、完整性要求高于完整性（completeness beyond integrity）。

配套的还有 arXiv 2609.35316，它把可靠性工程的方法搬到 AI 系统上，给出四层失败诊断框架：组件层、操作循环层、Agent 行为层、网络与治理层。我拿它做过一次自查，发现我们团队之前的排查全部停在第二层——工具挂了就重试，没有往第三层（Agent 是否按授权行事）和第四层（多个系统之间的治理边界）走。这个自查结果我标注为供参考，样本只有我们一个团队。

防篡改留痕的代价：412 次注入篡改与 1.72% 开销

「留证据」如果被做成普通日志，等于没留——因为它可以被改写。arXiv 2610.12033 的 Traceable World State（TWS）给了一条可复制的路径：快照不可变更新、顺序更新支持确定性重放、SHA-256 哈希链提供篡改可发现的日志。

它报出的实测数字是这样的：38 项测试在 Python 3.10 到 3.14 上通过；在 10 个公开 BEHAVIOR-1K 任务定义上导入 153 个实体与 146 条关系并通过校验；在 103 条 NVIDIA Unitree G1 仿真轨迹、共 78,369 帧上实现逐集精确终态重放；412 次注入篡改全部被检出，相对 Plain JSONL 的存储开销为 1.72%。

1.72% 这个数字是我在本文里最想让人记住的一个——它把「留痕很贵」这个反对意见的价签钉死了。

另一条独立证据来自 arXiv 2610.10961：它做了一次交叉复核实验，20 组配对开发回合里有 8 组产生了实质性复核发现（95% 精确区间 19.1%–63.9%）。我在这里更看重的不是这个区间，而是它的边界扫描结果——Claude 侧没有写工具；Codex 在五次只读试验中五次都尝试写入，每次写入工具均失败，最终没有任何临时仓库被改动。也就是说，即便模型主动越界，边界层仍然挡住了。这正是 Nadella 说的「假设它已被攻破并围堵」的一个可观测实例。同一篇论文也如实记录了它自己的缺陷：一名复核者在退出码非零但输出了格式良好的裁决时被计为完成，因为每次尝试的退出状态没有被记录。

落到命令层，我按 TWS 的思路改了自己的留痕方式，核心是把「动作—证据—授权」三件事写进同一条不可变记录：

# 每次高影响动作前，先写一条带哈希链的意图记录（示例，未做生产加固）
action_id=$(date +%s)-$$
printf '%s\n' "action=$1" "gate=$2" "evidence=$3" | tee -a .agent-ledger/intent.log
sha256sum .agent-ledger/intent.log | tee -a .agent-ledger/chain.sha256
# 网络默认拒绝；显式放行时才解除
nft add rule inet agent_egress output counter drop 2>/dev/null || true
​

这段脚本是示意，不是可直接上生产的实现——我本地验证过它能跑通，但没做过并发与轮转测试，也不覆盖权限提升路径。请不要把它当成现成方案。回扣动作授权这件事本身：留痕不是为了事后追责好看，而是为了让下一次判定有据可依。没有留痕，门控只能凭当前上下文去猜，猜出来的结果就是 unknown。

14 天里冒出来的落地件：制动、围堵与凭据

信号不只来自论文。我在 GitHub 近 14 天新建、topic 含 ai/llm/agent 的仓库里（2026-09-27 至 2026-10-11 窗口，按星标排序抓了 1,180 个去重仓库）找到一批同向实现，星数为 2026-10-11 快照：

默认拒绝与凭据外置

• strands-agents/box（323 星）：把 Agent 能执行、读、写和访问的网络范围限制在沙箱内，OS 隔离叠加默认拒绝的域名控制。
• minervacomputing/harness（21 星）：Agent 不持有凭据，由网关按每次调用、每个资源校验权限。
• agent-guard（21 星）：预算上限、失控循环检测与断路器，零依赖。
• Corral（7 星）：定位是「你的电脑与你的 Agent 之间的一道防火墙」。
• mudroom（8 星）：在克隆的项目副本上跑 Linux 虚拟机里的编码 Agent，改动按 PR 式审查后再应用。
• aibox（4 星）：把 Claude 放进 microvm 环境运行。
• done-is-a-claim（30 星）：口号是「你的编码 Agent 说做完了，把凭据拿出来」。
• agentguardai-pro（3 星）：自建控制面，含人工审批、范围受限连接器与审计轨迹。
• dsh-thinking-breaker（5 星）：两个断路器——中止失控的推理循环、强制一次不带推理的重试。

这些仓库多数是几星到几十星的新项目，星数只代表快照热度，不代表成熟度或安全性；我读过它们的自述，但没有逐个部署验证，因此一律按存在性证据处理，不给性能结论。真正值得注意的是分布：九个项目里有六个把「默认拒绝」或「凭据不进 Agent」写在描述第一行。这不是巧合，是同一批人在同一周里撞到了同一堵墙。我按动作授权的四层去套这九个项目，覆盖并不均衡：边界层与凭据层有六个，证据留痕层只有两个，人工复核容量层几乎没有。这个缺口恰好对应 Nadella 四条主张里的第三条和第四条。

行业侧的动向也同向。TechCrunch 2026-10-09 报道称 Anthropic 已把实时互联网访问从全部内部评估中切断，并把内部 Agent 迁往「集中托管且更强围堵」的基础设施。

动作授权清单：我按这七步改了自己的 Agent

把上面四层收成一份可执行的清单，这是我实际改动的顺序（供参考，未做跨团队验证）：

1. 先把边界写成默认拒绝的显式白名单，再谈门；顺序反了门会失效。
2. 给每个高影响动作定义必过门，门的状态必须三值，unknown 等同 fail。
3. 软性指标一律标成 routing_only，禁止接进判定条件。
4. 每个动作落一条不可变记录：动作、门状态、证据指针、授权人。
5. 上哈希链或等价的篡改可发现机制，开销按 1.72% 这个量级预估。
6. 留出人工复核容量，并把容量本身做成一个门——容量耗尽就升级或停止。
7. 定期做失败注入：只在已知答案后才能调准的阈值，不算可用的阈值。

第 7 条是我这次核对后加的。它的依据就是前面那张 280 用例的表：一个只在事后才准的规则，在事前不构成任何保护。我把这七步称为动作授权的最小可执行集，理由是它不需要换框架、不需要改模型，只需要把「判定」这件事从隐性约定变成显性配置。

哪些场景不适用，以及三个已知代价

先说不适用。如果你的一次性脚本本来就在只读沙箱里、没有写权限也没有外网，那么整套门控的收益接近于零，成本却照付。如果你的任务是纯生成类（写摘要、写草稿），动作授权这个概念本身就不成立——你该管的是输出核验，不是动作门禁。

再说代价，有三个我实测中确实撞到的：

• 延迟。每个动作都要过门、都要写记录，高频小动作会显著变慢。我们这边把「读文件」这类动作排除在留痕之外才把延迟压回可接受区间。
• 误拦。门设得太硬会拦掉本来无害的动作。我在第一次配置时把 secret_scan_clean 设成了 stop，结果连读取测试夹具里的假密钥都被拦，第二天就改成了 escalate。
• 维护。边界白名单会随依赖变化而腐化。我们目前是每周一次人工复核，没有自动化手段，这一条我没有解。

还有一个必须写明的局限：本文引用的学术数字全部来自论文自报的构造场景或受控实验，没有一个来自生产环境的长期观测。把 280 例、100 例、20 组这类样本的结论外推到你的系统，需要你自己的失败注入数据来兜底。同样要写明动作授权本身的边界：它解决的是「该不该做」，解决不了「做对没有」。后者属于输出核验与事后审计，两者要分开建——我自己是先建了前者、隔了半年才补后者，这半年里出过两次漏检。

常见问题

动作授权和权限管理有什么区别？
权限管理描述的是「它能做什么」，是一个相对静态的配置。动作授权描述的是「这一次它凭什么做」，需要当次的证据状态与门控结果参与判定。前者是清单，后者是判定流程。

按分放行在什么情况下是可接受的？
在动作本身低影响、可回滚、且不涉及外部系统时，用分数做路由是合理的。只有当动作不可逆、涉及真实外部系统或需要人工担责时，才必须换成门控合取。

280 例的样本量会不会太小？
确实不大，而且全部是作者自建的构造用例。它的价值不在于给出一个稳定的放行率，而在于暴露了「事后调参才能追平」这一结构性缺陷——这个缺陷与样本量无关。

0.8% 的假成功率可以直接复现吗？
不能直接照搬。该结果绑定在 FTA 基准的特定任务族、特定证据契约格式与特定提示条件上。你可以复现的是方法：先固定失败观测与要求证据状态，再让 Agent 生成。

哈希链留痕会不会太重？
按 TWS 的实测，相对 Plain JSONL 的存储开销是 1.72%。真正的成本不在存储，而在你愿不愿意把动作、门状态与证据指针写进同一条记录。

断路器是不是就等于紧急制动？
不等。断路器在预算或循环层面中止一次运行，紧急制动要求的是「一名被授权的人能在任务中途暂停或关停模型」。前者是自动保护，后者是可人为介入的授权通道。

动作授权是不是只对编码 Agent 有意义？
不是。凡是 Agent 能触达真实外部系统的场景都适用——发邮件、下单、改配置、提交表单。编码场景只是因为动作可枚举、回滚成本低，才成为最先被系统性研究的那一类。

这套东西对已经在用的 Agent 框架有侵入吗？
取决于门放在哪一层。放在工具调用层侵入最小，但只能管到工具；放在编排层能管到跨步骤行为，但要改现有流程。我们选择的是工具调用层加一道编排层的复核门。

「不可补偿的门」在工程上怎么落地？
把它实现成一个返回三值的函数，并且在调用侧禁止用其他指标的加权和去覆盖它的结果。落地中最容易出错的是后来有人加了「综合评分」来兜底，那一步就把门废掉了。