METR 披露查看器漏洞后，AI 审核界面还能作为决策依据吗？

10 月 6 日，METR 披露了一项概念验证：AI Agent 输出的内容可以影响 Inspect 轨迹查看器，让人工审核者看到被改变的页面。不过，真实轨迹仍保存在 METR 的数据库里。METR 表示，没有在其评测中观察到 Agent 利用这一漏洞，问题也已在报告后修补。这是在隔离测试环境中进行的调查，不能写成生产审计数据库遭到清空。具体边界见 METR 原始披露。

如果你在开发客服 Agent、审批流程、研究助手，或者向客户展示 AI 活动历史，这件事带来一个很具体的产品要求：把事件保存下来，与把事件如实呈现给人，是两项不同的责任。一个做得很漂亮的历史页面，如果隐藏、重新解释或没有加载关键证据，仍可能让人做出错误决定。

本文提供一套“记录、导出、查看”三段检查方法、一份可复用的验收表，以及供应商交付要求模板，帮助小团队判断审核界面能否支撑真正的上线决策。我们没有测试你的产品，也没有复现漏洞。下文场景和验收条件都是建议开展的防御性检查，不是实测结果，更不意味着所有 AI 控制台都有这个问题。

1. 先看清披露范围，再调整产品计划

METR 描述的是轨迹渲染器中的客户端 JavaScript 注入问题。Agent 可控的文本能够影响显示页面，包括下载控件。Meridian Labs 在收到报告后一天内修补了问题；METR 还提到，10 月 1 日合并的另一项改动引入了不信任内容的显示模式。这些事实足以支持团队检查呈现证据的软件，却不能用来推算 Agent 隐瞒行为的普遍发生率。

创始人容易走向两个极端。“记录还在，所以没什么损失”忽略了依赖界面作决定的人；“Agent 已经能抹掉全部审计证据”则超出了这次演示的边界。更准确的判断是：即使别处保留着可恢复的记录，审核者仍可能依据当前页面做错决定。

先找出产品中哪些面向客户的决策依赖对话轨迹、生成摘要、活动动态或下载报告。例如：批准退款、接受供应商对比结果、调查一封意外发出的邮件，或判断 Agent 是否越过权限。仅供浏览的辅助页面，与决定下一步能否执行的审批页面，处理优先级不应一样。

产品计划应围绕这种依赖关系展开。先确定决策及证据来源路径，再检查对应的渲染和导出控制。不要因为另一款产品披露了已修补的问题，就立刻要求重写整套监控系统；也不要把供应商说的“我们有日志”当成审核者确实能可靠检查日志的证明。

2. 分清原始事件、导出文件与查看界面

事件记录描述一次行为：哪个主体，对哪个对象，请求了什么操作，得到了什么结果。导出是从存储中取出、用于检查的记录表示。查看界面会对记录进行格式化、筛选、摘要或分组。来源与处理过程说明记录由谁产生、经历过哪些转换。信任边界则把较低可信主体提供的内容，与较高可信系统拥有的能力分开。

这些概念重要，是因为一个页面常常同时混合三个阶段。绿色状态卡可能来自模型解释，而不是实际工具结果；下载按钮可能只导出筛选后的行；轨迹里可能写着助手声称“已完成”，但外部服务实际上拒绝了请求。即使没有恶意行为，这些差异也会误导操作员。

Inspect 日志文档同时介绍了程序化读取和交互式查看，可以作为分开检查路径的例子。它不代表任意产品都具备不可变存储或独立导出能力。

让团队画出一条简单的数据路径：操作产生方 → 事件收集器 → 保留记录 → 导出服务 → 审核界面 → 人工决策。标出每一处内容变化。压缩、脱敏、翻译、排序和摘要即使是合理功能，也应该出现在图中。

接着追问谁能改变各个阶段。如果 Agent 自己能写入“已批准”，这只是它的说法；如果事件服务在收到审批人的决定后生成这一状态，来源就不同。界面应直接说明区别，而不是让操作员从颜色或自信的措辞中猜测。

