Glasswing 项目：Mythos 的安全漏洞挖掘实战与启示
Cloudflare 在 Project Glasswing 中深度试用 Anthropic 的 Mythos Preview 模型，对其 50 多个自有仓库进行了安全扫描。该模型的核心进步在于能自动将多个低危漏洞串联成完整利用链，并生成可执行的 PoC，使漏洞验证从猜测变为可操作。实际使用暴露出模型拒绝不一致、信噪比等问题，单一通用 coding agent 效果不佳。Cloudflare 构建了包含侦察、狩猎、验证、补缺、去重、追踪、反馈和报告的八阶段编排框架，用并行窄域任务和对抗性复核大幅提升质量。文章最后指出，仅加快修补不够，需从架构上限制漏洞可达性，并预告后续面向客户的实践分享。
2026-05-18
9 min read
For the last few months, we've been testing a range of security-focused LLMs on our own infrastructure. These LLMs help identify potential vulnerabilities in our own systems, so we can fix them – and they also show us what attackers are going to be able to do with the latest models.
None of these LLMs has captured more attention than Mythos Preview, from Anthropic. A few weeks ago, we were invited to use Mythos Preview as part of Project Glasswing. We soon pointed it at more than fifty of our own repositories – to see what it would find, and to see how it works.
This post shares what we observed, what the models did well and what they didn't, and how the architecture and process around them needs to change, so they can be used at scale.
2026-05-18
阅读时间约9分钟
过去几个月，我们在自己的基础设施上测试了一系列专注于安全的LLM。这些LLM帮助我们识别自身系统的潜在漏洞，以便修复；同时，它们也向我们展示了攻击者利用最新模型能做什么。
在所有LLM中，Anthropic的Mythos Preview最受关注。几周前，我们受邀在Project Glasswing中使用Mythos Preview。我们迅速将其指向了超过五十个自己的代码仓库，看看它能发现什么，以及它是如何工作的。
本文将分享我们的观察：模型做得好和不好的方面，以及围绕它们的架构和流程需要如何改变，才能实现规模化应用。
What changed with Mythos Preview
Mythos Preview is a real step forward, and it's worth saying that plainly before getting into anything else. We've been running models against our code for a while now, and the jump from what was possible with previous general-purpose frontier models to what Mythos Preview does today is not just a refinement of what came before.
It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:
Exploit chain construction - A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.
Proof generation - Finding a bug and proving it's exploitable are two different things, and Mythos Preview can do both. It writes code that would trigger the suspected bug, compiles that code in a scratch environment, and runs it. If the program does what the model expected, that's the proof. If it doesn't, the model reads the failure, adjusts its hypothesis, and tries again. The loop matters as much as the bugs it finds, because a suspected flaw without a working proof is speculation, and Mythos Preview closes that gap on its own.
Mythos Preview带来的变化
Mythos Preview是真正的进步，这一点在讨论其他内容之前值得明确说出来。我们已经运行模型分析代码有一段时间了，从之前通用前沿模型能做到的事到Mythos Preview如今的表现，不仅仅是改进，而是质的飞跃。
这是一种不同类型的工具，完成着不同类型的工作，这使得与早期模型进行纯粹的同类对比变得困难。因此，与其尝试将Mythos Preview与通用前沿模型进行基准测试，不如描述它实际能做什么，以及我们在使用Mythos Preview的工作中两个突出的特性：
攻击链构建——真正的攻击很少只用一个漏洞。它会将多个小的攻击原语链在一起，形成一个可工作的利用。例如，它可能将use-after-free漏洞转化为任意读写原语，劫持控制流，并利用面向返回编程（ROP）链完全控制系统。Mythos Preview可以获取这些原语，并推理如何组合它们形成可工作的证明。它沿途展现的推理过程看起来像高级研究员的工作，而不是自动化扫描仪的输出。
证明生成——发现漏洞和证明漏洞可利用是两回事，而Mythos Preview两者都能做到。它会编写触发可疑漏洞的代码，在临时环境中编译并运行。如果程序行为符合模型预期，那就是证明。如果不符合，模型读取失败信息，调整假设，然后重试。这个循环与它发现的漏洞同样重要，因为可疑的缺陷如果没有可工作的证明就只是猜测，而Mythos Preview自动弥补了这一差距。
Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit.
上面描述的有些功能并非Mythos Preview独有。当我们用同样的框架运行其他前沿模型时，它们发现了相当多相同的底层漏洞，在某些情况下，它们在推理方面也比我们预期的走得更远。它们的短板在于将碎片拼接在一起的能力。一个模型可能会识别出一个有趣的漏洞，写出深思熟虑的描述说明其重要性，然后停止，留下未完成的攻击链和悬而未决的可利用性问题。Mythos Preview带来的变化是，模型现在可以将那些低严重性漏洞（传统上会隐藏在积压工作中）串联成一个更严重的利用。
Model refusals in legitimate vulnerability research
The Mythos Preview model provided by Anthropic, as part of Project Glasswing, did not have the additional safeguards that are present in generally available models (like Opus 4.7 or GPT-5.5).
Despite this, the model organically pushes back on certain requests - much like the cyber capabilities that made it useful for vulnerability hunting, the model has its own emergent guardrails that sometimes cause it to push back on legitimate security research requests. But as we found, these organic refusals aren’t consistent - the same task, framed differently or presented in a different context, could produce completely different outcomes as illustrated in the examples below.
Example of Mythos Preview pushing back on building a working proof of concept
For example, the model initially refused to do vulnerability research on a project, then agreed to perform the same research on the same code after an unrelated change to the project’s environment. Nothing about the code being analyzed had changed.
In another case, the model found and confirmed several serious memory bugs in a codebase, and then refused to write a demonstration exploit. The same request, framed differently, got a different answer, and even the same request can produce different outcomes across runs due to the probabilistic nature of the model. Semantically equivalent tasks can produce opposite outcomes depending on how and when they’re presented to the model.
This matters because while the model’s organic refusals/guardrails are real, they aren’t consistent enough to serve as a complete safety boundary on their own. That’s precisely why any capable cyber frontier model made generally available in the future must include additional safeguards on top of this baseline behavior - making it appropriate for broader use outside of a controlled research context like Project Glasswing.
模型在合法漏洞研究中的拒绝行为
Anthropic作为Project Glasswing一部分提供的Mythos Preview模型，没有通用可用模型（如Opus 4.7或GPT-5.5）中存在的额外安全防护。
尽管如此，模型自然地会对某些请求进行抵制——就像使其对漏洞搜索有用的网络能力一样，模型有自己的涌现护栏，有时会导致它拒绝合法的安全研究请求。但我们发现，这些自发的拒绝并不一致——同样的任务，以不同方式或在不同上下文中呈现，可能产生完全不同的结果，如下例所示。
Mythos Preview拒绝构建工作概念证明的示例
例如，模型最初拒绝在一个项目上进行漏洞研究，但在项目环境发生无关更改后，它同意对同样的代码进行相同的研究。分析的代码没有任何变化。
另一个案例中，模型发现并确认了代码库中的几个严重内存漏洞，然后拒绝编写演示利用。同样的请求，以不同方式提出，得到不同的回答；甚至相同的请求也可能因模型的概率性质而在不同运行中产生不同结果。语义等价的任务可能产生相反的结果，取决于如何以及何时呈现给模型。
这很重要，因为尽管模型自发的拒绝/护栏是真实的，但它们不够一致，无法单独作为完整的安全边界。正是因为这个原因，任何未来普遍可用的强大网络前沿模型，必须在基础行为之上包含额外的安全防护，使其适合在受控研究环境（如Project Glasswing）之外更广泛地使用。
The signal-to-noise problem
One of the hardest parts of triaging security vulnerabilities is deciding which bugs are real, which are exploitable, and which need fixing now. This was a hard problem even in the pre-AI world. AI vulnerability scanners and AI-generated code have made it worse, and at Cloudflare we've built multiple post-validation stages to deal with it.
Two factors dominate the noise rate:
Programming language - C and C++ give you direct memory control and, with it, bug classes - buffer overflows, out-of-bounds reads and writes - that memory-safe languages like Rust eliminate at compile time. We saw consistently more false positives from projects written in memory-unsafe languages.
Model bias - A good human researcher tells you what they found and how confident they are. Models don't. Ask a model to find bugs, and it will find them, whether the code has any or not. Findings come back hedged with "possibly," "potentially," "could in theory," and the hedged findings vastly outnumber the solid ones. That's a reasonable bias for an exploratory tool. It's a ruinous one for a triage queue, where every speculative finding spends human attention and tokens to dismiss, and that cost compounds across thousands of findings.
Mythos Preview represents a clear improvement here, particularly in its ability to chain primitives - combining multiple vulnerabilities into a working proof of concept rather than reporting them in isolation. A finding that arrives with a PoC is a finding you can act on, and it means far less time spent asking "is this even real?"
Our harnesses are deliberately tuned to over-report, so we see more (and miss less), which comes with a lot more noise. But at triage time, Mythos Preview's output has noticeably higher quality: fewer hedged findings, clearer reproduction steps, and less work to reach a fix-or-dismiss decision.
信号噪声问题
安全漏洞分类中最困难的部分之一是判断哪些漏洞是真实的、哪些是可利用的、哪些需要立即修复。即使在AI之前的世界，这也是一个难题。AI漏洞扫描器和AI生成的代码使情况变得更糟，在Cloudflare，我们构建了多个后验证阶段来处理它。
两个因素主导了噪声率：
编程语言——C和C++提供直接的内存控制，随之而来的是漏洞类别——缓冲区溢出、越界读写——而Rust等内存安全语言在编译时就消除了这些。我们持续看到来自非内存安全语言编写的项目的误报率更高。
模型偏见——优秀的人类研究人员会告诉你他们发现了什么以及有多确定。模型不会。让模型找漏洞，它就会找到，无论代码中是否有漏洞。发现结果带有“可能”、“潜在”、“理论上可以”等修饰词，且带修饰的结果远多于确凿的。这对于探索工具来说是合理的偏见。但对于分类队列来说是毁灭性的，每个推测性发现都会消耗人力和token来排除，而且这种成本在数千个发现中不断累积。
Mythos Preview在这方面有了明显改进，尤其是在串联原语方面——将多个漏洞组合成一个工作概念验证（PoC），而不是孤立地报告。带有PoC的发现是可操作的发现，这意味着花在问“这到底是不是真的？”上的时间大大减少。
我们的框架有意调高报告率，以便我们看到更多（漏得更少），但这带来了更多噪声。但在分类时，Mythos Preview的输出质量明显更高：更少的模棱两可的发现、更清晰的复现步骤、更少的工作量就能做出修复或忽略的决定。
Why pointing a generic coding agent at a repo doesn't work
When we first started AI-assisted vulnerability research last year, our instinct was the obvious one: point a generic coding agent at an arbitrary repository and ask it to discover vulnerabilities. This approach works, in the sense that the model will produce findings, but it doesn't work in producing meaningful coverage of a real codebase and identifying findings of value. There are two main reasons for this:
Context - Coding agents are tuned for one focused stream of work: building a feature, fixing a bug, writing a refactor. They ingest a lot of source code, hold a single hypothesis at a time, and iterate against it. That's exactly the wrong shape for vulnerability research, which is narrow and parallel by nature. A human researcher picks one specific thing to look at and investigates it thoroughly. That one thing might be a single complex feature, transitions across security boundaries, or a specific vulnerability class like command injections, where attacker input ends up being run as a shell command. Then they do it again, for a different feature, security boundary, or vulnerability class, several thousand times across the codebase. A single agent session (even with subagents) against a hundred-thousand-line repository can cover maybe a tenth of a percent of the surface in a useful way before the model's context window fills up and compaction kicks in - potentially discarding earlier findings that would have mattered.
Throughput - A single-stream agent does one thing at a time, but real codebases need many hypotheses against many components at once, with the ability to fan out further when something interesting turns up. You can drive a single agent harder, but at some point you stop being limited by the model and start being limited by the shape of the interaction itself. Using the model directly in a coding agent turns out to be fine for manual investigation when a researcher already has a lead and wants a second pair of eyes. However, it's the wrong tool for achieving high coverage. Once we accepted that, we stopped trying to make Mythos Preview do the wrong job and started building the harness around it instead.
为什么将通用编码代理指向仓库行不通
去年我们刚开始AI辅助漏洞研究时，直觉上的做法很直接：将通用编码代理指向任意仓库，让它发现漏洞。这种方法在模型会产生成果的意义上有效，但无法对真实代码库提供有意义的覆盖并识别有价值的发现。主要原因有两个：
上下文——编码代理针对单一集中的工作流调优：构建功能、修复漏洞、编写重构。它们摄入大量源代码，一次保持一个假设，并针对它迭代。这恰好与漏洞研究所需的方式相反，漏洞研究本质上是狭窄且并行的。人类研究人员会选择一件具体事情深入调查。那件事可能是一个复杂特性、跨安全边界的转换、或者特定的漏洞类别（如命令注入，攻击者输入最终作为shell命令执行）。然后他们再对另一个特性、安全边界或漏洞类别重复这个过程，在代码库中进行数千次。单个代理会话（即使有子代理）针对十万行代码仓库，在模型上下文窗口填满并触发压缩之前，可能只能以有用的方式覆盖表面的一小部分——可能丢弃早期重要的发现。
吞吐量——单流代理一次只做一件事，但真实代码库需要同时针对多个组件进行多个假设，并在发现有趣内容时进一步扩展。你可以更努力地驱动单个代理，但到某个点，限制因素不再是模型，而是交互本身的形态。在研究人员已有线索并希望获得第二双眼睛的情况下，直接在编码代理中使用模型适合手动调查。然而，它是实现高覆盖率的不正确工具。一旦我们接受了这一点，我们就停止了试图让Mythos Preview做错误的工作，转而开始围绕它构建框架。
What a harness actually fixes
Four lessons came out of running the work at scale, and each one pointed to the need for a harness that manages the overall execution:
Narrow scope produces better findings - Telling the model "Find vulnerabilities in this repository" makes it wander. Telling it "Look for command injection in this specific function, with this trust boundary above it, here's the architecture document and here's prior coverage of this area" makes it do something much closer to what a researcher would actually do.
Adversarial review reduces noise - Adding a second agent between the initial finding and the queue - one with a different prompt, a different model, and no ability to generate its own findings - catches a lot of the noise that the first agent would miss if it just checked its own work. It turns out that putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful.
Splitting the chain across agents produces better reasoning - Asking "Is this code buggy?" and "Can an attacker actually reach this bug from outside the system?" are two different questions, and the model is better at each one when you ask them separately, because each question is narrower than the combined version.
Parallel narrow tasks beat one exhaustive agent - Coverage improves when many agents work on tightly scoped questions and we deduplicate the results afterward, rather than asking one agent to be exhaustive.
Each of those observations is about model behavior, and put together they describe something that isn't a chat interface anymore. It's a harness that helps you achieve the final outcomes. The first steps to building a harness are simple, as you can ask the model to help, which is what we did. We used Mythos Preview to build on, tailor, and improve our original harnesses to suit its strengths.
框架实际解决了什么
在规模化运行这些工作的过程中，我们得到了四个教训，每一个都指向需要一个管理整体执行的框架：
窄范围产生更好的发现——告诉模型“在这个仓库中查找漏洞”会让它漫无目的。告诉它“在这个特定函数中查找命令注入，之上有信任边界，这里有架构文档和该区域的先前覆盖情况”会让它做更接近研究人员实际工作的事情。
对抗性审查减少噪声——在初始发现和队列之间添加第二个代理——使用不同的提示、不同的模型，且没有生成自己发现的能力——可以捕获大量第一个代理仅检查自身工作时会遗漏的噪声。结果证明，让两个代理故意持有异议比仅仅告诉一个代理要小心要有效得多。
跨代理拆分链产生更好的推理——问“这段代码有漏洞吗？”和“攻击者能从系统外部实际到达这个漏洞吗？”是两个不同的问题，当分开询问时，模型在每个问题上表现更好，因为每个问题比组合版本更窄。
并行窄任务胜过单个详尽代理——当许多代理处理范围严格的问题，然后我们对结果去重时，覆盖率会提高，而不是要求一个代理做到详尽。
这些观察都关于模型行为，放在一起描述了一个不再是聊天界面的东西。它是一个帮助你达成最终结果的框架。构建框架的初始步骤很简单，因为你可以请模型帮忙，我们就是这样做的。我们使用了Mythos Preview来构建、定制和改进我们原有的框架，以适应它的优势。
An example of what a harness looks like in practice is described below.
Our vulnerability discovery harness
Here's what our vulnerability discovery harness looks like, stage by stage. It was used to scan live code across our runtime, edge data path, protocol stack, control plane, and the open-source projects we depend on.
Stage
What it does
Why it matters
Recon
An agent reads the repository from the top down, fans out to subagents responsible for each subsystem, and produces an architecture document covering build commands, trust boundaries, entry points, and likely attack surface. It also generates the initial queue of tasks for the next stage.
Gives every downstream agent shared context. Cuts the wander problem.
Hunt
Each task is one attack class paired with a scope hint. Hunters (the agents that actually look for bugs) run concurrently, typically around fifty at once, each fanning out to a handful of exploration subagents. Each hunter has access to tools that compile and run proof-of-concept code in a per-task scratch directory.
This is where most of the work happens. Many narrow tasks in parallel, not one exhaustive agent.
Validate
An independent agent re-reads the code and tries to disprove the original finding. It uses a different prompt and has no ability to emit new findings of its own.
Catches a meaningful fraction of the noise the hunter wouldn't catch when reviewing its own work.
Gapfill
Hunters flag areas they touched but didn't cover thoroughly. Those areas get re-queued for another pass.
Counteracts the model's tendency to drift toward attack classes it has already had success with.
Dedupe
Findings that share the same root cause collapse into a single record.
Variant analysis is a feature, not a way to inflate the queue with duplicates.
Trace
For each confirmed finding in a shared library, a tracer agent fans out (one instance per consumer repository), uses a cross-repo symbol index, and decides whether attacker-controlled input actually reaches the bug from outside the system.
Turns "there is a flaw" into "there is a reachable vulnerability." This is the stage that matters most.
Feedback
Reachable traces become new hunt tasks in the consumer repositories where the bug is actually exposed.
Closes the loop. The pipeline gets better as it runs.
Report
An agent writes a structured report against a predefined schema, fixes any validation errors against that schema itself, and submits the report to an ingest API.
Output is queryable data, not free-form prose.
下面是一个框架实际示例的描述。
我们的漏洞发现框架
下面展示我们的漏洞发现框架分阶段的样子。它用于扫描我们在运行时、边缘数据路径、协议栈、控制平面以及所依赖的开源项目中的实时代码。
阶段
作用
为何重要
侦察（Recon）
一个代理自上而下读取仓库，分派出负责每个子系统的子代理，生成涵盖构建命令、信任边界、入口点和潜在攻击面的架构文档。同时为下一阶段生成初始任务队列。
为所有下游代理提供共享上下文。削减漫无目的的问题。
狩猎（Hunt）
每个任务是一个攻击类别加上范围提示。猎人（实际寻找漏洞的代理）并发运行，通常一次大约50个，每个分出若干探索子代理。每个猎人可访问工具，在每任务的临时目录中编译和运行概念验证代码。
这是大部分工作发生的地方。许多窄任务并行，而不是一个详尽代理。
验证（Validate）
一个独立代理重新读取代码，试图反驳原始发现。它使用不同的提示，并且没有能力发出自身的新发现。
捕获猎人检视自身工作时不会捕获的相当一部分噪声。
补缺（Gapfill）
猎人标记它们触及但未彻底覆盖的区域。这些区域重新排队进行另一轮。
抵消模型倾向于漂移到已取得成功攻击类别的趋势。
去重（Dedupe）
具有相同根本原因的发现合并为一条记录。
变体分析是特性，不是用重复项膨胀队列的方式。
追踪（Trace）
对于共享库中的每个确认发现，追踪代理分发出一个实例（每个消费者仓库一个），使用跨仓库符号索引，判断攻击者控制的输入是否实际从系统外部到达漏洞。
将“存在缺陷”转变为“存在可达漏洞”。这是最重要的阶段。
反馈（Feedback）
可达追踪成为漏洞实际暴露的消费者仓库中的新狩猎任务。
闭环。管道随着运行而改善。
报告（Report）
一个代理根据预定义模式编写结构化报告，针对该模式自行修复任何验证错误，并将报告提交给ingest API。
输出是可查询的数据，而不是自由形式的散文。
What this means for security teams
The loudest reaction to Mythos Preview from other security leaders has been about speed - scan faster, patch faster, compress the response cycle. More than one team we have spoken with is now operating under a two-hour SLA from CVE release to patch in production. The instinct is understandable: when the attacker timeline shortens, the defender timeline has to shorten with it. Faster is not going to be enough, and we think a lot of teams are about to spend a lot of time, effort, and money learning that the hard way.
Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch. We learned a version of this when we tried letting the model write its own patches and watched a few go out that fixed the original bug while quietly breaking something else the code depended on.
The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it.
We also recognize this topic cuts both ways. The same capabilities that helped us find bugs in our own code will, in the wrong hands, accelerate the attack side against every application on the Internet. Cloudflare sits in front of millions of those applications, and the architectural principles described above are exactly the ones our products are built to apply on behalf of customers. We will share more on what that means for customers in the weeks ahead.
If your team is doing similar work and would like to compare notes, reach out to us at [email protected].
Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process.
这对安全团队意味着什么
其他安全领导者对Mythos Preview最强烈的反应是关于速度——扫描更快、打补丁更快、压缩响应周期。我们接触过的多个团队现在正按照从CVE发布到生产环境补丁的两小时SLA运作。这种直觉可以理解：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但仅靠更快是不够的，我们认为很多团队将花费大量时间、精力和金钱来艰难地认识到这一点。
更快的打补丁并不能改变产生补丁的流水线形状。如果回归测试需要一天，除非跳过它，否则无法实现两小时SLA，而跳过回归测试时发布的漏洞往往比原本试图修补的漏洞更糟糕。当我们尝试让模型自己编写补丁时，曾遇到过类似情况：我们看到一些补丁修复了原始漏洞，却悄悄地破坏了代码依赖的其他东西。
更困难的问题是围绕漏洞的架构应该是什么样的。原则是即使在存在漏洞的情况下，也让攻击者更难利用，从而缩小漏洞披露与修复之间的差距影响。这意味着在应用程序前端部署防御，阻止漏洞被触及。意味着设计应用程序时，代码一部分的缺陷不能让攻击者访问其他部分。意味着能够同时在所有运行代码的地方部署修复，而不是等待个别团队部署。
我们也认识到这个话题是双刃剑。帮助我们找到自身代码漏洞的相同能力，如果落入坏人之手，将加速针对互联网上每个应用程序的攻击。Cloudflare位于数百万个此类应用程序之前，上述架构原则正是我们产品代表客户应用的原则。我们将在未来几周分享更多关于这对客户意味着什么。
如果您的团队正在进行类似工作并希望交流经验，请通过[email protected]联系我们。
我们使用Mythos Preview的研究是在受控环境中针对我们自己的代码进行的；通过这项工作发现的每个漏洞都按照Cloudflare的正式漏洞管理流程进行了分类、验证和修复。
This work was a team effort. Thanks to Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, and Rohit Chenna Reddy for their contributions to the research, engineering, and analysis behind this blog post.
SecurityAIAgentsThreat IntelligenceLLMRisk ManagementThreat OperationsAutomationEngineering
这项工作是团队共同努力的结果。感谢Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl和Rohit Chenna Reddy对本文背后的研究、工程和分析的贡献。
安全 AI 智能体 威胁情报 LLM 风险管理 威胁运营 自动化 工程