控制评估考察的是：AI 研发机构的智能体，是否可能在未被其安全与监督措施制止的情况下，造成严重危害。目前，研发机构在很大程度上依靠监测器来发现可能有害的 AI 行为。本文讨论评估方可如何收集有关监测可靠性的证据。我们目前考虑以下五个核心子问题：¹

1. 监测覆盖范围：内部智能体推理中，有多少比例已纳入监测，又有多少比例应当纳入监测？
2. 监测系统漏洞：内部 AI 智能体能否通过破坏或攻陷监测系统的基础设施等方式，使其运行轨迹不受监测？
3. 规避监测：在监测正常运行的情况下，AI 智能体有多容易使其不当行为逃过监测器的检测？
4. 响应，包括规避人工审查：对于需要人工审查的已标记事件，是否能及时开展审查？即使不当行为已被基于大语言模型的监测器标记，这些行为是否仍容易逃过人工审查者的识别？
5. 影响：总体来看，智能体在不被发现的情况下，可能实施的最严重的不当行为是什么？它们有多容易规避其他可观测性工具和安全工具？能在内部或外部实现何种程度的持久驻留？

随着新能力和未对齐行为的出现，我们将更新这些子问题。

为什么重点评估监测器？

本提案主要关注利用大语言模型监测 AI 智能体。当 AI 智能体只需执行一组范围有限且已知的操作时，常规网络安全方法可能就足够了，例如借助沙箱机制，把智能体的权限限制在完成任务所需的范围内。然而，AI 智能体所需的权限往往十分广泛。例如，需要访问互联网才能完成任务的 AI 智能体可以执行极其多样的操作，²而判断这些操作何时会造成危害，往往需要结合更广泛的上下文来理解该操作。因此，利用能够理解智能体行为的大语言模型对其进行监测，是大规模自动化监督的关键组成部分，也是前沿 AI 研发机构内部关于 AI 不当行为的主要证据来源。

方法与子问题

监测覆盖范围

监测只有实际覆盖相关流量，才能发挥作用。评估方的目标是推算：研发机构基于大语言模型的监测覆盖了多大比例的内部智能体推理。这一比例可以按各类智能体的风险高低来划分：在高度安全的沙箱环境中运行的智能体，风险低于具备多种可操作条件（例如可访问互联网，或可获取内部凭据、访问基础设施）的智能体，所需的监测监督可能也较少。

要对监测覆盖范围作出合理推算，需要统计经由受监测路径和未受监测路径的内部流量，推算未受监测的推理中有多大比例属于智能体推理，并判断其中有多大比例“应当”受到监测。为此，需要查阅推理日志和监测日志（将后者与推理日志交叉核对），并访谈员工，以便有把握地确认已涵盖所有相关的推理来源。³

其他相关子问题还包括：

• 研发机构内部是否具备准确推算监测覆盖范围所需的信息？是否对所有智能体推理逐次记录日志，并保留这些日志？
• 符合监测条件的操作是否 100% 实际受到监测？是否有运行轨迹在未发出任何提示的情况下被丢弃？
• 究竟向监测器提供了哪些内容？是否有任何信息被排除在外？例如，是否向监测器提供了多模态数据？
• 研发机构如何推算监测所覆盖的推理量？评估方如何才能有把握地确认，已将该机构内部智能体推理的所有来源纳入统计？
• 对安全最为关键的领域，是否部署了阻断式监测器（即在检测到不当行为时阻止相关操作的监测器）？

如果未对齐的智能体攻陷了公司的内部基础设施，它们就可能利用未受监测的推理，执行原本会被标记的操作。因此，评估方应直接评估未受监测的推理是否确实并非由智能体产生，而不应仅因为（例如）它本应只有有限的工具使用能力，就假定它是安全的。

监测系统漏洞