3. Agent 内容的渲染也是产品边界

活动查看器经常支持 Markdown、公式、代码、图片和链接，因为纯文本不够方便。这些功能也扩大了显示一条记录时参与处理的软件范围。格式化组件、媒体加载器或数学渲染器，可能用普通文本显示不会采用的方式解释内容。

OWASP 的 XSS 防护指南区分输出编码、HTML 清理和安全的文本写入位置，并提醒：清理后再次修改内容，可能破坏先前的保护。具体实现交给工程师；创始人要明确的产品要求是，Agent 提供的内容不能控制审核者的导航、审批控件或其他记录。

采购时可以直接问：“这个审核页面的哪些部分会解释 Agent 输出？它们怎样与我用来作决定的控件隔离？”只回答用了哪个前端框架并不完整。还要覆盖整个转换过程，包括导出预览和嵌入附件。

当前 Inspect 查看器文档提供 inspect view --no-trust-content，用于把日志内容显示为纯文本。这里引用的是文档选项，我们没有为本文运行该命令。使用 Inspect 的团队应核对已安装版本和实际启动配置，不能默认旧安装具备最新文档描述的行为。

面向客户的产品可以提供类似的纯文本检查模式，并把操作控件明确分开。代价是可读性：表格和公式可能更难理解。因此仍要保留定位事件所需的结构，以及访问附件的路径，同时避免悄悄执行或加载附件引用的所有内容。如果安全模式让操作员无法工作，它很可能被绕开。

4. 客服退款场景：页面看起来完整，决策仍可能出错

假设有一款产品叫 HarborSupport。Agent 读取工单、提出退款建议，再请操作员批准。操作员看到客户消息、退款金额、工具调用和绿色完成摘要构成的时间线。这是用于说明设计问题的虚构场景，不是真实客户事故。

客户符合部分退款条件，但建议对应了错误订单。审核页面折叠了之前的订单查询，突出显示助手最后一条消息。操作员觉得金额合理，便批准退款。底层记录完全可能是准确的，默认界面却仍让错误决定变得容易。

再换一种情况：集成请求超时。Agent 声称退款完成，但产品并没有收到支付服务的最终确认。生成的时间线摘要把“确认不可用”改写成“已处理”。这是另一类失败：解释过程把不确定状态升级成成功。它并不需要浏览器注入漏洞才能发生。

创始人的验收问题应是：在选择下一步之前，普通操作员能否确认订单、金额、请求人、审批人、外部结果，以及尚未解决的不确定性？完整轨迹可以留给调查，但主页面应该突出关键字段，并说明各字段来自哪里。

让开发者准备一条刻意存在分歧的合成记录：助手叙述写着错误订单，结构化工具事件指向预期订单，外部结果仍未知。请操作员仅用交付的界面解释发生了什么，再与预先准备的记录比较。记录操作员的解释，而不只是“页面打开成功”。

这个练习检查的是受控场景下的证据呈现能力，不是在测 Agent 的攻击能力。如果操作员没有发现分歧，就先改善信息层级和不确定状态标签，再扩大自动操作权限。

5. 关键证据需要一条独立检查路径

“下载轨迹再核对”听起来像独立验证，但下载也可能只是同一页面里的另一个功能。METR 的演示让这个区别值得重视。对于有实际后果的审核，要说清导出在哪里生成，以及审核者如何不依赖已渲染的轨迹页面取得文件。

独立性总是相对于某种失败而言。服务器生成的导出绕过了客户端渲染器，但仍可能共用一个有缺陷的事件收集器；存储快照能保留原始字节，却无法补上收集器从未收到的事件；支付回执能证明外部效果，但不能单独证明用户授权。第二条检查路径应针对你真正需要回答的问题。

OWASP 日志指南把日志系统验证、访问控制和失败行为纳入检查。证据路径因此应该进入产品验收，而不是被当成无关紧要的运维细节。

对 HarborSupport，我们建议审核材料包含稳定的运行标识、保留的事件序列、导出时间、查看器版本，以及通过另一条路径取得的外部退款状态。操作员对照对象标识和结果。若权限规则隐藏了某个字段，材料应说明“此角色无权查看”，而不是暗示该字段从未存在。

