在过去的几个月里，我们一直在自己的基础设施上测试一系列专注于安全的LLM。这些LLM帮助我们识别自身系统中的潜在漏洞，以便我们进行修复——同时它们也向我们展示了攻击者能够利用最新模型做什么。
在这些LLM中，没有哪个比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 漏洞扫描器和 AI 生成的代码使情况变得更糟，在 Cloudflare，我们构建了多个后验证阶段来处理它。
两个因素主导了噪声率：
编程语言 - C 和 C++ 提供直接的内存控制，随之而来的是错误类别——缓冲区溢出、越界读写——而 Rust 等内存安全语言在编译时消除了这些错误。我们始终看到，用内存不安全语言编写的项目产生更多误报。
模型偏差 - 优秀的人类研究人员会告诉你他们发现了什么以及他们的信心程度。模型不会。让模型查找错误，它会找到错误，无论代码是否有错误。发现结果会带有“可能”、“潜在”、“理论上可以”等限定词，而带有限定词的发现数量远远超过可靠的发现。对于探索性工具来说，这是一个合理的偏差。但对于分类队列来说，这是一个毁灭性的偏差，其中每个推测性的发现都需要花费人力和令牌来排除，而且这种成本在数千个发现中不断累积。
Mythos Preview 在这方面代表了明显的改进，特别是在其链接原语的能力上——将多个漏洞组合成一个有效的概念验证，而不是孤立地报告它们。带有 PoC 的发现是一个可以采取行动的发现，这意味着花在问“这到底是不是真的？”上的时间大大减少。
我们的检测工具被刻意调校为倾向于过度报告，因此我们看到更多（漏报更少），但这也带来了更多噪音。然而，在分类阶段，Mythos Preview 的输出质量明显更高：模棱两可的发现更少，复现步骤更清晰，做出修复或驳回决定所需的工作量也更少。
为什么将通用编码代理指向仓库行不通
去年我们刚开始进行 AI 辅助的漏洞研究时，直觉做法显而易见：将一个通用编码代理指向任意仓库，让它发现漏洞。这种方法在模型会产生发现的意义上是有效的，但在对真实代码库进行有意义的覆盖并识别有价值的发现方面却行不通。主要原因有两个：
上下文 - 编码代理针对单一专注的工作流进行调优：构建功能、修复错误、编写重构。它们会摄入大量源代码，一次持有一个假设，并针对该假设进行迭代。这恰恰与漏洞研究的特点相悖，后者本质上是狭窄且并行的。人类研究人员会选择一件具体的事情进行深入研究。这件事可能是一个复杂的功能、跨越安全边界的转换，或者特定的漏洞类别（如命令注入，攻击者输入最终作为 shell 命令执行）。然后他们会针对不同的功能、安全边界或漏洞类别重复这一过程，在代码库中执行数千次。一个单一的代理会话（即使有子代理）针对一个十万行代码的仓库，在模型的上下文窗口填满并开始压缩之前，可能只能以有用的方式覆盖大约千分之一的攻击面——可能会丢弃早期本应重要的发现。
吞吐量 - 单流代理一次只做一件事，但真实的代码库需要同时针对多个组件提出多个假设，并在发现有趣内容时能够进一步扩展。你可以更努力地驱动单个代理，但到某个点，限制因素不再是模型，而是交互本身的形式。在研究人员已有线索并希望获得第二意见时，直接在编码代理中使用模型对于手动调查来说是不错的。然而，对于实现高覆盖率来说，它是错误的工具。一旦我们接受了这一点，我们就不再试图让 Mythos Preview 做错误的工作，而是开始围绕它构建检测工具。
检测工具实际解决了什么
大规模运行这项工作得出了四个教训，每个都指向需要一个管理整体执行的检测工具：
狭窄的范围产生更好的发现 - 告诉模型“在这个仓库中查找漏洞”会让它漫无目的。告诉它“在这个特定函数中查找命令注入，上方有信任边界，这是架构文档，这是该区域先前的覆盖范围”会让它做出更接近研究人员实际会做的事情。
对抗性审查减少噪音 - 在初始发现和队列之间添加第二个代理——使用不同的提示、不同的模型，且没有生成自己发现的能力——可以捕获第一个代理如果仅检查自己工作可能会遗漏的大量噪音。事实证明，让两个代理故意持不同意见比仅仅告诉一个代理要小心有效得多。
将任务链拆分到多个智能体上能产生更好的推理—— 问“这段代码有 bug 吗？”和“攻击者能否从系统外部实际触发这个 bug？”是两个不同的问题，分开提问时模型在每个问题上表现更好，因为每个问题都比合并版本更窄。
并行的窄任务胜过单一的穷举智能体—— 当多个智能体处理范围严格限定的问题，然后我们对结果去重，而不是让一个智能体穷举时，覆盖率会提高。
这些观察都关乎模型行为，合在一起描述了一种不再是聊天界面的东西。它是一个帮助你达成最终结果的框架。构建框架的第一步很简单，你可以让模型帮忙，我们就是这么做的。我们使用 Mythos Preview 来构建、定制和改进我们的原始框架，以发挥其优势。
下面是一个框架在实际应用中的例子。
我们的漏洞发现框架
以下是我们的漏洞发现框架，分阶段展示。它被用于扫描我们运行时、边缘数据路径、协议栈、控制平面以及所依赖的开源项目中的实时代码。
阶段
功能
重要性
侦察
一个智能体从上到下读取仓库，分派给负责每个子系统的子智能体，并生成一份架构文档，涵盖构建命令、信任边界、入口点和可能的攻击面。它还为下一阶段生成初始任务队列。
为所有下游智能体提供共享上下文。减少漫无目的的问题。
狩猎
每个任务是一个攻击类别搭配一个范围提示。狩猎者（实际寻找 bug 的智能体）并发运行，通常一次约五十个，每个再分派给几个探索子智能体。每个狩猎者可以访问工具，在每任务临时目录中编译和运行概念验证代码。
这是大部分工作发生的地方。许多窄任务并行执行，而不是一个穷举智能体。
验证
一个独立的智能体重新阅读代码，并试图反驳原始发现。它使用不同的提示，且自身不能发出新发现。
捕获了狩猎者在审查自己工作时可能遗漏的相当一部分噪音。
补漏
狩猎者标记他们触及但未彻底覆盖的区域。这些区域被重新排队进行另一轮检查。
抵消模型倾向于漂移到已成功攻击类别的趋势。
去重
共享相同根本原因的发现合并为一条记录。
变体分析是一个特性，而不是用重复项膨胀队列的方式。
追踪
对于共享库中的每个已确认发现，追踪代理会进行扇出（每个消费者仓库一个实例），使用跨仓库符号索引，并判断攻击者控制的输入是否真的从系统外部到达了该缺陷。
将“存在缺陷”转变为“存在可被利用的漏洞”。这是最关键的一个阶段。
反馈
可被利用的追踪路径会成为消费者仓库中新的狩猎任务，这些仓库中该缺陷实际暴露。
形成闭环。管道在运行中不断改进。
报告
代理根据预定义的模式编写结构化报告，自行修复针对该模式的任何验证错误，并将报告提交到摄取 API。
输出的是可查询的数据，而非自由格式的文本。
这对安全团队意味着什么
其他安全领导者对 Mythos Preview 最强烈的反应集中在速度上——扫描更快、修补更快、压缩响应周期。我们交谈过的多个团队现在正按照从 CVE 发布到生产环境修补的两小时 SLA 运作。这种本能可以理解：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但更快是不够的，我们认为很多团队即将花费大量时间、精力和金钱，以艰难的方式学到这一点。
修补更快并不会改变产生修补的管道的形态。如果回归测试需要一天，不跳过它就无法达到两小时的 SLA，而跳过回归测试所交付的漏洞往往比试图修补的漏洞更糟糕。当我们尝试让模型自己编写修补程序时，我们曾经历过类似情况：一些修补程序修复了原始漏洞，却悄悄破坏了代码依赖的其他功能。
更难的问题是围绕漏洞的架构应该是什么样子。原则是即使存在缺陷，也要让攻击者更难利用，从而降低漏洞披露到修补之间的时间窗口的重要性。这意味着在应用程序前端部署防御措施，阻止缺陷被触及。这意味着设计应用程序时，代码某一部分的缺陷不能让攻击者访问其他部分。这意味着能够同时将修复部署到代码运行的所有地方，而不是等待各个团队单独部署。
我们也认识到这个话题是一把双刃剑。帮助我们找到自己代码中缺陷的相同能力，如果落入坏人之手，将加速对互联网上每个应用程序的攻击。Cloudflare 位于数百万个应用程序的前端，上述架构原则正是我们的产品代表客户所应用的。我们将在未来几周分享更多关于这对客户意味着什么的信息。
如果您的团队也在进行类似工作并希望交流经验，请通过 [email protected] 联系我们。
我们使用 Mythos Preview 进行的研究是在受控环境中针对我们自己的代码进行的；通过这项工作发现的每个漏洞都经过了分类、验证，并在 Cloudflare 的正式漏洞管理流程下采取了必要的补救措施。
这项工作是一项团队努力。感谢 Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl 和 Rohit Chenna Reddy 对这篇博文背后的研究、工程和分析所做的贡献。