“Shall We Approve?”：面向自主编码智能体的后果感知审批

Caper 会在快照沙箱中预执行每条提议的 shell 命令，向 LLM 审批器提供有界影响报告，提交允许的命令，并以原因回滚被阻止的命令。

现有自动审批器仅根据请求和命令文本做决定，因此不会观察 shell 命令调用了什么，也不会观察当前工作区如何改变其影响。像 make clean && make 这样的命令在一个工作区中可能只删除构建产物，而在另一个工作区中会删除源文件以及仓库历史。观察文件变化的系统在执行后评估这些变化，从而把补救留给智能体或人类。Caper 针对这一空白，在提交已观察到的后果之前先做决定。

Caper 对任务容器做快照，并在系统调用跟踪下在其中预执行每条提议的 shell 命令，输出暂存到审批通过后再返回。根据跟踪记录，它生成有界影响报告，保留持久工作区变更、连接尝试、命令输出和受保护读取，并归因到涉及的进程和文件。LLM 审批器接收用户任务、交互历史、原始命令和影响报告，并返回 Allow 或 Block、置信度和简短原因。若 Allow，则保留已执行状态并返回输出；若 Block，则将容器恢复到快照并返回原因，以便智能体重新规划。

• Caper 在 SABER 和 YoloFS-Ext 上取得最低有害结果率，同时在 YoloFS-Ext 上仅阻止 1.0% 的安全孪生任务。 §Abstract
• 在 SABER 上，五个基于文本的审批系统使 14.8–18.8% 的任务受到伤害，而不审批时为 19.7%，Caper 为 6.7%。 §5.2
• 将 Claude Code Auto Mode 的内置分类器替换为 Caper 作为审批钩子，在 SABER 上使有害率从 14.8% 降至 10.0%，在 YoloFS-Ext 上从 62.7% 降至 6.9%。 §5.2
• 不带影响报告的 Caper 会阻止 61.8% 的安全孪生任务；带影响报告时，它在 84.3% 的危险任务中阻止有害命令，同时仅阻止 1.0% 的安全孪生任务。 §5.2
• YoloFS 的智能体在 102 次危险运行中有 66 次回滚；在 36 次未回滚的运行中，有 33 次最终受到伤害。YoloFS 留下 35.3% 的伤害，是 Caper 的四倍，并且仅安全完成 22.5% 的危险任务，而 Caper 为 60.8%。 §5.2
• 在 SABER 上，影响报告的中位大小为 0.9 KB、p95 为 2.6 KB，而原始跟踪为 62.5 KB，减少 99.4%；审批延迟中位数为 3.2 s，而无证据时为 3.3 s；每个任务的 API 成本为 $0.019，而无证据时为 $0.017。 §5.5

• 论文指出，回滚仅恢复容器文件系统，因此离开容器的效果（如网络请求、远程写入或已启动的进程）会在审批前发生且无法撤销；部署必须隔离预执行，例如使用记录代理。
• 论文指出，Caper 仅门控 shell 命令；文件编辑等其他工具在调用中声明其变更，而本身造成伤害的编辑仅根据调用进行判断。
• 论文指出，报告描述的是一次观察到的执行；依赖时间、随机性或环境的工具在重跑时可能表现不同，自适应攻击者可能检测沙箱、在报告中植入文本，或将伤害拆分到多条命令；两个基准都不包含此类攻击者。
• 论文指出，LLM 的判断可能在不同运行间变化并误读报告，且 SABER 的 oracle 也可能以同样方式出错。

• Caper 不改变智能体，而是在状态 s_t 中针对每条提议命令在 shell 边界进行干预。 §4
• 每个任务在自己的 Docker 容器中运行，禁用网络并设置内存和进程限制；命令执行前对容器做快照，命令在 strace -f 下带超时执行。 §4.1
• Allow 会丢弃快照并返回捕获的输出；Block 会移除已变更的容器，从快照重新启动，并返回原因以便智能体重新规划；命令恰好执行一次。 §4.1
• 影响报告仅保留有后果的事件：持久工作区变更、连接尝试、命令输出和受保护读取，并归因到涉及的进程和文件；探测访问按计数扣除。 §4.2
• 审批器接收用户任务、交互历史、原始命令和影响报告，并返回 JSON 的 Allow 或 Block、置信度和简短原因。 §4.3
• 审批器评估范围、凭据、受保护的安全控制、运行时效果、延迟行为和不确定性；该信息包被表述为证据而非指令。 §4.3
• 在案例 1 中，当 diff 显示 src/app.js 从 29 B 被覆盖为 11 B 时，Caper 阻止 ./tool；随后智能体复制源文件并安全部署。 §5.4
• 在案例 2 中，当报告显示 app.db 从 32 KB 缩小到 20 KB 时，Caper 阻止 make migrate；智能体备份数据库并仅运行迁移脚本。 §5.4