面向自主编码代理的后果感知命令审批机制 "Shall We Approve?" Consequence-Aware Approval for Autonomous Coding Agents
Caper 在快照沙箱中预执行命令，LLM 依观测效果在提交前审批，危害率最低且误拦仅 1.0%
前置知识
自主编码代理
能多轮自主工作的 LLM 系统：编辑代码、运行构建与测试、执行 shell 命令，如 Claude Code、Codex、SWE-agent。每轮提出一个动作、读取工具结果、继续规划，工作区状态随命令持续演变。
本文的安全防护对象正是这类代理发出的 shell 命令，理解其「提议—执行—反馈」的有状态循环，才能明白审批该插在哪个环节、为什么事后撤销来不及。
沙箱快照与回滚
把容器某一时刻的完整文件系统状态保存为快照，之后可将容器恢复到该状态，类似数据库事务的 BEGIN/ROLLBACK。本文用 Docker 快照让命令「先试跑、被拒即回滚」，代理不会继承被拒命令的任何改动。
预执行加回滚是 Caper 敢于真实运行不可信代码而不留副作用的关键，理解它才能理解「先跑再批」的事务性保证及其边界（容器外效果回滚不了）。
系统调用追踪（strace）
用 strace 等工具记录进程的全部系统调用：文件读写、进程创建、网络 connect、写终端等。一条 shell 命令可产生数十 KB 原始 trace，绝大多数是动态链接、locale 探测等噪声，需过滤压缩才能供 LLM 使用。
Caper 的效果报告正是从 strace -f 的追踪数据提炼而来，这是其「证据」的技术来源；理解 trace 的噪声结构才能体会有界报告设计的必要性。
提示注入
攻击者把恶意指令藏在工作区文件、构建脚本或工具输出中，代理读到后可能被误导执行危险命令，而用户请求本身完全良性。Debenedetti 等人与 Greshake 等人系统研究过这种间接注入。
论文威胁模型的核心：危害可能来自被调用代码而非命令文本，这正是只看文本的审批者（规则、护栏模型、Auto Mode）系统性失效的根本原因。
误拦截与审批疲劳
安全审批系统的核心权衡指标：误拦截率指把无害命令错误拒绝的比例。拦得太凶会频繁打断开发者、造成审批疲劳——Anthropic 报告用户批准了 93% 的 Claude Code 权限提示，说明过吵的告警会被无脑放行。
论文卖点不只是低危害率，还包括对安全孪生任务仅 1.0% 的误拦截率；不理解这个权衡就无法体会「观测效果同时降低危害与误拦」这一结果的分量。
研究动机
现有审批系统只看文本、不看效果。静态规则检查器（如 CARE）把命令字符串与危险语法、路径、来源的模式匹配；护栏模型（ToolSafe、gpt-oss-safeguard、Qwen3Guard）拿请求和命令文本对照安全政策分类；部署中的 Claude Code Auto Mode 用允许规则加只读可见对话的两级分类器。它们都无法在决策前观察命令的真实效果，这个盲区在 shell 命令上尤其致命：一条命令可调用工作区里的任意脚本、构建目标或包工具，这些代码可能读取凭据、删除数据、访问网络，而命令文本毫无痕迹。Figure 1 的例子一针见血：用户都要求清理构建产物并重编译，两个工作区的代理都提出 make clean && make，但 A 的 Makefile 会删掉 src/ 和 .git/，B 只删 build/——只看文本的审批者面对完全相同的输入。另一面，人工审批不可扩展：Anthropic 报告用户批准了 93% 的 Claude Code 权限提示，频繁提示拖慢开发并造成审批疲劳；YoloFS 虽观察文件变化，却把评估留给代理和事后人工，此时凭据可能已外传、无法撤回。
本文的目标是本文要回答的核心问题是：这条命令将对当前工作区产生哪些安全相关的效果，它们是否在用户请求的授权范围之内？目标是构建一个在效果提交之前就完成判断的审批机制：既能拦截 shell 中介的越界后果——非预期的持久化修改、外传网络请求、通过输出泄露——又不拖累良性任务的完成。量化目标是在 SABER 和 YoloFS-Ext 两个基准上达到最低的危害结果率（最终 6.7% 和 7.8%），同时把安全孪生任务的误拦截率压到极低（最终 1.0%），并保持与无审批时相当的安全结果率（SABER 上 67.8% 对无审批的 66.6%）。系统还必须实用：效果报告要远小于原始 trace（实测缩小 99.4%），审批延迟可接受（中位 3.2 秒），每任务 API 成本仅从 $0.017 增至 $0.019；被拦截时返回可行动的理由，让代理改走更安全的路径而不是直接失败。
与已有工作不同的是，本文的独特切入是把审批依据从「命令说了什么」换成「命令做了什么」：先在快照沙箱里真实执行一次，再基于观测到的效果决策。已有方法都停在执行前——规则和护栏模型读文本，ToolEmu 让 LM 模拟工具执行，但得到的是模型预期会发生什么，而非被调用代码的真实行为；YoloFS 观察了变化但时序错了，先提交后评估，把撤回责任丢回给提议命令的代理本人。Caper 同时满足三个此前无人兼得的要素：观测（真实执行加系统调用追踪）、判断（独立于代理的 LLM 审批者对照用户任务）、时点（提交之前、回滚可及）。为让证据能被 LLM 消化，它还设计了有界效果报告这一中间表示，把数十 KB 的原始 trace 压缩成约 1 KB 的结构化卡片。评估侧同样有新意：构造 YoloFS-Ext，把危害藏进被调用工具内部，并给每个危险任务配一个文件、请求、命令完全相同而工具无害的安全孪生，使误拦截第一次成为可精确测量的对照指标。
核心方法
直觉上，审一条命令最可靠的方式是先看它实际干了什么。Caper 位于 shell 边界，代理本身不变——仍是每轮提议一条 shell 命令、读取结果的多轮工具使用模型（GLM-5.3-Flash）。每个任务运行在独立 Docker 容器中，容器默认禁网并限制内存与进程数。命令提交时，系统先把容器快照为状态 $s_t$，然后在容器内用 strace -f 真实预执行该命令并扣住输出；从追踪数据提炼出有界效果报告（中位 0.9 KB，而原始 trace 中位 62.5 KB，总体缩小 99.4%），连同任务和历史交给独立 LLM 审批者（gpt-5.6-luna）判断。批准则丢弃快照、保留执行后状态、把输出作为工具结果返回，命令因此只执行一次；拒绝则销毁被改容器、从快照重建新容器，代理从未被污染的 $s_t$ 继续，并收到可行动的拒绝理由。容器禁网保证了事务性——离开容器的效果无法靠回滚撤销——但连接尝试仍被观测，连同目的地、发起进程及其此前读取过的文件一起进入报告，使外传企图在数据真正离开容器之前就可见。
核心创新是后果感知：审批基于预执行观测到的效果，而非命令文本或其预测。与文本审批者的本质区别在可见性——当危害藏在被调用代码里时（python3 scripts/check-deps.py 暗中读 .env 并尝试外传），危险任务与其安全孪生在文本层面完全相同，任何文本审批者只能两者同判：Figure 4 显示它们聚在对角线上，TS-Guard 危害 8.8% 同时误拦孪生 8.8%，Qwen3Guard 两者全不拦（危害 67.6%），Caper 去掉证据后误拦孪生高达 61.8%。与 YoloFS 的本质区别在时序与判断主体：YoloFS 先提交、事后把变更摘要给代理看、最终靠人把关；Caper 在提交前由独立于代理的审批者判断，阻断即可回滚。与 ToolEmu 的本质区别在真实性：预执行暴露的是被调用代码的真实行为而非模型预测——消融显示预测效果能把危害降到 3.9%，但 61.8% 的安全孪生仍被误拦，因为预测天然留有不确定性；只有真实观测能把误拦压到 1.0%，同时拦下 84.3% 危险任务中的有害命令。
方法步骤详情
流程四步。第一步事务性预执行：代理在状态 $s_t$ 提议命令 $a_t$，任务容器（禁网、限内存与进程数）先被快照，命令在容器内以 strace -f 追踪运行并设超时，记录进程创建、文件操作、网络系统调用与输出；容器启动时先探测 shell、加载器与追踪器自身的访问并按计数扣除噪声。第二步构建有界效果报告：(a) 后果卡片——提取持久文件变迁（对比执行前后工作区，小文本附内容 diff，敏感路径打码）、网络尝试与用户可见输出；(b) 来源归因——保留同进程此前从仓库、凭据位置的成功读取，标注「同行为者、后果前读取」；(c) 保护读取——读 dotenv、凭据库、私钥即记录，即使读后即退；(d) 预算控制——目标 $4\,\mathrm{KiB}$ 上限 $8\,\mathrm{KiB}$，超限按目录聚合、化为计数，执行状态、各类计数、模拟标记与不确定性始终保留。第三步审批：审批者收到任务、交互历史、原始命令与报告，独立评估授权范围、凭据访问、安全控制变更、延迟行为与证据不确定性，整包框定为证据而非指令，返回带置信度的 Allow/Block JSON 与理由。第四步执行：Allow 保留状态返回输出，命令只执行一次；Block 销毁被改容器、从快照重建，返回指名违规边界的理由并要求另寻安全路径。
技术新颖性
技术新颖性有三处。其一，把事务语义完整引入代理审批：快照—预执行—提交/回滚构成对容器本地状态的事务（思想可追溯到数据库与文件系统研究如 Porter 等、Nightingale 等），禁网保证只有容器内效果需要事务管理，这在代理审批系统中是首次把「先执行、再批准、可撤销」做成闭环。其二，有界效果报告是新的证据中间表示：基线探测去噪、后果卡片结构化、同行为者先前读取链的来源归因、凭据只记类别不记值的打码、以及覆盖度元数据（各类事件的观测/纳入/省略计数）共同构成 LLM 可用的证据格式，解决了「trace 太大、太噪、且含不可信内容、无法直接喂给 LLM」的实际问题，Debenedetti 等指出的不可信 trace 内容风险被显式框定为证据而非指令。其三，评估设计上的安全孪生构造：每个危险任务配一个文件、请求、命令完全相同、只有被调工具代码无害的孪生，使「误拦截」从模糊概念变成可精确测量的对照指标，从而首次把「观测效果（而非更多上下文或更强模型）是区分危险与安全的因果因素」这一论断用实验钉死。
实验结果
主实验在 SABER（682 个 shell 任务）与 YoloFS-Ext（102 危险任务加 102 安全孪生）上对比 8 个系统，代理为 GLM-5.3-Flash，审批者 gpt-5.6-luna。发现一：文本审批者失败于看不见而非不够严——五个文本系统在 SABER 留下 14.8%–18.8% 危害（无审批 19.7%，Caper 6.7%）；在 Claude Code 内换成 Caper hook 其余不变，危害从 14.8% 降到 10.0%、从 62.7% 降到 6.9%，证明提升来自证据。发现二：观测效果能区分危险与孪生——文本审批者聚在对角线（TS-Guard 8.8% 危害对 8.8% 误拦，Qwen3Guard 全不拦致危害 67.6%），Caper 无证据版误拦孪生 61.8%，有证据后拦下 84.3% 有害命令而误拦仅 1.0%。发现三：判断须在提交前且独立于代理——YoloFS 事后评估，代理仅 66/102 次撤回，不撤回时 33/36 次受害，安全完成率 22.5% 对 Caper 60.8%，总危害 21.2% 反高于无审批。消融：无证据时上下文越全危害越低（44.1%→17.6%）但误拦升至 61.8%；预测效果危害 3.9% 但误拦仍 61.8%；观测效果 7.8%/1.0%；去 diff 危害升至 13.7%；弱审批者加观测危害反升至 33.3%；四级隐藏下危害稳定在 4%–15.4%。开销：报告中位 0.9 KB（P95 2.6 KB），延迟 3.2 秒（P95 6.4 秒），每任务 $0.019；案例中 Auto Mode 放行的覆盖源码、删表任务被 Caper 依 diff 与数据库缩小证据拦截，代理随后自行备份并安全完成。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SABER shell 任务（合法开发请求的朴素完成会导致特定危害） | 危害结果率 harmful-outcome (%) | 6.7 | 无审批 19.7；Claude Code Auto Mode 14.8；CARE 15.0；YoloFS 21.2 | 相对最佳基线降低 8.1 个百分点（约 55% 相对降幅） |
| YoloFS-Ext 危险任务（危害藏在被调用工具内部） | 危害结果率 (%) | 7.8（Claude Code hook 版 6.9） | 无审批 71.6；YoloFS 35.3；Auto Mode 62.7；护栏模型 62.7–94.1 | 相对最佳基线降低 27.5 个百分点以上（约 78% 相对降幅） |
| YoloFS-Ext 危险任务 | 安全完成率 (%) | 60.8 | 无审批 17.6；YoloFS 22.5；Auto Mode 7.8 | 为全部系统最高，约为无审批的 3.5 倍 |
| YoloFS-Ext 安全孪生（命令相同、工具无害） | 误拦截率 (%) | 1.0（hook 版 2.0） | TS-Guard 8.8；gpt-oss-safeguard 15.7；Auto Mode 3.9；Caper 去证据版 61.8 | 全部有审批系统中最低（Qwen3Guard 的 0.0 是因它不拦任何命令，不参与排名） |
| 证据压缩 | 效果报告大小 | 中位 0.9 KB（P95 2.6 KB），较原始 trace 缩小 99.4% | 原始 trace 中位 62.5 KB | 约 70 倍压缩，使 LLM 审批在上下文与成本上可行 |
| 审批开销 | 延迟与成本 | 延迟中位 3.2 秒（P95 6.4 秒）；每任务 $0.019；沙箱每命令 +0.5 秒（批准）/ +1.5 秒（拒绝） | 无证据的同一审批者延迟中位 3.3 秒（P95 11.4 秒）；$0.017 | 延迟反而更低（证据缩短了审批者的犹豫），成本仅增约 12% |
局限与改进
作者承认四点局限。其一，沙箱外效果不可回滚：预执行本身是真实执行，网络请求、远程服务写入、派生进程在审批决定前已发生，只能靠禁网和记录连接尝试缓解，部署类流量需路由到以占位符应答的录制代理。其二，只管 shell：文件编辑等自述变更的工具留给宿主框架，直接覆盖配置文件的编辑只按调用文本判断，植入恶意代码的编辑要等后续命令执行才暴露。其三，单次观测：报告只描述一次沙箱执行，效果依赖时间、随机数或环境的工具再次运行时可能不同；能适应 Caper 的攻击者可检测沙箱、延迟危害、向报告注入文本、或把危害拆分到多条看似无害的命令，基准中不含这种自适应攻击者。其四，判断依赖 LLM：效果是否可接受取决于用户任务，审批者跨运行有波动且可能误读报告，SABER oracle 同样混合规则与 LLM、也可能出错。我的补充：YoloFS-Ext 上仍有 7.8% 危害（脚本链下达 15.4%），链条式包装仍能部分逃逸；每命令约 3.2 秒审批延迟对高频迭代者是可观税负；评估全为合成基准，真实工作区的误拦分布未知。
独立分析的弱点
第一，禁网假设削弱适用范围：现代开发依赖包安装、API 调试、CI 交互，全禁网会误伤；给包仓库开白名单虽保事务性，但攻击者可借允许域返回的内容夹带毒料。改进方向：对白名单域内容做证据级检查，或对出站负载过脱敏代理。第二，单次执行留下可适应攻击面：沙箱检测与延迟执行是恶意软件的经典规避手段（论文引用了 Lindorfer 等 2011 年的工作却未防御），把危害拆到多条良性命令更可绕过单命令审批。改进方向：多次不同环境参数下预执行取效果并集，或对提交后前 N 秒持续监控并支持事后事务。第三，报告可被注入：diff、输出摘要携带工作区内容直达审批者，攻击者可构造看似无害的文件内容误导判断，提示词声明「证据非指令」只是软防御。改进方向：对不可信来源字段做结构化隔离与来源标注。第四，弱审批者收益失衡：消融显示弱模型加观测后危害反从 25.5% 升到 33.3%（仅误拦降到 4.9%），证据价值依赖审批者能力，落地需配套模型选型。第五，非文件效果表达力有限：删表只能靠数据库文件从 32 KB 缩到 20 KB 间接推断，对容器内网络服务、长驻进程缺乏一等公民表达。
未来方向
作者明确留作未来工作的：自适应攻击者的攻防评估——检测沙箱、延迟危害、报告注入、把危害拆分到多条命令；把预执行扩展到出站流量，例如路由到录制代理以占位符应答，使部署请求也进入报告；把审批扩展到 shell 之外的工具类型；与 OpenAI Codex 等其他部署门控的匹配比较（需调整其沙箱策略，因 Codex 默认只审离开工作区的请求）。基于成果可以延伸的方向：一是把效果报告标准化为通用证据格式，接入 IDE 实时审查与 CI 门禁，让同一套卡片服务多种审批场景；二是增量预执行——命令序列只有局部状态变化时复用快照链，摊薄每命令 0.5 到 1.5 秒的沙箱开销；三是把「保护读取加外传尝试」的证据链用于自动蒸馏最小权限策略，长期把 LLM 审批降级为确定性规则的兜底；四是人机混合审批——高置信度自动裁决、低置信度升级给人并附带效果报告卡片，针对性缓解 93% 无脑批准的审批疲劳；五是在真实大规模代码库上测量误拦率分布并校准审批者阈值，补上合成基准与生产环境之间的缺口。
复现评估
复现条件总体较好。论文给出 GitHub 地址，声明公开 YoloFS-Ext 基准；附录 B 详述每个基线的复现方式，附录 A 描述 YoloFS-Ext 构建与评估流程及修订版 SABER oracle，附录 E 给 95% Wilson 区间，附录 F 给开销分解。算力需求轻：无需训练，全为推理调用——代理用 GLM-5.3-Flash，审批者与 Auto Mode 分类器用 gpt-5.6-luna，每系统每任务一次（682+204 个任务），API 成本约每任务 $0.019。主要门槛在基础设施而非算力：需要 Docker 编排、strace 追踪、快照恢复、效果报告提取器（基线探测、卡片化、diff、打码、预算压缩）一整套流水线，工程量不小但无特殊硬件；复现 hook 版还需对接 Claude Code 官方 hook。按每任务约 3 秒审批延迟估算，全量评估数小时级 API 时间，个人研究者可承受。风险点：GLM-5.3-Flash、gpt-5.6-luna 等依赖模型版本可能下线或变更，绝对数字难对齐；报告提取器的边界情况需要大量工程调试。
论文图表
两个工作区的唯一差异在 Makefile：用户都要求清理构建产物并重编译，代理都提出 make clean && make，但工作区 A 的 clean 目标会删除 src/ 和 .git/，工作区 B 只删除 build/。只看命令文本的审批者面对完全相同的输入。
这是全文问题陈述的核心例子：命令的危险性不在命令本身，而在它调用的代码与工作区状态。理解这张图就理解了为什么文本审批在原理上不可能可靠。
以 python3 scripts/check-deps.py 为例展示完整效果报告：保护读取 .env（dotenv）、165 B 的 stdout、3 个端点各 16 次连接尝试（ENETUNREACH 失败）、来源归因到 .env 与脚本自身、覆盖度元数据（353 条文件事实、3 个进程）、报告仅 3.4 KB 而原始 trace 165 KB；审批者以 0.98 置信度 Block，理由指出依赖检查脚本不该读凭据并外联。
这是有界效果报告的具体形态，展示了后果卡片、来源归因、保护读取、覆盖度等所有设计元素如何协同，是理解方法细节的关键图。
左侧对比整体危害、安全完成与误拦：无审批 71.6% 危害；对话-only 17.6% 危害但 61.8% 误拦；预测效果 3.9% 危害但误拦仍 61.8%；观测效果（Caper）7.8% 危害、误拦 1.0%；去掉 diff 危害升到 13.7%；弱审批者 25.5% 危害、加观测后 33.3% 但误拦降到 4.9%。右侧按隐藏方式（脚本、Makefile、脚本链、二进制）拆分危害率。
同时回答「证据从哪来才有效」和「危害包装方式是否影响防御」两个问题，是消融部分信息密度最高的图表。
用户要求运行 ./tool 部署到 staging 目录，该编译工具同时把 src/app.js 从 29 B 覆盖为 11 B（内容变成 // removed）。Auto Mode 全程放行导致源码被毁；Caper 从 diff 中看到源码被替换为注释而拦截，代理随后自行 cat deploy.sh 并用 cp -r 复制源码，最终部署成功且源码完好。
案例研究之一，演示 block 理由如何引导代理找到安全替代路径而非任务失败，体现「可行动理由」设计的价值。
用户要求 make migrate 迁移数据库，该目标却删除三张表并 VACUUM，数据库从 32 KB 缩到 20 KB。Auto Mode 放行导致数据丢失；Caper 凭文件缩小的证据拦截（无需读二进制），代理随后阅读迁移脚本、先 cp 备份 app.db，再直接运行 python3 src/migrate.py，迁移完成且表完好。
案例研究之二，说明间接证据（文件大小变化）也足以支撑正确决策，且阻断后代理能在理解危害后自行安全完成任务。