即使目前大多数智能体推理都受到基于大语言模型的监测器监测，系统中仍可能存在智能体可以利用的程序缺陷或漏洞，使其能够关闭针对自身运行轨迹的监测、创建不受监测的新智能体、阻止监测系统查看其部分运行轨迹，或以其他非预期方式导致监测系统损坏或失效。监测系统十分复杂，涉及多种推理引擎或 API、智能体运行框架、内部身份验证机制、触发系统等，各子系统交互的环节很容易出现漏洞。针对监测系统开展红队测试，旨在发现这些程序缺陷和漏洞，为判断未对齐的智能体有多容易破坏监测系统基础设施的正常运作提供证据。

问题举例如下：

• 智能体能否直接禁用或关闭对其进行监测的系统？它们能否生成某些输出，使监测系统发生故障，同时不使其运行轨迹被标记？
• 智能体能否在监测系统评估运行轨迹之前，修改发送给该系统的轨迹内容（例如，掩盖不当行为的证据）？
• 是否存在易于实施、能够攻陷监测系统的供应链攻击，包括通过内部资源实施的攻击？

要发现这些缺陷，或有把握地判断不存在易于利用的严重缺陷，需要能够访问关键路径上的全部代码。主要包括完整的模型推理与监测触发系统、内部 API 和推理服务代码，以及智能体运行框架（如涉及）。

为测试已发现的漏洞利用方法，评估方可以触发生产环境中的监测系统，并查看监测器处理已知攻击时的完整输入和输出。实际运行系统并查看完整输入和输出十分重要，因为程序缺陷或问题往往涉及运行轨迹预处理或后处理中的细节，或涉及与复杂的轨迹管理代码之间的交互（例如处理上下文压缩、记忆等功能的代码）。

规避监测

假设监测基础设施没有遭到破坏或控制，监测器实际发现不当行为的能力如何？评估方可以通过以下方式开展压力测试，以检验这一点：

• 在真实的轨迹记录中寻找“攻击机会”，据此实施攻击，并检验这些攻击能否骗过监测器；
• 取用监测器已标记的既有事件，检验修改这些事件以骗过相应监测器有多难；以及
• 寻找已经发生但未被监测器标记的事件。

直接针对监测器开展红队测试时，需要有大量具有代表性的轨迹记录（数量级为数十万至数百万条）。首先，如果评估方在大量未被监测器标记的轨迹记录中未能发现严重事件，这就为监测器并未漏报大量事件提供了证据。其次，需要检索大量轨迹记录，寻找智能体可能有机会在不被发现的情况下实施攻击、却未采取行动的情形。智能体可能放过某些攻击机会，同时利用另一些机会；能力很强的智能体还可能优先选择极难被发现的攻击，以至于研发机构几乎总会漏检。

最后，我们预计，评估监测器与智能体能在多大程度上成功串通而不被研发机构察觉，将变得越来越重要。如果监测系统在某些情况下决定不标记智能体的未对齐行为，就可能使智能体在研发机构未察觉的情况下采取有害行动。我们建议评估方研究这种担忧所指的情形是否可能发生。例如，评估方可以为监测器设置逼真的“蜜罐”，检验能否发现监测器不标记某些攻击的情况。评估方还可以检索监测系统的思维链，查看其中是否提及或讨论了串通或相关概念。

响应，包括规避人工审查

一些监测系统被设计为直接阻断危险操作。

另一些监测系统则被设计为通知工作人员，由其判断 AI 智能体是否正在进行危险活动。要使这种机制有效运作，需要人工查看已标记的运行轨迹，并采取适当的缓解措施。对于此类系统，评估方应当回答以下问题：

• 通知工作人员并响应已标记运行轨迹的流程是什么？触发此类标记的阈值是什么，这一阈值在实践中效果如何？
• 人工审查已标记的运行轨迹并作出响应需要多长时间？
• 评估方能否让被监测器标记的攻击蒙混过人工审查者，例如让这些攻击呈现出与常见误报相似的特征？
• 有哪些用于缓解事件的流程？这些流程能否可靠地处理最严重的事件？

