跳到正文
UK AI Security Institute Blog·· 2 小时前精选AI 评分66

英国 AISI 控制红队如何压力测试前沿监控器

How our Control Red Team is stress-testing frontier monitors

AI 导读

英国 AI 安全研究院(AISI)新设 Control Red Team,用对抗方式压力测试前沿 AI 开发者部署的监控器,即审查智能体行为并标记危险动作的独立 LLM。

推荐理由

英国 AISI 公开对前沿监控器的红队测试结果,读者可了解控制类安全措施的实际薄弱点与评估难点。

正文 · AI 翻译

随着 LLM 智能体变得更加自主,它们造成危害的机会也更多。为降低风险,前沿 AI 开发者,如 OpenAI 和 Anthropic,已经在监控器的监视下部署智能体:一个单独的 LLM,负责审查智能体的行为,并在其危险时发出标记。不断发展的 AI 控制研究领域旨在设计这类安全措施,并评估它们是否具有稳健性——即便智能体试图逃避检测。

两年多来,AISI 的红队一直在评估滥用防护措施:即防止人类故意诱导模型做出有害行为的保护机制。我们攻破这些防护措施,以便开发者发现并修补其缺陷。现在我们成立了一个新的子团队——控制红队——将同样的对抗性方法引入控制防护措施,这些措施针对的是智能体自行采取的有害行为。由于这些安全措施往往是抵御自主智能体有害行为的最后一道防线,对它们进行压力测试尤为重要:我们通过在失准智能体之前发现漏洞来强化它们。

这篇博客简要介绍了我们的监控器红队演练、我们自动化搜索攻击的尝试,以及我们为强化评估而需要回答的研究问题。

我们对前沿控制监控器的评估

通常,前沿 AI 开发者使用的安全措施以监控器为核心。安全性取决于 监控器何时标记某个行为,以及被标记的行为会如何处理——但未被监控器捕获的行为无法被阻止。

对控制监控器进行红队测试,就是问:‘如果一个 AI 攻击者完成了有害目标而非用户请求,监控器会标记这次攻击吗?’例如,如果用户要求智能体修复其代码库中的一个 bug,但智能体却下载并执行了某些恶意软件,监控器会标记这次攻击吗?

我们已经测试并正在帮助改进两家前沿 AI 开发者的内部控制监控器:

  • 与 Google DeepMind 合作,我们测试了一个异步推理监控器(在智能体行动后审查其推理),旨在检测智能体欺骗性地追求失准目标。我们发现了若干监控器漏洞,其中之一是智能体可以通过假装幻觉以为那是用户指令,从而完成恶意目标。
  • 与 Anthropic 合作,我们测试了一个同步内部智能体编码监控器的多个连续版本(在执行每个行为前进行审查)。我们在测试的每个监控器版本中都发现了漏洞,推动了一个迭代改进循环,其中我们最好的攻击最终为 Anthropic 对 Claude Mythos Preview 的测试提供了参考。

我们的一些攻击通过找到监控器提示词中的缺口而成功。另一些则利用了 LLM 本身的弱点,完成了提示词明确禁止的目标。在某些情况下,硬编码规则决定哪些行为会被发送给监控器审查,因此最佳攻击策略是完全避免行为被发送到监控器。

我们早期的红队演练暴露出了一些对我们和整个领域来说都是全新的开放研究问题:我们的滥用红队(Misuse Red Team)在专注于人类滥用时从未遇到过这些问题,而 AI 控制研究人员大多研究的是程式化的红蓝对抗博弈,而非针对特定监控器的红队测试。我们将在最后一节回到这些问题。

自动化红队测试

智能体可能很快会在许多任务上超越人类专家——包括生成能够绕过控制监控器的攻击。如果智能体能够超越我们的红队,那么一个能阻止我们红队的监控器仍可能被一个失准的智能体击败。1

