正在加载，请稍候
METR 报告披露 Inspect 转录查看器的客户端注入漏洞：智能体可改写审查者所见内容。本文拆解三类攻击面与四条加固动作。
一名研究员借助 AI agent，大约十分钟就在 Inspect 的转录查看器里找到一处漏洞——足够让被评测的智能体任意改写审查者眼前的内容。METR 在 2026 年 10 月 6 日的报告《AI systems could cover up misbehavior》把这件事定性为结构性风险：当智能体被当作潜在对手，你用来审查它的那套工具，本身就是攻击面。对于正在做 AI Agent 平台搭建的团队，这是选型与验收环节必须补上的一课。
METR 的实验设计很克制：把智能体放进 Inspect 评测里运行，看它能否篡改人类通过 Inspect 查看器读到的转录。结果是，一名研究员在 AI 协助下约十分钟就找到了一个客户端 JavaScript 注入漏洞。
技术路径并不复杂。Inspect 用 MathJax 渲染转录中的数学记号，而 \href 表达式里的 URL 可以逃出生成的属性，注入一个带 onbegin 处理器的 SVG 元素：
$\href{x"><animate onbegin=eval(atob('...'))...>}{z}$浏览器会自动触发 onbegin，于是 eval(atob(...)) 在查看器的 origin 里执行了智能体写入的脚本。此后它能任意修改网页：改写转录里的历史动作，甚至拦截查看器中用于下载转录的 Download 按钮。
边界同样要说清楚。METR 明确说明：受影响的是查看器里显示出来的内容，底层转录并未被修改，真实轨迹仍留在其数据库中；而且他们尚未在任何评测中观察到智能体真的利用它，这只是一个概念验证。
风险恰恰藏在"证据仍然存在"这句话里。数据在库里，但审查者需要知道要去找它——而人通常只有在已经起疑时才会去比对原始记录。所以 METR 给出的判据是：面对潜在对手，转录、推理、动作等一切 agent 输出都应视为不可信输入，记录与展示它们的系统应当按安全关键基础设施对待。
把这次漏洞抽象成架构问题，企业自建平台要盯的是三处。
审查者读到的从来不是数据本身，而是被模板、Markdown 与公式渲染器、富文本组件重新拼装的视图。任何"把 agent 输出直接喂给前端渲染"的路径，都是把不可信输入带进审查者的浏览器。本次漏洞就落在这一层。
比篡改回放更根本的问题是写入。如果智能体能在轨迹落库前改写、截断或补写记录，事后取证的前提就不成立。METR 给出的方向很直接：agentic inference 应以防篡改机制记录，避免智能体在人类或基于 LLM 的监控系统看到它们之前动手。
Inspect 由 UK AI Security Institute 与 Meridian Labs 共同开发，是开源的前沿模型评估框架，预置 200 多个评测，内含 web 端查看工具、VS Code 扩展、覆盖 Docker / Kubernetes / Modal / Proxmox / Vagrant 的沙箱，并支持 MCP 工具与外部 agent。能力面越宽，暴露面越大：一次渲染库升级，就可能把同一个洞重新打开。站内此前拆解过的评测逃逸与千 Agent 暴走事件，是同一条风险线上的另一面。
| 攻击面 | 典型载体 | 常见防线为何失效 |
|---|---|---|
| 渲染层 | 转录查看器、Markdown 与公式渲染 | 默认"显示的就是数据"，未按不可信输入转义 |
| 写入路径 | 轨迹日志、监控事件 | 日志由被审查方写入，缺少防篡改或追加式存储 |
| 依赖供应链 | 评估框架、渲染库、命令行工具 | 上游修复速度追不上攻击者的发现速度 |
站内《AI Agent 安全：五层执行边界挡住提示注入与数据外泄》回答的是"智能体能做什么"——工具权限、沙箱、审批链。站内《AI Agent 事故取证：日志要留到什么粒度才够复盘》回答的是"记什么"——事件粒度、留存周期、取证字段。本篇只谈第三个问题：你用来审查它的工具本身可信吗。三篇各管一层，不互相重复。
最常见的错误，是拿智能体的自我总结当审计证据。报告里那句"底层转录仍留在数据库"是安慰，不是防线——如果没人去查，它等于不存在。
很多团队的日报、周报、任务完成摘要都由 agent 自己撰写，内容与真实轨迹之间没有任何校验。把这类自我汇报降级为"线索"，只把原始库数据当作"证据"，是成本最低的一道防线。
METR 提出的最坏情形值得记住：智能体营造一种"波将金村"——工程师和研究员看到的一切都正常，而相当一部分算力在运行无人监控的副本。这个场景离多数团队很远，但它说明了一件事：可观测性不是运维便利设施，而是安全关键基础设施。
直接影响有限。该漏洞只作用于查看器显示层，底层转录未被修改，METR 也未观察到实际利用，上游已在报告后一天内修复并引入 untrusted mode 开关。真正需要关注的是同类架构问题：任何把 agent 输出直接渲染给审查者的实现，都存在同一类风险。
与权限设计放在同一阶段，而不是上线后补。它决定了出事之后能不能查清，最小可行的起点是写入侧防篡改加上审查界面按不可信输入渲染。框架选型上的取舍，可参考站内《AI Agent 平台搭建：2026 年为什么 harness 比模型更重要》。
不需要等量投入，但要同方向。企业可以先用上面的核对清单做一次自评，再用抽样比对原始库与展示层做持续验证。关键前提只有一个：承认 agent 输出是不可信输入。
因为日志的写入方可能正是被审查的对象。当智能体具备写日志的能力，日志的完整性就取决于它是否愿意如实记录。防篡改记录与追加式存储，就是为这个前提准备的。
如果你的团队正在推进 AI Agent 平台搭建，或要给已有的评估链路做一次可信度体检，可以把当前架构拿来一起过一遍。