Project Glasswing：Mythos が示したもの

過去数ヶ月間、Cloudflare は自社インフラストラクチャ上でセキュリティ特化型LLMをテストしてきました。これらのLLMはシステム内の潜在的な脆弱性を特定し、修正するのに役立つと同時に、最新モデルを使って攻撃者が何をできるようになるかを示しています。中でも、Anthropic の Mythos Preview は大きな注目を集めています。Project Glasswing の一環として、Cloudflare は Mythos Preview を使用する機会を得て、50以上のリポジトリに適用し、その実力を評価しました。

Mythos Preview の進歩

Mythos Preview は脆弱性調査において真の進歩を示しました。これまでの汎用フロンティアモデルとは異なり、単なる改良ではなく、異なる種類のツールとして異なる作業を行います。特に際立った2つの機能は以下の通りです：

• エクスプロイトチェーン構築：実際の攻撃は単一のバグではなく、複数の小さな攻撃プリミティブを連鎖させてエクスプロイトを構成します。Mythos Preview はこれらのプリミティブを組み合わせ、動作する概念実証（PoC）を構築する方法を推論できます。その推論プロセスは、シニアリサーチャーの作業に似ています。
• プルーフ生成：バグを発見することと、それが悪用可能であることを証明することは別物です。Mythos Preview はその両方を実行できます。疑わしいバグをトリガーするコードを書き、サンドボックス環境でコンパイルして実行し、プログラムが期待通りに動作すれば証明完了です。失敗した場合はエラーを読み取り、仮説を調整して再試行します。このループにより、推測に過ぎなかった欠陥が確固たる証明に変わります。

他のフロンティアモデルも同様の基礎的なバグを発見できましたが、それらを連鎖させる点で劣っていました。Mythos Preview は、低重要度のバグ（従来はバックログに埋もれていた）を連鎖させ、より深刻なエクスプロイトに変えることができます。

有機的拒否と安全境界

Project Glasswing で使用された Mythos Preview モデルには、一般公開モデル（Opus 4.7 や GPT-5.5 など）にある追加の安全策は含まれていませんでした。それにもかかわらず、このモデルは特定のリクエストに対して有機的に拒否を示します。これは脆弱性ハンティングに有用な能力と同様に、モデル自身が持つ創発的なガードレールによるものです。しかし、これらの拒否は一貫性がありません。同じタスクでも、異なる文脈や表現で提示されると全く異なる結果を生む可能性があります。例えば、あるプロジェクトでの脆弱性調査を最初は拒否したものの、環境に無関係な変更を加えた後には同意する、といったケースがありました。この不一致は、モデル自身のガードレールだけでは完全な安全境界として機能しないことを意味し、将来の汎用フロンティアモデルには追加の安全策が不可欠です。

信号対ノイズ問題

脆弱性のトリアージにおいて最も難しい部分の一つは、どのバグが本物で、悪用可能で、今すぐ修正すべきかを判断することです。プログラミング言語とモデルのバイアスがノイズの主な原因です。C や C++ は直接メモリ制御によりバグクラス（バッファオーバーフロー、範囲外読み取り/書き込み）を引き起こしやすく、メモリ安全言語よりも偽陽性が多く見られました。また、モデルはバグを探すよう指示されると、コードに実際にバグがなくても「可能性がある」「潜在的に」「理論上は」といった曖昧な発見を大量に返します。これは探索ツールとしては妥当ですが、トリアージキューにとっては破滅的です。Mythos Preview はこの点で明らかに改善しており、特にプリミティブの連鎖能力により、PoC が付属した発見は即座に対応可能で、「これは本当に存在するのか？」という確認にかかる時間を大幅に削減します。

汎用コーディングエージェントが機能しない理由

当初、Cloudflare は汎用コーディングエージェントを任意のリポジトリに向け、脆弱性を発見するよう指示しました。この方法は結果を出しますが、現実のコードベースに対する有意義なカバレッジを提供しません。理由は2つあります：

• コンテキスト制限：コーディングエージェントは単一の作業ストリーム（機能追加、バグ修正、リファクタリング）に最適化されていますが、脆弱性調査は狭く並列的な性質を持ちます。単一のエージェントセッションが10万行のリポジトリを調査できるのは、有用な表面積のせいぜい0.1%程度です。
• スループット制限：単一ストリームのエージェントは一度に一つのことしかできませんが、実際のコードベースは多くのコンポーネントに対して多数の仮説を同時に必要とします。エージェントを強く駆動しても、モデルの限界ではなく対話の形状自体がボトルネックになります。

ハーネスの役割

大規模な実行から得られた4つの教訓は、それぞれ全体的な実行を管理するハーネスの必要性を示しています：

1. 狭い範囲がより良い発見を生む：具体的な範囲と対象を指定すると、モデルは研究者により近い行動をとる。
2. 敵対的レビューがノイズを減らす：初期発見とキューの中間で、異なるプロンプトとモデルを持つ第二のエージェントを導入し、発見を生成せずにレビューのみ行わせると、多くのノイズを捕捉できる。
3. チェーンの分割が推論を改善する：「このコードはバグがあるか？」と「攻撃者が外部からこのバグに到達可能か？」を別々に問うことで、モデルは各質問に正確に答える。
4. 並列狭タスクが単一網羅エージェントより優れる：厳密に限定された質問に取り組む多数のエージェントとその後の重複排除が、単一エージェントの網羅的試行より効果的。

これらの観察は、チャットインターフェースではなく、最終結果を達成するためのハーネスを指向しています。Cloudflare は Mythos Preview を活用して既存のハーネスを構築・調整し、その強みを最大限に引き出しました。

脆弱性発見ハーネスの例

Cloudflare の脆弱性発見ハーネスは、ランタイム、エッジデータパス、プロトコルスタック、コントロールプレーン、依存するオープンソースプロジェクトをスキャンするために、以下の段階で構成されています：

• 偵察段階：エージェントがリポジトリをトップダウンで読み、サブシステムごとにサブエージェントに展開し、ビルドコマンド、信頼境界、エントリポイント、攻撃面を含むアーキテクチャ文書を生成。次の段階のタスクキューも作成。
• 狩猟段階：偵察で得たタスクに基づき、特定のサブ領域に深く潜り込み、脆弱性を検索。
• 検証段階：独立したエージェントが発見を攻撃可能性の観点で検証し、実際に悪用できないものを除外。
• 合成段階：検証済みの脆弱性を連鎖させて完全なエクスプロイトを構成し、レポートを生成。

この構造化アプローチにより、脆弱性発見の効率と信頼性が大幅に向上し、AI支援セキュリティ研究のスケーラブルなフレームワークを提供しています。