Project Glasswing：Mythosが示したこと

Grant Bourzikas — 9 min read — Published: 2026-05-18

ここ数ヶ月、私たちは自社インフラ上でセキュリティ特化型のLLM群をテストしてきました。これらのLLMは、自社システムの潜在的な脆弱性を特定して修正を促す手助けをするだけでなく、攻撃者が最新モデルを使って何ができるかを示してくれます。これらの中で最も注目を集めたのは、AnthropicのMythos Previewでした。

数週間前、私たちはProject Glasswingの一環としてMythos Previewの使用に招かれました。すぐに50以上の自社リポジトリに向けて実行し、何を見つけるのか、どのように動くのかを検証しました。本稿は私たちの観察結果、モデルが得意なこと・苦手なこと、そして大規模運用のためにアーキテクチャとプロセスをどう変える必要があるかを共有するものです。

Mythos Previewで何が変わったか

Mythos Previewは明確な前進であり、率直にそう述べる価値があります。私たちはしばらく前からコードに対してモデルを走らせてきましたが、従来の汎用フロンティアモデルから今日のMythos Previewへと進化した差は、単なる改良ではありません。異なる種類の作業を行う別種のツールであり、以前のモデルと単純に比較するのは難しいのです。したがって、Mythos Previewを汎用モデルとベンチマークするよりも、実際に何ができるのかを記述する方が有益です。私たちが行った作業で目立った二つの特徴は次の通りです。

• エクスプロイト連鎖の構築

  • 実際の攻撃は稀にひとつのバグだけを使うことはありません。複数の小さな攻撃プリミティブを連結して動くエクスプロイトを作ります。例えば、use-after-freeバグを任意読み取り/書き込みプリミティブに変え、制御フローを乗っ取り、return-oriented programming (ROP)チェーンを使ってシステムの完全制御を取る、という具合です。Mythos Previewはこれら複数のプリミティブを取り、どのように組み合わせて動作する証明を作るかを推論できます。その過程で示す推論は、自動スキャナの出力というよりは上級研究者の仕事に近く見えます。

• 証明（Proof）生成

  • バグを見つけることと、それが実際に悪用可能であることを証明することは別物です。Mythos Previewは両方を行えます。疑わしいバグをトリガーするコードを書き、スクラッチ環境でコンパイルし、実行します。プログラムがモデルの期待どおり動けばそれが証明です。期待どおり動かなければ、モデルは失敗を読み取り仮説を調整して再試行します。このループは発見されたバグと同じくらい重要です。疑わしい欠陥が動作する証明なしに残るのは推測にすぎませんが、Mythos Previewはそれを自動で埋めます。

上記のうちいくつかはMythos Preview固有のものではありません。他のフロンティアモデルを同じハーネスにかけたとき、同じ基礎的なバグの多くを見つけ、場合によっては推論の面でも想定以上に進んだ例もありました。しかし彼らが失速したのは、ピースを縫い合わせる点でした。モデルは興味深いバグを特定し、その重要性を考察する記述を書き、それから止まってしまい、実際の連鎖は未完でエクスプロイト可能性は未解決のままとなることが多かったのです。Mythos Previewで変わったのは、従来はバックログの中で見えずに座していたような低重大度のバグを取り、それらを連鎖させてより深刻な単一のエクスプロイトにできる点です。

正当な脆弱性調査におけるモデルの拒否

Project Glasswingの一環としてAnthropicが提供したMythos Previewには、Opus 4.7やGPT-5.5のような一般公開モデルにある追加の安全機構はありませんでした。それでもモデルは一定のリクエストに対して自発的に拒否を示すことがありました。サイバー能力が脆弱性ハンティングに有用である一方で、モデル自体にも出現的なガードレールがあり、正当なセキュリティ調査の要求に対して時折拒否することがある、ということです。

ただし、こうした自発的な拒否は一貫していません。同じタスクを別の文脈で、あるいはわずかに異なる提示の仕方で与えると、全く異なる結果が出ることがありました。以下の例がそれを示しています。

Mythos PreviewがPoCの作成を拒否した例

• あるプロジェクトでモデルが最初は脆弱性調査を拒否したのに、プロジェクト環境に無関係な変更を加えたあとで同じコードに対する同一の調査を受け入れたことがありました。解析対象のコード自体は何も変わっていませんでした。
• 別のケースでは、モデルはあるコードベースで複数の深刻なメモリバグを発見・確認した後にデモ用のエクスプロイトの作成を拒否しました。同じ要求を別の言い回しで与えると異なる答えが返り、また確率的性質のため同一の要求でも実行毎に結果が変わることがあります。

意味的に同等なタスクでも、提示の仕方やタイミングによって逆の結果が出ることがあります。これは重要です。モデルの自発的な拒否／ガードレールは実在しますが、それだけでは一貫した安全境界にはなり得ません。だからこそ将来、強力なサイバーフロンティアモデルが一般提供される際には、このベースラインの振る舞いに上乗せする追加の安全措置が必要になるのです。Project Glasswingのような管理された研究コンテキスト外で適切に使えるようにするためです。

信号対雑音の問題

脆弱性のトリアージで最も難しい部分の一つは、どのバグが実在し、どれが悪用可能で、どれを今すぐ修正すべきかを決めることです。AI以前の世界でもこれは難題でした。AI脆弱性スキャナやAI生成コードの登場で状況は悪化し、Cloudflareではそれに対処するため複数のポストバリデーション段階を構築しています。

雑音率を支配する要因は主に二つです。

