玻璃翼项目：Mythos向我们展示了什么

过去几个月，我们一直在自有基础设施上测试一系列专注于安全领域的大语言模型。这些大语言模型帮助我们识别自身系统中的潜在漏洞，以便我们进行修复——同时，它们也向我们展示了攻击者能够利用最新模型做到哪些事情。

在这些大语言模型中，没有哪一款比 Anthropic 的 Mythos Preview 更受关注。几周前，我们受邀在 Project Glasswing 项目中使用 Mythos Preview。我们很快将其指向了五十多个自有代码仓库——看看它能发现什么，也看看它是如何工作的。

本文分享了我们的观察结果、模型表现优异之处与不足之处，以及围绕它们的架构和流程需要如何改变，才能使其得以大规模应用。

Mythos Preview 带来了哪些变化

Mythos Preview 确实是一次真正的进步，在讨论其他内容之前，有必要先明确这一点。我们已经在代码上运行模型有一段时间了，而从以往通用前沿模型所能做到的水平，到如今 Mythos Preview 所实现的能力，这种跃升不仅仅是此前成果的简单优化。

这是一种不同类型的工具，执行着不同类型的工作，这使得与早期模型进行纯粹的同类对比变得困难。因此，与其试图将 Mythos Preview 与通用前沿模型进行基准测试，不如描述它实际能做什么，以及我们在使用 Mythos Preview 过程中发现的两个突出特性：

• 利用链构建——真正的攻击很少只利用一个漏洞。它通常将多个小型攻击原语串联成一个可用的利用程序。例如，它可能将一个释放后使用漏洞转化为任意读写原语，劫持控制流，并利用返回导向编程（ROP）链来完全控制系统。Mythos Preview 能够获取多个这样的原语，并推理如何将它们组合成一个可用的验证程序。它在此过程中展现的推理能力，看起来更像是一位资深研究员的工作，而非自动化扫描器的输出。

• 漏洞证明——发现一个漏洞与证明其可利用性是两回事，而 Mythos Preview 两者都能做到。它会编写能够触发疑似漏洞的代码，在沙盒环境中编译该代码并运行。如果程序按照模型预期的方式运行，这就是证明。如果未能如愿，模型会读取失败信息，调整其假设，然后再次尝试。这个循环过程与它发现的漏洞本身同样重要，因为一个没有有效证明的可疑缺陷只是猜测，而 Mythos Preview 能够自行弥合这一差距。

我们上面描述的某些功能并非 Mythos Preview 所独有。当我们让其他前沿模型通过相同的测试框架时，它们也发现了相当数量的相同底层漏洞，在某些情况下，它们在推理方面取得的进展甚至超出了我们的预期。它们的不足之处在于将各个环节串联起来。一个模型可能会识别出一个有趣的漏洞，写出关于其重要性的详尽描述，然后就停止了，留下未完成的实际攻击链和悬而未决的可利用性问题。Mythos Preview 带来的改变在于，模型现在能够将这些低严重性漏洞（传统上会默默无闻地积压在待办列表中）串联起来，形成一个单一的、更严重的可利用漏洞。

模型在合法漏洞研究中的拒绝行为

由 Anthropic 提供、作为 Project Glasswing 一部分的 Mythos Preview 模型，不具备通用可用模型（如 Opus 4.7 或 GPT-5.5）中存在的额外安全防护措施。

尽管如此，该模型会自发地对某些请求进行抵制——就像它用于漏洞搜寻的网络能力一样，该模型拥有自身涌现出的护栏，有时会导致它拒绝合法的安全研究请求。但正如我们所发现的，这些自发的拒绝行为并不一致——同样的任务，以不同的方式表述或在不同的上下文中提出，可能会产生完全不同的结果，如下面的示例所示。

Mythos Preview 拒绝构建有效概念验证的示例

例如，该模型最初拒绝对一个项目进行漏洞研究，但在对项目环境进行一项无关更改后，它又同意对同一代码执行相同的研究。被分析的代码本身没有任何变化。在另一个案例中，该模型发现并确认了代码库中的几个严重内存错误，随后却拒绝编写演示性利用代码。同样的请求，换一种方式提出，会得到不同的答案；甚至相同的请求，由于模型的概率特性，在不同运行中也可能产生不同结果。语义等价的任务，根据向模型呈现的方式和时机，可能产生截然相反的结果。