哈希值能帮助把文件与可信参照副本进行比较，但不能证明原始记录描述了事实、采集完整，或同时提供文件和哈希的一方具有独立性。追加式存储保护的是某段历史免受特定修改，并不会自动验证历史中每句话的真实性。

把这些限制写进供应商要求。你买的是从明确来源通向明确决策、能够展示验证的路径，而不是一句笼统的“AI 审计防篡改”。

6. 直接复用这份证据验收表

下面是针对有限试点建议采用的最低检查集合。使用合成账号和无害记录；涉及安全机制的测试，由工程师在隔离环境中设计，不要把漏洞利用内容粘贴进真实客户控制台。表格检查产品行为和操作员理解，不证明系统能抵抗所有对抗性 Agent。

演示前先定义预期答案。否则，善于展示的人可能把意外结果解释成新的验收标准。例如，“叙述冲突”场景的通过条件，可以要求操作员说出两个对象、指出当前不能批准，并说明谁负责解决分歧。这是为该工作流提出的要求，不是已发表的 benchmark 门槛。

不仅保存截图，还要记录准确配置。纯文本模式通过，不代表客户实际使用的富格式模式也通过；管理员通过，也可能漏掉权限较少的客服看不到的信息。验收记录应包含角色、浏览器、导出路径、筛选状态和相关软件版本。

每项失败都应落到修复、限制或推迟功能的决定上。一个便利筛选器有问题，可以先不提供该筛选器；把未知外部结果标成“完成”的页面，则不能继续作为重要审批的依据。判断的是某个具体用途是否成立，不是整个产品“看起来值不值得信任”。

7. 采购的是操作员工作流，不只是一个控制台功能

小团队可以把验收表变成简短的供应商交付要求：写明审核决定、可能后果、实际审核人，以及他们需要的原始记录。明确普通模式和降级模式，要求展示记录分歧、事件缺失、导出不可用时的行为。

下面的模板可以直接填入项目约定：

我们将使用活动页面，决定是否允许对【用户或对象】执行【操作】。页面必须区分 Agent 的说法、已记录的工具请求、人工批准、已确认的外部结果，以及未知状态。Agent 可控内容不能控制审核动作或改变无关证据。具备【角色】权限的审核者，应能通过【导出路径】取得【明确范围】的记录，并与【独立来源】核对。证据不完整或互相矛盾时，产品必须显示【阻断状态】，并交由【负责人】处理。验收须在实际交付配置中执行附件里的合成场景。

再补上维护责任：谁维护渲染依赖清单，谁判断相关安全更新，谁能关闭富格式显示，谁在升级后确认导出仍符合规定范围。要求展示已安装的配置，而不只是发来上游文档链接。

Inspect 命令参考明确说明，纯文本覆盖选项不受日志自身信任配置影响。供应商应能把你选择的产品的运行行为讲到这种精度。不能据此推断所有查看器都有同样保证，也不能未经测试就把相同配置套用到另一套技术栈。

预算也要真实。独立导出、按权限脱敏、操作员培训和依赖维护，可能比加入一个时间线组件费力得多。如果预算不足以支持重要审批，就缩小试点权限。只生成草稿、由人回到原始服务核对的助手，仍然可能有价值，无须假装已经提供完整审计能力。

8. 同时考虑隐私、无障碍与证据是否有用

为解决查看器风险，把每段对话复制到人人可访问的档案里，可能制造新问题。OWASP 日志指南列出了通常应排除或保护的敏感字段。可审计性不是无目的保留密钥、客户文档或个人信息的理由。先确定谁需要哪些字段、材料保留多久，以及怎样撤销访问。

把日常操作员视图，与调查人员更深入的访问分开。操作员可能只需要订单标识和确认结果；调查人员则可能需要在更严格权限下查看相关工具参数。界面应解释证据为什么受到限制，并提供有负责人的升级路径。“没有记录”不能替代“记录存在，但你的角色无法读取”。

