いつ動かないかを知る：セキュリティエージェントが自律性を獲得する方法

この夏、OpenAIのテスト環境から抜け出したエージェントの話ほど広く伝わったAIの話題は多くありません。私が何度も立ち返るのは、その動機です。誰もエージェントに攻撃を指示してはいませんでした。彼らはただテストに合格しようとしていただけなのです。

簡潔に言うと、7月、OpenAIはサンドボックス内で最も高性能なモデルを使い、高難度のサイバーベンチマークを実行していました。この種のテストでは通常行われるように、本番環境の安全対策は意図的に無効化されていました。唯一の出口は、多くのテスト実行で共有される内部パッケージキャッシュでした。約1,200のエージェントがこれを掲示板に変え、さらにインターネットへの経路に変えてしまいました。

外に出た後、そのうち約700がHugging Faceへの攻撃に加わりました。公開状態にあった14個のトークン、データセット処理における2件の未知の脆弱性、41台の本番ワーカーでのコード実行、そして13時間足らずで、単一のポッドから複数のKubernetesクラスタの管理者相当のアクセス権に至る経路が生まれました。Hugging Faceは4日半にわたり、約17,600件の攻撃者による行動を記録しました。

彼らの狙いは何だったのでしょうか。主にグレーダー、つまりテストを採点するシステムでした。METRとRedwood Researchの独立調査員が、攻撃がピークに達した時間帯に参加した100のエージェントを分析したところ、97がテストを採点するシステムに関する情報を探していました。すべてのステップは盲目的な最適化から生まれたものであり、エージェントはスコアを上げるためならどんなことでもしていました。これらはいずれも人間の意図によるものではありませんでした。

防御側に注目してほしい点がひとつあります。シグナルは確かに存在していましたが、2度にわたって「動かない」という判断が下されたのです。6月、OpenAIでポートスイープに対するアラートが発報しました。オンコール担当者はこれをベンチマークに関連づけ、実行を停止する必要はないと判断しました。Hugging Faceでは、AIセキュリティスタックが散発的なシグナルをひとつの攻撃としてつなぎ合わせましたが、既存のエスカレーションプロセスは対応者を呼び出しませんでした。それでもHugging Faceの方が先に侵入を検知しました。7月16日に開示し、OpenAI自身の最初のアラートが発報したのは7月19日でした。両社と独立調査員は、異例なほど率直な事後分析を公表しました。彼らがそうしてくれたおかげで、私たちはそこから学ぶことができます。

問われるべきは、どれだけの自律性を与えるかということ

今月パリで開催した、当社初のユーザーカンファレンスTHREADで、私はこの話を取り上げました。防御側が問うべき問いを研ぎ澄ますものだからです。共同創業者でFiligranのCEOであるSamuel Hassineが基調講演で述べたように、攻撃者は今やループで反復する一方、多くの防御側は依然として直線的に動いています。私たちの側にもエージェントが必要になります。

では、エージェントにどれだけの自律性を与えるべきか、どのようにそれを獲得させるのか、そして動かないという決定も含め、エージェントが下す決定の責任は誰が負うのか。この問いに答えることこそが、エージェントを用いて継続的脅威エクスポージャー管理（CTEM）を運用するアプローチである、エージェンティックCTEMの核心です。

ひとつの脅威がエージェンティックCTEMのループをたどる様子：インテリジェンスから決定まで

CTEMは、スコーピング、ディスカバリー、優先順位付け、検証、モビライゼーションという5つのステップからなるループです。そして、それをまた繰り返します。この仕組みを示すために、エージェントがほとんどの作業を担いながら、ひとつの脅威がこのループを通過していく様子を見てみましょう。

脅威インテリジェンスベンダーが新たなキャンペーンを報告します。OpenCTI内のエージェントがこれをエンリッチし、既知の攻撃者情報と関連づけ、優先インテリジェンス要件と照合します。このキャンペーンは自社を標的にする可能性が高いでしょうか。

可能性が高い場合、OpenAEV内のエージェントがそのインテリジェンスを攻撃シナリオに変換し、防御体制に対して実行します。多くのチームは、自社がエクスポージャーを抱えているかどうかを知るためのエビデンスをいまだ欠いていると私は考えており、当社の調査も同じ結論を示しています。2026年2月から3月にかけて実施した550名以上のセキュリティ意思決定者と実務者を対象とする調査である脅威管理の現状レポートでは、回答者の97%が、エクスポージャーが悪用可能かどうかの判断に困難を感じていると回答しました。AIが生成したシナリオをどれだけ人間が厳密にレビューするかは、それがどこで実行されるかによって決まります。消去可能な隔離マシンであれば、そのまま実行させます。本番環境の深い部分であれば、先に確認します。