这一点很重要，因为虽然模型自带的拒绝/护栏机制是真实存在的，但它们的一致性不足以单独构成完整的安全边界。这正是为什么任何未来普遍可用的、具备能力的网络前沿模型，都必须在此基础行为之上增加额外的安全措施——使其适合在像 Project Glasswing 这样的受控研究环境之外更广泛地使用。

信噪比问题

对安全漏洞进行分类时，最困难的部分之一是判断哪些漏洞是真实的、哪些是可利用的、以及哪些需要立即修复。即使在人工智能出现之前，这也是一个难题。AI 漏洞扫描器和 AI 生成的代码使这个问题更加严重，在 Cloudflare，我们构建了多个后验证阶段来处理它。

影响噪声率的两个主要因素：

• 编程语言——C 和 C++ 提供了直接的内存控制，同时也带来了相应的漏洞类型——缓冲区溢出、越界读写——而这些是 Rust 等内存安全语言在编译时就能消除的。我们发现，使用内存不安全语言编写的项目，其误报率始终更高。

• 模型偏见——一位优秀的人类研究员会告诉你他们发现了什么以及有多大把握。模型不会。让模型去找漏洞，无论代码里有没有漏洞，它都会找出一些来。返回的结果中充斥着“可能”、“潜在”、“理论上可以”这类措辞，而这些含糊其辞的发现数量远超确凿的发现。对于探索性工具来说，这是一种合理的偏见。但对于分类队列来说，这却是毁灭性的，因为每一个推测性的发现都需要消耗人力和模型 token 去排除，而随着数千个发现的累积，这种成本会急剧增加。

Mythos Preview 在这方面有了明显改进，尤其是在组合基本能力方面——它能将多个漏洞整合成一个可行的概念验证，而不是孤立地报告它们。一个附带概念验证的发现，就是你可以据此采取行动的发现，这意味着你无需花大量时间去问“这到底是不是真的？”

我们的测试框架特意调校为倾向于过度报告，这样我们能看到更多（漏得更少），但随之而来的是大量噪音。然而，在分类阶段，Mythos Preview 的输出质量明显更高：含糊其辞的发现更少，复现步骤更清晰，做出“修复或排除”决策所需的工作也更少。

为什么把通用编码智能体指向一个代码仓库行不通

去年我们刚开始进行 AI 辅助漏洞研究时，直觉上想到的最直接方法就是：把一个通用编码智能体指向任意代码仓库，让它去发现漏洞。这种方法在“模型会产出发现”这个意义上是有效的，但在对一个真实代码库进行有意义的覆盖、并识别出有价值的发现方面，它并不奏效。这主要有两个原因：

• 上下文——编码智能体针对单一聚焦的工作流进行调优：构建一个功能、修复一个漏洞、编写一次重构。它们会摄入大量源代码，一次只持有一个假设，并针对该假设进行迭代。而这恰恰是漏洞研究的错误形态，因为漏洞研究本质上具有狭窄且并行的特点。人类研究员会选择一件具体的事情进行深入调查。这一件事可能是一个单一复杂功能、跨越安全边界的转换，或者是一个特定的漏洞类别，比如命令注入——攻击者的输入最终被当作 shell 命令执行。然后，他们会针对不同的功能、安全边界或漏洞类别，在代码库中重复这个过程数千次。一个单一的智能体会话（即使有子智能体）针对一个十万行代码的仓库，在模型的上下文窗口填满并开始压缩之前，可能只能以有用的方式覆盖大约千分之一的攻击面——这可能会丢弃之前那些本应重要的发现。

• 吞吐量——单流智能体一次只做一件事，但真实的代码库需要同时针对多个组件提出多个假设，并且在发现有趣内容时能够进一步扩展。你可以让单个智能体更努力地工作，但到了某个节点，限制你的将不再是模型，而是交互形态本身。当研究员已经有了线索，想要多一双眼睛时，直接在编码智能体中使用模型进行手动调查是可行的。然而，对于实现高覆盖率来说，这是错误的工具。一旦我们接受了这一点，我们就不再试图让 Mythos Preview 去做错误的工作，而是开始围绕它构建一个支撑框架。