• プログラミング言語
  • CとC++は直接的なメモリ制御を与えるため、バッファオーバーフローや境界外読み書きといったバグクラスが生まれます。Rustのようなメモリ安全言語はそれらをコンパイル時に排除します。メモリ非安全言語で書かれたプロジェクトからは一貫して誤検知が多く出ました。
• モデルバイアス
  • 良い人間の研究者は見つけたものと自信度を伝えますが、モデルはそうしません。モデルにバグを探させると、コードにバグがあろうとなかろうと見つけてきます。結果は「おそらく」「潜在的に」「理論上はあり得る」といった慎重な表現で返ってきて、確実な所見を大きく上回ります。探索的ツールとしては妥当なバイアスですが、トリアージキューでは破滅的です。推測的な所見のひとつひとつが人間の注意とトークンを消費し、それが何千件と積み重なるとコストは爆発します。

Mythos Previewはこの点で明確な改善を示します。特にプリミティブを連鎖させる能力—複数の脆弱性を単独で報告するのではなく、動作するPoCに組み合わせる—が効いています。PoC付きの所見は対処可能な所見であり、「本当に実在するか？」を問い直す時間がぐっと減ります。

私たちのハーネスは意図的に過報告にチューニングしているため、より多くを見て（見落としを減らし）騒音も増えます。しかしトリアージ時、Mythos Previewの出力は明らかに質が高く、慎重な言い回しが少なく、再現手順が明確で、修正か取り下げかの判断に至るまでの作業が少なくて済みます。

なぜ汎用のコーディングエージェントをリポジトリに向けても上手くいかないのか

昨年AI支援の脆弱性調査を始めたとき、私たちの直感は単純でした：汎用のコーディングエージェントを任意のリポジトリに向けて脆弱性を見つけさせよう、というものです。このアプローチはモデルが所見を出すという点では機能しますが、実際のコードベースを意味のあるカバレッジで調査し、価値ある所見を特定する点では機能しません。理由は二点です。

• コンテキスト
  • コーディングエージェントは一つの集中的な作業フロー（機能構築、バグ修正、リファクタリングなど）にチューニングされています。大量のソースを取り込み、同時に一つの仮説を保持して反復します。これは脆弱性調査に向かない形です。脆弱性調査は狭く並列的です。人間の研究者は特定の一箇所に絞って徹底的に調べます。それが複雑な機能の一部か、セキュリティ境界の遷移か、あるいはコマンドがシェルで実行されるようなコマンドインジェクションのような特定の脆弱性クラスであるかもしれません。それを別の箇所、別のクラスで何千回も繰り返します。1セッションのエージェント（サブエージェントを使っても）で十万行規模のリポジトリを扱うと、コンテキストウィンドウが埋まり、圧縮が働く前に有用にカバーできる表面の割合はほんのわずかです。しかも初期の所見が捨てられることもあります。
• スループット
  • 単一ストリームのエージェントは一度に一つのことしかできませんが、実際のコードベースでは多くのコンポーネントに対して多くの仮説を同時並行で検証し、何か興味深いものが出たらさらに扇状に広げる能力が必要です。エージェントを強く駆動することはできますが、ある時点で制約はモデル自体ではなく、インタラクションの形に移ります。

モデルをそのままコーディングエージェントとして使うのは、研究者が既にリードを持っていて第2の目が欲しいという手動調査には適しています。しかし高いカバレッジを達成するには間違った道具です。これを受け入れた時点で、私たちはMythos Previewに無理をさせるのをやめ、代わりにその周りのハーネスを構築し始めました。

ハーネスが実際に解決すること

大規模での運用を通じて得られた教訓は四つあり、いずれも全体の実行を管理するハーネスの必要性を指し示していました。

• 狭いスコープはより良い所見を生む
  • モデルに「このリポジトリの脆弱性を見つけろ」と言うと彷徨いますが、「この特定の関数でコマンドインジェクションを探せ、この信頼境界より上にある、ここにアーキテクチャ文書と既存のカバレッジがある」と指示すると、研究者が実際に行うのに近い行動をします。
• 敵対的レビューは雑音を減らす
  • 初期所見とキューの間に別のエージェント（異なるプロンプト、異なるモデルで、自身で所見を生成する能力は持たない）を挟むことで、第一段のエージェントが見落とす雑音の多くを取り除けます。二つのエージェントを意図的に対立させる方が、単一エージェントに慎重になるよう指示するよりも効果的であることが分かりました。
• チェーンを分割すると推論が良くなる
  • 「このコードはバグか？」と「攻撃者が外部から実際にこのバグに到達できるか？」は別々の問いです。モデルはそれぞれを個別に聞かれた方が得意です。各問いは組み合わせた問いより狭いからです。
• 並列の狭いタスクは一つの exhaustive なエージェントより優れる
  • 多数のエージェントが厳密にスコープされた問いに取り組み、後で結果を重複除去する方が、一つのエージェントに網羅を求めるよりカバレッジが改善します。

これらの観察はすべてモデルの振る舞いに関するもので、総じてチャットインターフェースではなく、最終的な成果を達成するためのハーネスを示しています。ハーネスを構築する最初のステップは単純で、モデル自身に手伝わせることができます。私たちもそうしました。Mythos Previewを使って元のハーネスを拡張・調整し、その強みに合わせました。

私たちの脆弱性発見ハーネス

以下は私たちの脆弱性発見ハーネスの段階別概要です。ランタイム、エッジデータパス、プロトコルスタック、コントロールプレーン、依存するオープンソースプロジェクトなど、実際のコードを走査するために使用しました。

段階	何をするか	なぜ重要か
Recon	エージェントがリポジトリを上から下へ読み、各サブシステムを担当するサブエージェントへファンアウトし、ビルドコマンド、信頼境界、entry

（本文はここで原文が途切れています）