近几个月来，我们一直在自有基础设施上测试一系列专注于安全的大语言模型。这些大语言模型帮助我们识别系统中的潜在漏洞，以便及时修复 —— 同时也向我们展示了攻击者能够借助最新模型进行的操作。
在所有这些大型语言模型中，来自 Anthropic 的 Mythos Preview 比任何其他模型都更引人注目。几周前，作为 Project Glasswing 的一部分，我们受邀使用了 Mythos Preview。我们很快就将其指向了我们自己的五十多个代码库，以观察它能发现什么，并了解其工作原理。
本文介绍了我们的观察结果、模型的优势与不足之处，以及在规模化场景中应用需要进行的架构和流程改进。
Mythos Preview 是一项真正的进步，在深入讨论其他问题之前，有必要明确指出这一点。我们已经在自有代码库上使用模型进行测试已有一段时间，从之前通用型前沿模型的能力水平到 Mythos Preview 今天的表现，这不仅仅对之前工作的改进，而是质的飞跃。
这是一种全新的工具，执行全新的工作，因而难以与早期模型进行直接对比。因此，与其试图将 Mythos Preview 与通用前沿模型进行性能对标，不如描述它实际能做什么更有意义。我们在使用 Mythos Preview 进行的工作中发现了两项突出的特性：
漏洞利用链构造—— 现实中的攻击很难仅靠一个漏洞完成，而是将多个微小的攻击原语串联成一个可实际运行的漏洞利用工具。例如，它可能将一个use-after-free（释放后重用）漏洞转化为任意读写原语，劫持控制流，并使用返回导向编程 (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 漏洞扫描器和 AI 生成代码使问题更加复杂，为此 Cloudflare 建立了多层后置验证机制来加以处理。
两个关键因素主导了噪声率：
编程语言——C 和 C++ 提供直接内存控制，随之带来了缓冲区溢出、越界读写等缺陷类别，Rust 等内存安全语言则能在编译时消除这些问题。我们观察到，使用内存不安全语言编写的项目产生的误报率始终更高。
模型偏差 ——优秀的人类研究者会阐明其研究发现及其置信度。模型不会这样做。让一个模型寻找缺陷，它就会发现缺陷，无论代码是否真正存在这些漏洞。发现结果充斥着“或许”、“潜在”、“理论上可能”等模糊表述，此类模棱两可的结果数量远超确凿可靠的结论。对于一个探索性工具来说，这样的偏向是合理的。但这对于漏洞分级处置队列而言弊端极大，每一条推测性漏洞结论都需要耗费人力与算力资源进行剔除，数千条此类结论叠加将导致成本累计攀升。
Mythos Preview 在这里表现出明显的改进，特别是在其连接原语的能力方面——将多个漏洞组合成一个可行的概念验证，而不是单独报告。附带 PoC 的漏洞发现结果可让您直接着手处置，还能大幅减少您耗费精力去核实漏洞真伪的时间。
我们的驾驭框架被刻意调整为过度报告，这样我们能看到更多（并漏掉更少），但这也带来更多噪音。然而在漏洞分类环节，Mythos Preview 的输出质量明显更高：减少了推测性发现、提供了更明确的复现步骤，大幅降低了安全人员做出修复或排除决策的工作量。
当我们去年首次开始 AI 辅助的漏洞研究时，我们的直觉是显而易见的做法：把一个通用编码智能体指向一个任意的代码库，然后要求它发现漏洞。这种方法从表面上看是可行的——模型确实会产生发现结果，但它无法对实际代码库进行有效的覆盖分析，也无法识别真正有价值的发现。主要原因有两个：
上下文 —— 编码智能体针对单一的专注工作流进行了优化调整：功能实现、缺陷修复和代码重构。它们摄入大量源代码，每次持有单一假设，并对其进行迭代。这对漏洞研究而言是完全错误的方式——漏洞研究的本质是狭窄且并行的工作流。人类研究员选择一个特定目标并对其进行深入调查。那个特定目标可能是一个复杂功能、跨越安全边界的转移，或特定漏洞类型（如命令注入），其中的攻击者输入最终被作为 shell 命令执行。随后，研究员在代码库中反复进行同样的工作——针对不同的功能、安全边界或漏洞类型，重复这个过程数千次。单个智能体会话（即使包含子智能体），面对一个十万行的代码库，在模型的上下文窗口填满并进行压缩之前，有效覆盖比例可能还不到千分之一，从而丢弃早期的潜在重要发现。
吞吐量 —— 单流智能体一次处理一项任务，而真实代码库需要同时针对多个组件提出多个假设，并在发现有价值的目标时能进一步扩展探索。您可以让单个智能体更加高效，但到了某一阶段，限制不再来自模型本身，而是来自交互形式本身的限制。对于已有具体线索并寻求辅助视角的人工调查场景，直接使用模型的编码智能体确实是可行的。然而，这不是实现高覆盖率的合适工具。认识到这一点后，我们不再试图让 Mythos Preview 执行不适合的任务，而是转向围绕它构建驾驭框架。
大规模运行这项任务产生了四个关键经验教训，每一个都指向同样的需求：构建一个驾驭框架来统筹整体执行：
范围越窄，结果越好—— 要求模型“在此代码库中寻找漏洞”会导致它漫无目的地游荡。直接告诉它：”查找此特定函数中的命令注入，采用这一信任边界，这是架构文档和这一区域的现有覆盖情况“，可引导模型以更接近人类研究员实际工作的方式运行。
对抗性审查能降低噪声——在初始发现和队列之间插入第二个智能体，该智能体采用不同的提示词、不同的模型，且不能自主生成发现。这种设计能捕获第一个智能体检查自身工作时会遗漏的大量噪声。事实证明，让两个智能体故意产生分歧，比仅仅告诉一个智能体要小心更加有效。
将推理链拆分到多个智能体可产生更优质的推理——”这段代码有 bug 吗？“和”攻击者能从系统外部到达这个 bug 吗？“是两个不同的问题。当分别提问时，模型在每个问题上的表现都更好，因为每个问题的范围比组合版本更窄。
多个并行的狭窄任务优于单个穷举式智能体——当多个智能体分别处理范围明确的问题，随后对结果进行去重时，覆盖率提升效果显著。这优于让单个智能体力图穷尽所有情况。
这些观察结果都涉及模型行为，综合起来，它们描述的已经不再是一个聊天界面。这是一种帮助您实现最终结果的工具。构建控制框架的初期步骤很简单——您可以请模型协助完成，这正是我们所做的。我们使用 Mythos Preview 来构建、定制和改进最初的驾驭框架，使其更好地发挥 Mythos Preview 的优势。
下面介绍一个驾驭框架在实际应用中的示例。
以下将分阶段呈现我们的漏洞发现驾驭框架。该框架用于扫描我们实时运行的代码——从运行时环境、边缘数据路径、协议栈、控制平面，到依赖的开源项目。
|
阶段
|
作用
|
为何重要
|
侦察
|
智能体从代码库从上到下扫描代码库，扩展至负责各个子系统的子智能体，生成一份架构文档，涵盖构建命令、信任边界、入口点及可能的攻击面。同时为下一个阶段生成初始任务队列。
|
为每个下游智能体提供共享上下文。消除了”游荡“问题。
|
狩猎
|
每个任务对应一种攻击类型，具有范围提示。猎手（负责实际寻找漏洞的智能体）并发执行，通常约 50 个同时运行，每个猎手向若干个探索子智能体分配任务。每个猎手都可以访问一个工具集，用于在每个任务的专用临时目录中编译并运行概念验证代码。
|
这就是大部分工作进行之处。多个狭窄范围的任务并发运行，而非一个穷尽性的智能体。
|
验证
|
一个独立智能体重新读取代码，并尝试推翻原始发现。它使用不同的提示词，且不能独立生成新的发现。
|
捕获到猎手审查自身工作时会遗漏的一部分重要噪音。
|
补漏
|
猎手标注其接触但未深入探测的区域。这些区域会被重新加入队列，进行另一轮探索。
|
抵消模型向其已取得成功的攻击类别漂移的倾向。
|
去重
|
具有相同根因的发现合并为单条记录。
|
变体分析是一个特性，而非通过重复发现来扩大队列规模的方式。
|
追踪
|
对于共享库中的每个确认发现，追踪智能体会逐一展开（每个消费者库一个实例），使用跨库符号索引，并判断攻击者控制的输入是否确实从系统外部到达漏洞。
|
将”存在缺陷“转化为“存在可达漏洞“。这是最重要的阶段。
|
反馈
|
可达追踪结果转化为新的狩猎任务，在漏洞实际暴露的消费仓库中执行。
|
完成闭环。这个流程的性能将随着运行而不断提高。
|
报告
|
智能体基于预定义的架构编写结构化报告，针对该架构自动修复任何验证错误，然后将报告提交至摄入 API。
|
输出是可查询数据，而非自由格式文本。
|
来自其他安全负责人对 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 对本文背后的研究、工程和分析所做出的贡献。