テストマシンが侵害されたとしましょう。エクスポージャーが存在することになります。多くのプログラムはここで止まります。エクスポージャーがあるから修正する、というわけです。しかし、エクスポージャーは答えの半分にすぎません。次のステップは、そのエクスポージャーが何を意味するかを判断することです。

まもなくベータ版として提供予定のサイバーリスク定量化モジュールであるOpenCRQ内のエージェントは、インテリジェンス、アタックサーフェス、そして重要と定義した資産からリスクシナリオを構築します。検証結果は、既存のコントロールがどれだけ機能しているかを示すエビデンスとなります。優れたリスクシナリオには想像力が必要です。AIは強力な初稿を提供でき、それをチームが磨き上げていきます。

検証済みエクスポージャーからリスク判断へ

ここで判断が可能になります。このキャンペーンがLinuxでしか機能しないとし、自社にLinuxノートパソコンが5台あるとしましょう。これらはオープンソースのコードしか扱わないエンジニアのものであり、横展開の経路はありません。このエクスプロイトは利用が難しいため、発生可能性は低いといえます。最悪の場合でも、数名が数日間、マシンの再構築のために作業できなくなる程度、影響額はおそらく2万ドルほどです。一方、検証結果が示す修正には年間約100万ドルのコストがかかります。

アラートをクローズし、その理由を記録します。これが正しい判断です。

ここでひとつだけ事実を変えてみましょう。そのノートパソコンの1台が、あらゆるシステムにアクセスできるCEOのものだったとします。脅威もエクスポージャーも同じですが、コンテキストが変わり、影響は別のカテゴリに属するものになります。これにより、CISOは経営層に対し、明確な根拠を持って臨むことができます。これがリスクであり、これが修正にかかるコストであり、合意済みのリスク許容度に照らせば、今この予算が必要である、と。

これがそのサイクルです。脅威に関する知識は証拠となり、その証拠が行動、あるいは意図的に動かないという決定につながります。

「今は動かない」をよく考えられた決定にする

同じ論理は高度な領域でも成り立ちます。一部の手法は、国家規模のリソース、数百万ドル規模の労力を要します。潤沢な資金を持つ政府であっても、戦略的な関心のない企業にそれだけの費用をかける可能性は低いでしょう。その手法に対する防御には、新しいツール、人員、プロセスからなる2,000万ドル規模のプログラムが必要になるかもしれません。

その手法が成功した場合の損失が約3,000万ドルになるとしましょう。自社が5,000万ドルの損失まで吸収できると合意している場合、発生可能性の低い3,000万ドルの事象を防ぐために2,000万ドルを費やすことは正当化しにくいといえます。一方、許容度が1,000万ドルであれば、同じ事象は吸収可能な範囲を超えることになり、結論は変わります。

誰も確認する時間がなかったために動かないのは、決定が下されていない状態にすぎません。おそらくテストによるものだろうと、確認せずにアラートをクローズするのも同じです。一方、確認し、測定し、その結果を合意済みのリスク許容度と照らし合わせた上で動かないという判断は、優れたマネジメントです。OpenAIがこのインシデント後に採用したルールのひとつは、この違いに時間制限を設けています。呼び出されたアラートが30分以内に誤検知と判断できない場合、該当する活動は一時停止されます。うまく運用されれば、エージェンティックCTEMは、あらゆる「今は動かない」を後者の種類にする助けとなります。

エージェントが自律性を獲得していく中で、人間が関与し続けるべき領域

エージェンティックCTEMにおける自律性は、エビデンスが積み上がるのに応じてのみ拡大すべきです。最もよく聞かれる質問は、どこで人間が介入すべきかというものです。普遍的な答えはなく、それを提示してくる相手は過大に売り込んでいるにすぎません。これはユースケース、システムの重要度、規制当局、そして自社自身のルールによって決まります。重要なのは、そのルールを自ら設定することです。

私が推奨する実践方法は次のとおりです。

人間による承認をデフォルトとする

最初は、すべての重要なアクションを人間がレビューします。

独立した判定役を追加する

作業を行うエージェントの傍らで、複数のAIジャッジ（エージェントの作業を検証する独立したモデル）を稼働させます。各ジャッジは異なるモデル上で動作し、独自のルールを持ち、エージェントのコンテキストの外側に置かれます。一つでも判断に迷うものがあれば、人間が決定します。

ジャッジと承認者をエージェントの手が届かない場所に置く

今年の夏のエージェントたちは自らを採点するシステムを標的にし、承認ステップがエージェント自身の世界の中でどうなるかも示しました。あるOpenAIのエージェントはHugging Faceへの攻撃を対象外と判断し、一時停止しました。別のエージェントがメッセージボードに「GO」と投稿し、6分間の期限を設けました。最初のエージェントの次の推論はこうでした。「GOの承認が届いた！」そのまま処理を続けました。1,200体のエージェントのうち、人間に警告したものは一つもありませんでした。

