イーサリアム財団のプロトコルセキュリティチームによる、実際のプロトコルコードに対して連携したAIエージェントを実行した際のメモです。作業の構成方法、精査に耐えうるもの、そしてクライアントチームやセキュリティ研究者がそこから得られるものについて説明します。この記事は単独で完結していますが、今後の記事で個々のクライアントについてさらに深く掘り下げる予定です。
私たちが実行してきたこと、そして驚いたこと
イーサリアム財団のプロトコルセキュリティチームでは、システムソフトウェア、暗号コード、正確性が求められるコントラクトなど、ネットワークが依存する種類のシステムに対して、連携したAIエージェントを実行してきました。エージェントは実際のバグを発見しました。そのうちの1つは現在公開されています。それは、イーサリアムのコンセンサスクライアントが実行されるピア・ツー・ピア層の中核部分であるlibp2pのgossipsubにおける、リモートからトリガー可能なパニックです。これは修正され、チームの功績としてCVE-2026-34219として公開されました。
エージェントがバグを発見したこと自体は驚きではありませんでした。驚いたのは、バグを見つけるための作業が非常に少なく、本物のバグと本物のように見えるだけのバグを見分けるために多くの作業が費やされたことです。
この記事は、同じことを行いたいと考えているクライアントチームやセキュリティ研究者に向けたものです。エージェントの構成方法、候補が発見としてカウントされるためにクリアしなければならない基準、そして結果の信頼性を保つための習慣について網羅しています。
他のチームも同じ手法に収束しつつあります。Anthropicのフロンティア・レッドチームは、プロパティベースのテストを記述し、Pythonエコシステム全体で実際のバグを発見するエージェントを構築しました。Cloudflareは、自社のシステムに対してセキュリティ研究用のハーネスを通じてフロンティアモデルを実行しました。誰もが同じループに行き着きます。つまり、有能なモデルをコードベースに向け、検索させ、返ってきたものをトリアージするのです。したがって、本当の課題は、自信ありげなノイズに溺れることなく、これをどのように行うかということです。
最初に1つ注意点があります。エージェント主導の監査ツールは進化が速く、特定のセットアップは数週間で時代遅れになります。そのため、この記事ではツールではなく、永続的である手法について意図的に焦点を当てています。情報開示（ディスクロージャー）はそれ自体が1つのトピックであり、おそらく別の記事として取り上げる予定です。
エージェントは検索ツールであり、オラクルではない
コードベースに向けられたエージェントは、ファザー（fuzzer）によく似た検索ツールです。違いは、何が返ってくるかです。ファザーはクラッシュとスタックトレースを渡してくれます。エージェントは、レポート（コールチェーン、影響の請求、提案される深刻度）や、実際のコードに対して実行できる概念実証（PoC）のようなそれを裏付ける成果物など、はるかに多くのものを渡してくれます。
これらすべてにより、結果は読みやすく、信頼しやすくなります。中でも実行可能な概念実証は最も信頼できる要素です。したがって、エージェントが生成した候補の数を数えるのではなく、そのうちいくつが本物であったかを数えてください。
作業の構成方法
私たちは、1つのターゲットに対して多数のエージェントを並行して実行しています。エージェントはリポジトリ自体を通じて連携し、バージョン管理システム内で状態を共有し、作業を割り当てる中央プロセスは存在しません。エージェントは他のエージェントが見える場所に請求を書き留め、作業を行い、コミットします。
私たちはこのアプローチを、同じ方法で連携するAnthropicのエージェント群を用いたCコンパイラの構築に関するレポートから得ました。構築や保守が必要な中央コーディネーターが存在しないため、問題が発生する可能性も低くなります。
役割は、発見された作業によって生成されます。
- 偵察（Recon）は、アタックサーフェス（攻撃対象領域）を具体的でテスト可能な仮説に変換します。「デコーダーを監査する」のではなく、「このフィールドはこの時点以降信頼されている。これが維持すべきプロパティであり、これが壊れる可能性のある方法であり、そしてこれを解決する証明である」といった具合です。
- ハンティング（Hunting）は、1つの仮説を取り上げ、コードパスをトレースし、再現手順（reproducer）の構築を試みます。
- ギャップフィル（Gap-filling）は、何が受け入れられ、何が拒否されたかを確認し、次の仮説のバッチを作成し、エージェントが同じ領域を繰り返し探索しないようにカバレッジを追跡します。
- 検証（Validation）は、各候補を独立して再チェックし、重複を削除して、判定を下します。
私たちがこのパイプラインを発明したわけではありません。Cloudflareも、偵察、並行ハンティング、独立した検証、重複排除、レポート作成という同じ段階について説明しており、彼らのレポートは私たちのパイプラインを形成するのに役立ちました。
候補が発見としてカウントされる前の状態は以下のようになります。
ターゲット: 攻撃者が実際に到達できるコンポーネントとエントリポイント 不変条件: 維持されなければならないプロパティ メカニズム: それが壊される可能性のある具体的な方法 成功: 観察可能な証明：パニック、ストール、受け入れられた無効な入力 再現手順: 実際のコードに対して実行される自己完結型の成果物 重複排除: 2つのエージェントが同じものを追跡しないためのキー
このスキーマが存在するのには理由があります。これにより、具体的でテスト可能な請求と、完了の明確な定義が強制されます。観察可能な証明を書き留めなければならないエージェントは、「これはリスクが高そうだ」という曖昧な表現に逃げることができません。
再現可能でなければ起きていないのと同じ
他のどのルールよりも重要なルールが1つあります。実際のコードに対して障害を再現し、それを書いた本人以外でも実行できる自己完結型の成果物が存在しない限り、候補は発見とはみなされません。
再現手順はレポートを読みませんし、モデルがどれほど自信ありげであったかも気にしません。実行できるか、できないかのどちらかです。
その価値の大部分は、誤検知（フォールス・ポジティブ）を捕捉できる点にあります。そのうちの3つは何度も繰り返し発生し、それぞれが間違った理由でエージェントがパスしてしまうケースです。
- デバッグビルドでのみ発生するパニック。ソフトウェアが実際に出荷される方法でコンパイルして実行すると、値がラップアラウンドするだけです。何もクラッシュしません。クラッシュのように見えますが、そうではありません。
- 実際の入力では決して生成されない内部値を手動で構築する再現手順。攻撃者が制御できるすべてのパスで、それより前に拒否されるためです。このバグは、到達可能なものがそのように呼び出すことのない関数に対してのみ「再現」します。
- 形式的検証の作業において、証明は通るものの、意図した意味を持たない場合。コードの動作に関係なくステートメントが自明に真であるか、捉えようとしたプロパティよりも弱い場合です。検証者は満足しますが、その定理は実際に懸念していた動作を制約しません。
これらはどれも新しいことではありません。実際には何もチェックしていないためにパスするテストと同じです。新しいのはその量です。エージェントは、本物と同じくらい速く、そして同じくらい自信を持って役に立たないバージョンを書きます。そのため、チェックは自動で行われなければなりません。エージェントが自ら間違いに気づくことを期待することはできません。
シグナル対ノイズが作業の大部分を占める
ほとんどの候補は間違っているか、重複しているか、範囲外です。それは手法の問題ではなく、そういう仕組みなのです。目標は、間違ったものを素早く拒否し、本物の候補を反論の余地がない証明で裏付けることです。
生き残ったすべての候補は、2つの独立したチェックを受けます。実際の攻撃者は、通常の構成で実際にそこに到達できるか？そして、それが成功した場合にネットワークにかかるコストと比較して、攻撃者がそれを実行するのにどれだけのコストがかかるか？単一のピアがトリガーできるバグは、特別なアクセスや膨大なリソースを必要とするバグとは大きく異なります。
すべての候補は、すでに既知、修正済み、または拒否されたものの最新リストと照らし合わせてチェックされます。これがないと、エージェントはクローズされた同じ問題を何度も再発見し、繰り返し報告し続けます。
受け入れ率はターゲットによって大きく異なり、そのばらつき自体が有用です。これを成熟し、厳密に監査されたコードに対して実行すると、生き残るものはほとんどありませんが、それでも知る価値はあります。「一生懸命探したが何も見つからなかった」というのは立派な結果です。あまり探索されていないコードや、機械によってチェックされた証明がモデルをカバーし、デプロイされたバイトコードがそれに一致すると想定されているだけの形式的検証済みのコードに対して実行すると、より多くのものが通過します。
トリアージが難しい部分であることに気づいたのは私たちだけではありません。Cloudflareの主な結論は、狭い範囲に絞る方が広範なスキャンよりも優れているということでした。Anthropicのプロパティベースのテストエージェントは、約1,000件の候補レポートを生成し、その後ランキングと専門家によるレビューを使用して、約86%の確率で有効なトップティアにまで絞り込みました。生成は簡単な部分でした。ここでは私たち自身の数値を公開するつもりはありません。特定のターゲットに結びついているため、手法についてよりもターゲットについて多くを語ることになってしまうからです。
エージェントが得意なこと、そして誤解を招くところ
どちらの方向にも誇大宣伝があるため、エージェントがうまく機能する点と誤解を招く点のシンプルなリストを以下に示します。
| 得意なこと | 誤解を招くところ |
|---|---|
| 仕様とコードを併せて読み解くこと | 到達可能に見えて実際には到達できないコールチェーン |
| 実際の不変条件を記述し、チェックすること | 成功チェックの悪用（間違った理由でのパス） |
| 1行のアイデアから再現手順の草案を作成すること | レポートの劇的な響きに合わせて深刻度を誇張すること |
| 調査する前に根本原因を提案すること | 一連の有効なステップにまたがるバグ |
この分かれ目は、タスクごとに一定しているわけでもありません。実際の脆弱性についてさまざまなモデルをテストしたStanislav Fort氏は、これをギザギザのフロンティア（jagged frontier）と呼んでいます。つまり、あるコードベースで完全なエクスプロイトチェーンを復元できるモデルが、別のコードベースでは基本的なデータフロートレースに失敗する可能性があるということです。1つの良い結果が次も通用するとは限らないため、これも各候補が個別にチェックされる理由の1つです。
最後の行が重要です。単一のエージェントセッションは、単発の推論には優れていますが、各ステップは有効で順序だけが間違っているような、一連のステップにまたがるバグには適していません。そのような場合、エージェントは検索ツールではありません。その役割は、どのシーケンスを状態を持つテストハーネスで実行する価値があるかを提案することです。そのように使用すれば、うまく機能します。ハーネスの代わりとして使用すると、シーケンス全体でしか現れないような、最も代償の大きいバグを見逃してしまいます。
信頼性を保つ
エージェントの発見を信頼できるものにするための作業の大部分は、いくつかの習慣によって成り立っており、そのどれも複雑なものではありません。
- すべての成果物の出所（プロベナンス）：何がそれを生成したのか、どのようなコンテキストで、どのリビジョンに対して生成されたのか。発見は、数ヶ月後に再実行できるものでなければなりません。
- 重要な部分での決定性：1つの環境、1つのビルドおよび実行方法。これにより、「再現する」ということが、発見されたマシンだけでなく、すべてのマシンで同じ意味を持つようになります。
- スクリプトではなく規範：番号付けされた手順ではなく、何が重要か、不変条件、そして実際の発見の基準をエージェントに伝えます。スクリプト化されすぎたエージェントは、仕様が細かすぎるテストと同じように壊れます。つまり、手順が意味をなさなくなった後も手順に従い続けるのです。リポジトリのコンテキストファイルに関する研究でも同じことが判明しています。追加の要件はタスクの成功率を下げ、コストを20%以上増加させました。著者らはコンテキストを最小限の要件にとどめることを推奨しています。
- 最終的な判断は人間が下す：エージェントは提案するだけです。何が本物か、何が既知の問題の重複か、あるいは何をいつ開示するかを決定するのはエージェントではありません。
ボトルネックの移動
AIはセキュリティ研究者を置き換えたわけではありません。作業を移動させたのです。かつて仮説を立てて追跡することに費やされていた時間は、現在では、オラクルの構築、トリアージの実行、既知の問題リストの維持、情報開示の処理など、大規模な判断を下すことに費やされています。
ボトルネックがなくなったわけではありません。バグの発見から結果の信頼へと移動しただけです。人間の判断が実際に重要になる場所であるため、これはより良い場所への移動と言えます。しかし、依然としてボトルネックであることに変わりはなく、それを無視すると、間違った「問題なし」を出荷することになります。
これを機能させるための実践は新しいものではありません。再現可能な障害、実際のオラクル、そして慎重なトリアージは、過去15年間でファジングを研究テーマから標準的な実践へと変えたのと同じ実践です。ツールは新しいですが、実践はそうではありません。
ツールがどれほど速く変化し続けるかは未解決の疑問です。慎重派であり、かつては自身も懐疑的であったNicholas Carlini氏は、大きな誤差範囲を設けつつも、指数関数的なケースは真剣に受け止める価値があると主張しています。生成側がそれほど速く上昇するのであれば、判断側もそれに合わせて上昇しなければなりません。そうでなければ、生成されるものと実際に検証されるものとのギャップは広がるばかりです。
イーサリアムが依存するシステムにとって、それが重要な部分です。エージェントを使用することで、手作業で行うよりもはるかに広い範囲をカバーできるようになります。その代わり、自信ありげな大量の請求に対して、より慎重な判断が求められます。判断こそが真のプロダクトであることを忘れない限り、それは行う価値のあるトレードオフです。