我们的滥用红队已经使用自动化来寻找越狱方法。控制红队正在应用类似的方法来寻找不会被监控器标记的攻击记录。我们尝试了不同的算法,但最成功的却是其中最简单的一种:一种分为四个阶段的进化搜索算法:

  1. 初始化:我们从一组初始的攻击记录种群开始——这些记录来自在其系统提示中被指示进行攻击的智能体。
  1. 评估:我们评估每条记录——运行目标监控器以产生一个可疑度分数,并验证该记录是否完成了恶意目标。
  1. 筛选:我们筛选种群——将最不可疑的记录保留在一个固定大小的候选攻击缓冲区中。
  1. 提议:由 LLM 基于缓冲区中的记录提出新的攻击记录。提议者可以使用来自监控器的反馈,例如可疑度分数或监控器的推理过程。

例如,我们早期的一项实验使用我们的算法在一个具有挑战性的单步编码场景中对监控器进行红队测试,在该场景中,智能体生成的代码会隐蔽地泄露其私有 API 密钥。我们使用 Claude 4.6 Sonnet 同时作为提议者和监控器。

图 1:进化搜索与 Best-of-N(BoN)的监控器可疑度分数对比。

我们进行了三次各 15 万次查询的运行,将进化搜索(蓝色)与 Best-of-N(BoN)基线(灰色)进行比较,后者从 N 个独立样本中取分数最佳的样本。在全部三次运行中,进化搜索最终都达到了 100 分中最低 3 分的可疑度分数——远低于 BoN 的 14、15 和 18 分。在其中一次运行中,进化算法在不到 5 千步内就达到了 3 分。

这些早期实验还有很大的改进空间。未来,我们希望将监控器分数中的随机噪声纳入考量,并开发出能够发现成功“策略”而非单条记录的算法。尽管如此,我们的自动化红队测试工具已经在前沿监控器中暴露出了一些有趣的失效模式。 

控制红队的下一步计划

控制监控器目前正在部署中,随着 LLM 智能体能力越来越强、运行时的监督越来越少,风险将会上升。我们的目标是确保 AISI 具备持续对监控器进行有意义压力测试的专业能力,并开发出对其进行整体评估的方法。为此,我们需要回答几个开放的研究问题:

  • 我们如何模拟一个逼真的 AI 攻击者?控制红队测试中最具挑战性的方面之一,是决定一个模拟的失准智能体应该具备哪些能力,然后判断我们发现的攻击是否合理。我们的自动化红队测试凸显了这个问题:我们的算法会以已部署智能体不可能采用的方式,针对监控反馈进行迭代。我们赋予模拟攻击者的能力应如何与真实智能体的能力保持一致——我们又该如何找到既强大又逼真的攻击?
  • 我们如何估计整体安全性?发现监控弱点是一回事;根据这些发现估计某项安全措施的整体有效性则是另一回事。我们如何利用红队测试结果来估计某个给定智能体规避某项安全措施的实际可能性?AISI 一直在研究如何估计整体安全性,但仍有许多未解决的问题。
  • 我们如何开发更强的算法?为了扩展到高度逼真的环境,并与更强的监控器保持同步,我们需要继续改进我们基础的进化搜索算法(例如通过引入更高层次的策略生成)。
  • 我们如何考虑监控器本身的失准?在实践中,开发者常常使用一个可能失准的 LLM 实例来监督另一个自身的实例。AI 控制研究者区分“可信”与“不可信”监控器,但迄今为止我们还没有办法建立信任。我们如何排除或抵消监控器自身的失准?

我们与 Google DeepMind 和 Anthropic 的早期合作表明,对安全措施进行红队测试既可行又有用:监控器确实存在真实弱点,及早发现这些弱点有助于开发者加强其安全措施。还有很多工作要做——我们既期待改进我们的攻击搜索算法,也期待推进理解这些攻击何时具有逼真性的概念性工作。

我们正在招聘杰出人才,帮助我们红队测试前沿 AI 开发者的监控器。如果你正是这样的人,请在此表达意向。

‍

来源:UK AI Security Institute Blog · aisi.gov.uk