为评估攻击最终能否被发现（无论是由监测系统直接阻断，还是提交人工审查），评估方需要访谈相关人员，并以贴近真实情况的方式，将自己构造的攻击轨迹插入⁴监测处理流程。评估方还需要查阅已被标记的事件、员工通过其他渠道报告的事件，以及研发机构内部关于升级处理的判定标准。

影响

评估方了解监测器的覆盖范围及其局限后，需要判断：智能体可能实施哪些行为而不被发现？它们能够在研发机构内部或外部实现何种程度的持久驻留？应如何设计未来的监测系统，才能最大限度地提高研发机构发现最严重事件的可能性？这需要梳理攻击链并构建威胁模型，以便提前应对新出现的风险。

这项探索性更强的工作，主要需要掌握研发机构内部基础设施的相关信息。如果还能使用开发机器、推理系统、容器或虚拟机等内部基础设施，将有助于验证漏洞，并直接探索未来可能出现的威胁路径。

访问权限详情

总体而言，对控制措施开展压力测试，需要具备以下访问权限：

• 与研发机构内部从事前沿 AI 安全研究的人员相近的代码库访问权限⁵
• 查阅研发机构内部大多数或全部推理使用场景的推理日志，以及监测系统日志的权限
• 查阅事件报告及相关轨迹记录和日志的权限
• 访问集群或内部基础设施的权限，例如运行监测系统
• 调用研发机构内部能力最强的模型进行推理的权限

下文分别说明：对于我们目前认为控制评估应优先回答的各个子问题，需要具备哪些访问权限。

监测覆盖范围

• 为推算受监测流量的比例，需要查阅研发机构内部推理服务和监测系统的日志。⁶
• 为推算未受监测的推理中有多大比例属于智能体推理，需要查阅未受监测的推理日志或运行轨迹的大规模样本，且这些样本应大致具有代表性。⁷
• 为完成上述两项估算并验证大语言模型分类器，需要从研发机构内部所有相关的推理使用场景中抽取部分运行轨迹供查阅。
• 为核查监测器是否发现了以往发生的事件，需要查阅员工通过其他渠道报告的未对齐事件的相关清单。
• 为核实监测是否全面，需要查阅监测系统的日志，并与推理日志交叉核对。
• 为分析已发现的监测覆盖缺口并确定其规模，需要根据具体情况，查阅能够反映该缺口的其他相关日志。

监测系统漏洞

• 对代码库中相关部分的完整访问权限。
• 运行或触发生产环境中监测系统的权限，以及查看监测器完整输入和输出的权限。

规避监测

• 至少约 10 万条大致具有代表性的内部智能体轨迹记录（例如，经员工或团队选择加入后纳入的机构内部使用记录，另加数量级相近、具有代表性的评测和训练记录）。⁸
• 至少约 100 条涉及研发机构内部最严重事件的轨迹记录，其中也包括员工通过其他渠道报告的事件。

规避人工审查及响应

• 访谈相关人员、查阅文档，并直接了解研发机构内部近期已标记运行轨迹的升级处理与审查流程。
• 能够将评估方自行构造的攻击轨迹插入监测处理流程，以便在贴近真实情况的条件下，判断人工审查能否发现其中的攻击，并将这些轨迹妥善升级处理。

影响

• 能够访问管理研发机构内部基础设施与计算资源、凭据、沙箱、网络配置、开发机器等的代码或系统，访问范围应与该机构的前沿 AI 安全人员相近。在一定程度上，可以通过访谈相关人员来替代此类访问，但这会对评估构成不可忽视的限制。
• 对实际运行集群的有限访问权限，以便直接测试是否存在漏洞，而非仅凭推断，尤其是在重要配置参数既未保存在代码库中、也无法通过其他途径获取的情况下。