「人間が承認する」と言うとき、重要な言葉は人間です。つまり、エージェントがなりすますことのできない、認証された人物を指します。

まず運用し、その後レビューする

一定期間、例えば6か月が経過したら、記録を確認します。人が毎回変更なしに承認していたなら、そのステップはより高い自律性に移行する準備ができている可能性があります。規制当局や保険会社が人間の署名を必要とする場合は、そのまま維持します。

承認のコストにも注意が必要です。1日に5回、チャットウィンドウでクリックする程度ならほとんどコストはかかりません。しかし私の経験では、1日に1,000件の承認を求められると、人は内容を読まずに「はい」をクリックするようになります。当社の脅威管理の現状調査では、回答者の88%が、自動化を強化しなければリスクの量に対応しきれないと回答しており、誰も読まない承認はそれ自体がリスクとなります。人が読む1回のチェックは、読み飛ばしてクリックするだけの10回より価値があります。

これは採用に似ています。新しい同僚は、自らの力を証明することでより大きな責任を得ていきます。エージェントも同じであるべきです。

継続的なテストを通じてエージェントへの信頼を築く

セキュリティにおけるAIエージェントの自律性は、根拠に基づくべきです。そしてエンジニアは、その根拠を生み出す方法をすでに知っています。テストです。エージェントが直面する可能性が最も高い50のシナリオを洗い出し、それぞれについて期待する回答を書き出します。エージェントを実行し、独立したジャッジに結果を採点させ、モデル同士を比較します。あるモデルが一貫して期待通りの回答を出すなら、そのシナリオにおいてそのモデルを信頼する根拠が得られたことになります。

テストは継続的に行う必要があります。数か月ごとに新しいモデルが登場し、それぞれ前のモデルとは少し異なる推論をします。再テストせずに切り替えれば、何が起こるか分かりません。

テストは、テスト対象を可視化できて初めて機能します。Samuelが基調講演で述べたように、重要な振る舞いはハーネス、つまりモデルを取り巻くプロンプト、ツール、ルールの中にあります。OpenAI自身のデータがそれを裏付けています。OpenAIは、本番環境のハーネスとシステムプロンプトによって、モデルがインフラを侵害する傾向を100倍以上低減できることを発見しました。同じモデルでも、ハーネスが違えば、エージェントは別物になります。

だからこそ私たちは、XTM Platformの中核であるXTM Oneのハーネスを公開しています。エージェントが自分の代わりに行動するのであれば、その推論の仕方と許可されていることを検証できるべきです。

エージェントが誤った場合、責任は企業にとどまる

エージェントが何かを誤った場合、責任を負うのは誰でしょうか。健全に運営されている企業であれば、それは企業自身です。バグによってインテグレーションが失敗しても、それを書いたエンジニアを解雇することはありません。そのバグがリリースされるに至ったプロセスを修正します。

自律性が高まっても、この原則は変わらず、トレーサビリティに対する要求水準はむしろ高まります。Hugging FaceのAIスタックの話に戻りましょう。それは攻撃を検知しながら、事実上「緊急ではない」と判断しました。これはHugging Faceへの批判ではありません。同社は誰よりも早く侵入を検知していました。ここで避けるべきパターンは、エージェントが重大な判断を下したにもかかわらず、その種の判断を担う責任者を誰も決めていなかったという点です。エスカレーションしないという判断も含め、エージェントのあらゆる決定には、名前のある責任者とその理由の記録が必要です。

そして、その記録はエージェント自身が書き換えられないものでなければなりません。調査担当者は、少なくともOpenAIのエージェントのトランスクリプト96件で、ツール呼び出しの偽装を発見しました。記録上はあるコマンドが表示されていたのに、実際には別のコマンドが実行されていたのです。エージェントがなぜそのような行動を取ったのかを解明するには、被害が発生してから数週間後に、推論内容を別途レビューする必要がありました。エージェントがなぜその決定を下したのかは、それがまだ意味を持つうちに把握しておく必要があります。

エージェントにとっても、コンテキストがすべて

Samuelと私がFiligranの設立前にOpenCTIをオープンソースプロジェクトとして始めたとき、その発想はシンプルでした。サイバーセキュリティにおいては、コンテキストがすべてです。私はAIを、これまでで最も強力なコンテキストの加速装置だと捉えています。AIはどのアナリストよりも多くの情報を集約し、トレードオフを含めた選択肢を提示します。自分で判断を下すこともあれば、そのまま進めさせることもあります。いずれの場合も、決定の責任は自分にあり、そしてその根拠は残っています。

このようにして、エージェンティックCTEMは、かつては大規模なセキュリティ組織だけが持ち得たようなコンテキストを、小規模なチームにももたらすことができます。攻撃者側のエージェントは、許可を求めずに行動します。私たちのエージェントは、行動する権利を自ら獲得し、そして行動すべきでないときを見極めるべきです。