支撑框架实际上解决了什么问题

大规模运行这项工作得出了四个教训，每一个都指向了需要一个管理整体执行的支撑框架：

• 限定范围能产生更好的发现——告诉模型“找出这个仓库中的漏洞”会让它漫无目的地搜索。而告诉它“在这个特定函数中查找命令注入，上方有这条信任边界，这里是架构文档，这里是该区域之前的覆盖情况”，则能让它做出更接近研究人员实际会做的事情。

• 对抗性审查能减少噪声——在初步发现和队列之间加入第二个智能体——使用不同的提示词、不同的模型，且没有能力生成自己的发现——可以捕获第一个智能体在仅检查自身工作时可能会遗漏的大量噪声。事实证明，让两个智能体刻意处于分歧状态，比仅仅告诉一个智能体要小心有效得多。

• 将推理链拆分到多个智能体上能产生更好的推理——询问“这段代码有缺陷吗？”和“攻击者能否从系统外部实际触及这个缺陷？”是两个不同的问题，当你分别提出这两个问题时，模型在每个问题上的表现都更好，因为每个问题都比合并后的版本范围更窄。

• 并行的窄范围任务胜过单个穷举式智能体——当多个智能体在严格限定范围的问题上并行工作，然后我们对结果进行去重，而不是要求一个智能体穷举所有情况时，覆盖范围会得到改善。

上述每一条观察都关乎模型行为，综合起来，它们描述的已不再是聊天界面。而是一个能帮助你达成最终成果的“驾驭框架”。构建驾驭框架的第一步很简单，你可以请模型帮忙，我们就是这么做的。我们利用 Mythos Preview 来构建、定制和改进我们原有的驾驭框架，以发挥其优势。下面描述了一个驾驭框架在实际应用中的示例。

我们的漏洞发现驾驭框架

以下是我们的漏洞发现驾驭框架的逐阶段展示。它被用于扫描我们运行时、边缘数据路径、协议栈、控制平面以及我们所依赖的开源项目中的实时代码。

这对安全团队意味着什么

其他安全领导者对 Mythos Preview 最强烈的反应集中在速度上——扫描更快、修补更快、压缩响应周期。我们接触过的多个团队现在都按照从 CVE 发布到生产环境修补两小时 SLA 的标准运作。这种直觉可以理解：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但更快是不够的，我们认为很多团队即将花费大量时间、精力和金钱，以惨痛的方式学到这一点。

加快修补速度并不能改变产生修补程序的流水线形态。如果回归测试需要一天时间，不跳过它就不可能达到两小时 SLA，而跳过回归测试发布出去的漏洞，往往比原本试图修补的漏洞更严重。我们曾尝试让模型自己编写修补程序，结果发现有几个补丁虽然修复了原始漏洞，却悄悄破坏了代码依赖的其他功能——我们就是从这件事中吸取了教训。

更棘手的问题在于，围绕漏洞的架构应该是什么样子。其原则是：即使存在漏洞，也要让攻击者更难利用它，从而缩小漏洞披露与修补之间的时间窗口。这意味着要在应用程序前端部署防御措施，阻止漏洞被触及；意味着要设计应用程序，使代码某一部分的缺陷无法让攻击者访问其他部分；还意味着能够同时向代码运行的所有位置推送修复，而不是等待各个团队单独部署。

我们也认识到，这个话题是一把双刃剑。那些帮助我们发现自己代码中漏洞的能力，如果落入不当之手，将加速对互联网上所有应用程序的攻击。Cloudflare 位于数百万个此类应用程序的前端，上述架构原则正是我们产品为客户所构建的核心能力。未来几周，我们将进一步分享这对客户意味着什么。

如果你的团队也在从事类似工作并希望交流经验，请通过 security-ai-research@cloudflare.com 联系我们。

我们使用 Mythos Preview 进行的研究是在受控环境中针对我们自己的代码开展的；此项工作发现的每一个漏洞都经过了分类、验证，并在需要采取行动时按照 Cloudflare 的正式漏洞管理流程进行了修复。

这项工作凝聚了团队的力量。感谢 Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl 和 Rohit Chenna Reddy 为本篇博文背后的研究、工程和分析所做出的贡献。