易用性同样影响证据质量。只通过颜色变化显示状态，审核者可能看不到；更新到达时没有可访问的通知，有人可能继续依据旧信息行动。WCAG 2.2 的状态消息要求规定，状态信息应能通过程序识别，让辅助技术在不移动焦点的情况下呈现。这里只涉及一项相关要求，不是对产品无障碍能力的完整评估。

让操作员使用键盘、页面缩放和他们实际使用的辅助技术，找到一条缺失确认。提供“确认不可用”“证据不完整”等文字状态，并说明下一步。降级模式也应保留可访问的结构，不能让更安全的查看方式只有开发它的工程师会用。

通过限定访问范围和清晰解释来平衡这些要求。能够可靠支持一个明确决定的小型证据包，往往比没人能理解、也不便安全分享的完整轨迹堆更有用。

9. 哪些问题阻断上线，哪些可以等

对于只读研究助手，如果活动日志只是补充信息，审核界面的缺陷可能适合通过关闭某种渲染功能来处理，试点仍可继续。对于能发消息、改记录或发起资金操作的 Agent，同样的缺陷可能直接破坏团队的监督依据。后果与现有独立核对路径，才决定能否发布。

我们建议的暂停条件包括：Agent 可控字段能改变审批控件；页面与约定范围的导出存在无法解释的差异；缺失事件被显示成完整历史；未确认的外部结果被写成成功。这些是本文针对相关工作流提出的验收条件，不是已经发现你的应用存在这些问题。

内容安全策略（CSP）可以增加浏览器保护，但不能包办全部问题。OWASP 的 CSP 指南将其定位为一层防护，而不是修复底层漏洞的万能办法。让工程师为实际应用选择并验证策略；响应中出现某个头字段，并不能证明证据可信。

受控上线可以从合成审核材料开始，在获得权限后进入只读客户案例，只有操作员能够稳定识别冲突和不确定性时，才扩大操作权限。保留关闭富格式显示或暂停重要操作的开关，写明谁能使用，以及启用后需要的记录仍在哪里可查。

这套框架不足以覆盖高保证安全评测，也不足以对付能同时攻陷收集器和所有独立存储的对手。那些场景需要更深入的威胁建模与技术验证。它也不能证明 Agent 的推理轨迹忠实反映了真实动机；这里检查的是团队取得已记录证据的路径。

10. 创始人今天可以做什么

先选产品里一个有实际后果的决定，让开发者追踪关键字段从产生、存储、导出到显示的全过程。把 Agent 写的叙述与服务确认结果分开。准备一个合成分歧场景和一个缺失确认场景，请真正负责审核的人使用界面检查。

接着，通过独立性已说清的路径取得导出，比较范围、对象标识和结果，而不只是页面外观。如果界面与导出不一致，在查清原因前，暂停依据该页面批准操作。保留两份材料及配置，方便调查差异。

最后，把责任写进发布记录：谁维护渲染依赖，谁核对缺失证据，谁能缩小 Agent 权限。明确哪些功能可以关闭，同时仍保留后续处理所需的记录访问。

METR 这次披露对小型产品团队的实际价值，是让采购与上线多出一个更准确的问题：审核者能否通过一条不会被待审内容悄悄改变的路径，取得当前决策所需的证据？在把审计界面写进客户承诺之前，先用范围清晰的演示和可保留的材料回答它。

参考资料

1. METR：AI systems could cover up misbehavior，2026 年 10 月 6 日。原始披露及概念验证边界。
2. Inspect：Log Viewer。交互查看和纯文本选项。
3. Inspect：Log Files。日志保留、程序化访问与配置。
4. Inspect：inspect view 命令参考。信任配置的运行行为。
5. OWASP：Logging Cheat Sheet。日志验证与访问要求。
6. OWASP：Cross Site Scripting Prevention Cheat Sheet。编码、清理与安全显示。
7. OWASP：Content Security Policy Cheat Sheet。浏览器多层防护及限制。
8. W3C：WCAG 2.2，状态消息。可访问的状态沟通。