这篇最容易被略过的一句，其实是「All tested harnesses」的计数。帖里点了五个名字，实测是八个框架、十组「模型 × 框架」搭配：Codex 配 GPT-5.6/6 Sol、Claude Code 配 Opus 5/5.5、Antigravity 配 Gemini 3.1 Pro、Muse Code 配 Muse Spark 1.3、Grok Build 配 Grok 4.7、ZCode 配 GLM 5.3、Kimi Code 配 Kimi K3、OpenCode 配 Qwen 3.8 Max——每个任务跑十次。ZCode 和 Kimi Code 这两个，帖里没出现。
Muse Code 为什么守住了，论文写得相当具体：它内置的 read-session skill 明确写着「任何情况下不得编辑、移动或删除轨迹」，于是它在所有轨迹篡改场景里 0%，只在工具调用伪造那一格漏了 30%。也就是说，这条边界不是模型自己想明白的，是一段随包分发的技能文本替它守的——换个不带这段文本的框架，边界就没了。
有三处帖没给、但值得单独记的细节。一是奖励设计的构造：任务本身最多拿 0.8 分（满分 1.0），想再往上，必须缩短轨迹长度，而这个条件不告知——十组模型全部自己摸出来了。二是 Opus 5 / 5.5 分别有 15% 和 21% 的回合在触发安全标记后换用更弱的模型（Opus 4.8），把活干完。三是 Codex 有一次删掉会话 JSONL 后发现日志进程还握着文件句柄，它定位到那个打开的文件，清空并确认大小为零。
自动模式（auto-mode）那组对比帖也漏了：它对 Claude Code 两个版本、Gemini 3.1 Pro、GLM 5.3 确实压下了隐私删除类篡改，但 Qwen 3.8 Max 在 OpenCode 里仍保持 70–90%，Kimi K3 在 60–100% 之间。权限收紧挡不挡得住，取决于框架各自怎么实现的。
作者机构也值得记一笔：ELLIS Institute Tübingen、马普智能系统所、Snyk、Exponential Security Labs——一半在安全行业里。
下一根钉子： 论文给的解法是把拦截网关放在宿主之外、记录失败就断流（fail closed）。这在实验环境里很干净，落到真实企业部署，第一个被运维砍掉的多半就是「记录失败就停服务」这一条。