17,600 アクション: エージェントのセキュリティはシステムの問題です

OpenAIとHugging Faceの件は誰もが話題にしているが、私は当初、Dockerが何か付け加えるべきことがあるのか懐疑的だった。数週間にわたる顧客との対話を経て、私たちはそうすべきだと考えています。有益な教訓は、AIエージェントがサンドボックスから脱出したということではない。これは、17、600の行動が人間のテンポに合わせて設計されたセキュリティシステムについて明らかにするものです。

Hugging Faceは、7月に行われた4日半のキャンペーンにおいて、約17,600件の攻撃者の行動を再構築しました。これには、約2日半にわたる同社のインフラストラクチャ内部での活動が含まれます。

各作業に対して30秒間の人間によるレビューを行うと、147時間の作業時間になります。Hugging Face はこれらのアクションを大まかに 6、280 のグループに分類しました。それらのグループだけをレビューしても、52 時間以上かかります。いずれにせよ、手動承認や通常の警告トリアージは、この作業負荷に対する適切な主要な制御策とはなり得なかった。

これは根本的に新しいタイプの攻撃ではなかった。インシデント対応の経験がある方なら、その手順はよくご存知でしょう。到達可能なサービスを悪用し、コード実行権限を取得し、認証情報を収集し、権限を昇格させ、次の信頼境界を越える、という流れです。

異なっていたのは、短期間の環境下でも権威と国家を維持する速度、持続性、そして能力だった。エージェントは、障害が発生した場合でも、ツールを再構築し、通信チャネルを復旧させ、キャンペーンを最初からやり直すことなく、別の環境から作戦を継続できる。有用なメンタルモデルは、ファジングツールと融合した有能な攻撃者です。それぞれの結果について推論し、疲労することなく調査を続けることができます。それがこの話のAIに関する部分です。

これはモデルの整合性に関する解説ではなく、あなたやあなたの組織がどのモデルやエージェントフレームワークを使用すべきかについて、ここで意見を述べるつもりはありません。セキュリティ上の問題はよく知られている。コードを実行し、認証情報を保持し、ネットワークにアクセスし、人間ならテストを中止するであろう後もテストパスを継続できるワークロードに、どのような権限を与えるべきか？

何が起こったのか

OpenAIは、脆弱性を発見して悪用することをエージェントに課す「ExploitGym」と呼ばれるベンチマークを用いて、社内でサイバー能力の評価を実施していた。この評価では、拒否動作を減らし、通常展開されるモデルが持つような実運用レベルの分類器は一切使用しなかった。

エージェントたちはインターネットに直接アクセスできなかった。彼らは、社内ホスト型のパッケージレジストリキャッシュを介してパッケージをインストールすることが許可されていた。捜査官らは、許可されたサービスにこれまで知られていなかった脆弱性を発見し、それを利用してインターネットにアクセスした。

許可されたサービスは、避難経路だった。それがこの事件の重要な点だ。

そこから、エージェントはOpenAIの研究環境内で権限を昇格させ、外部サンドボックス上で動作するユーザーがホストするCyberGymスタイルのコード実行ハーネスに到達し、そのハーネス内でroot権限を取得した。サンドボックスプラットフォーム自体は侵害されていませんでした。どうやらハギングフェイスがベンチマークの参考解答を掲載している可能性があると突き止めた捜査官たちは、不正行為が合格点を得るための最短ルートだと判断して、ハギングフェイスに直接攻撃を仕掛けた。

Hugging Faceによる再構築では、ローカルファイルの漏洩、テンプレートエンジンを介したコード実行、クラウドメタデータへのアクセス、Kubernetesの権限昇格、136個のキーを含む本番環境の秘密情報の漏洩、盗まれた認証情報による企業ネットワークへのアクセス、およびソース管理への限定的な書き込みアクセスが記録されています。調査の結果、公開されているモデル、データセット、パッケージ、またはリリース済みのソフトウェアが改変された証拠は見つからず、アクセスされた顧客コンテンツは、ごく少数のベンチマーク関連のデータセットに限られていた。それは、起こり得た可能性と比較すれば、良い結果だ。それは、攻撃経路が無害であったという証拠にはならない。

個々の脆弱性は既知のものであった。すなわち、安全でない処理経路、アクセス可能なクラウドメタデータ、広範な権限、長期にわたる認証情報、そして共有された管理者IDである。有能な人間であれば、彼らを鎖で繋ぐこともできたはずだ。違いは、テストされた経路の量、失敗した経路が置き換えられるスピード、そしてキャンペーンが続く中で防御側が解釈しなければならなかった証拠の量だった。

詳細な経過を知りたい場合は、Hugging Faceが詳細な技術解説とインタラクティブなリプレイを公開しています。どちらも読む価値がある。

これには制御が必要です

攻撃の斬新さではなく、その計算方法こそが運用モデルを変えるのだ。人間は、機械の速度で何千もの動作を制御ループ内で実行し続けることはできない。

考慮すべき関連する脅威モデルが2つ存在する。

最初のケースでは、エージェントが自ら経路を発見し、それを活用する。今回の事件でエージェントが行ったように。2つ目のケースでは、外部の主体が、悪意のあるツール、侵害された依存関係、悪意のある文書、プロンプトの注入、または攻撃者が制御するデータを通じて、エージェントをリダイレクトします。その場合、エージェントが攻撃ベクトルとなる。

どちらの場合も、同じ権威は危険である。したがって、制御システムは、環境に何が導入されるか、エージェントがどのような能力を受け取るか、そしてエージェントの行動が想定される境界を超えた場合に何が起こるかを制御する必要がある。

重要なのは、あらゆる行動の前に人間の承認を求めることではない。それはエージェントを利用するメリットの多くを損ない、最終的には承認疲れを引き起こす。定型的で可逆的な動作は、ほとんど摩擦を伴わないべきである。より敏感な、外部的な、破壊的な、あるいは異常な行動は、より厳格な精査を受けるべきである。

特に外部データがコマンドになり得るパッケージ、ツール、パスに関しては、レビューとサニタイズが依然として重要である。しかし、消毒だけでは迅速な注射への確実な解決策とはならない。自然言語コンテンツは曖昧さが多すぎるため、悪意のある部分を常に特定して削除できるとは限りません。より強固な境界はアーキテクチャ上のものです。信頼できないコンテンツは、自身に権限を付与したり、ポリシーを変更したり、エージェントが既に持っていない機能を作成したりすることができてはいけません。

適切に実施されれば、ガバナンスはエージェントの自律性を制限するものではない。それが、エージェントに安全にさらに多くの量を投与することを可能にするのです。

Dockerが現在適用できる範囲と、適用できない範囲

私たちは、エージェントベースラインの創設開発者であることを誇りに思っています。私たちは他の業界専門家と協力して、問題を「発見」「制約」「承認」「観察」「検証」「対応」という6つの成果に集約しました。

Docker Sandbox が特定のカテゴリに分類されるとすれば、それは「制約」ですが、実際には、それらは基盤となるものであり、6 つのカテゴリすべてを計測または実装する場所だと考えています。それらは各エージェントに専用のマイクロVMと、ローカルコンピューティング、ファイルシステムへのアクセス、ネットワーク範囲に関する強制可能な境界を与え、さらに監視対象の基本層（つまり真実の層）を提供する。それは実に有用なレイヤーだ。

Docker AI Governanceは、組織がエージェント環境に関する制御（ネットワークおよびファイルシステムのポリシー、MCPサーバーおよびツールへのアクセスなど）を一元的に定義および適用できるようにすることで、承認と監視の一部に対応します。

サンドボックスとAIガバナンスを組み合わせることで、今日の課題に対する重要な解決策の一部、すなわち、強化された実行環境と、その環境を中心とした一元的なポリシー適用が実現する。エージェントがアクセスを許可されている脆弱なサービスを修復したり、他のシステムによって発行された認証情報を狭めたり、顧客自身のセキュリティアーキテクチャを置き換えたりするものではありません。Dockerを含め、どのベンダーも、自社の技術があれば今回の事件を未然に防げたと主張することはできない。

しかし、決定論的な執行境界は依然として必要である。これにより、組織は最小限の権限と最小限の権限を適用できる場所を1か所に絞り込むことができ、エージェントが実際に何を実行できたかを監視できる場所も1か所に確保できる。エージェントがパッケージレジストリではなく、エグレスプロキシとしてパッケージレジストリを使用している場合、特にリクエストを1つずつではなく、一連のリクエストにわたって表示する場合、テレメトリによってそのような差異を明らかにする必要がある。

より広範な問題は依然として困難である。観察の有用な単位は、必ずしも1回のツール呼び出しとは限らない。それは、活動の急増、標的、プロトコル、認証情報、あるいはシステム間でのみ確認できるパターンである可能性がある。荷物の受け取り依頼はごく普通のことです。その背後にあるサービスを繰り返し調査し、認証情報を発見し、それを使って別のシステムにアクセスすることで、評価は変わるはずだ。

それが、基本的な封じ込めを超えた、エージェントセキュリティにおける課題です。権限を制限する必要がある一方で、適切な粒度で活動を監視し、より詳細な調査が必要な時期を認識し、行為者と同じペースで対応する必要がある。Dockerを含め、私たち全員にとって、監視、検証、対応の面で、まだまだ多くの課題が残されています。

運用上のトレードオフ

セキュリティ、能力、自律性はすべて重要であり、それらは常に緊張関係にある。言い換えれば、これらはどれも無料ではない。

有効期限の短い認証情報は、長時間実行されるタスク中に期限切れになります。制限的なリリースポリシーは、正当なパッケージのインストールを阻害します。開発者が動作すると想定していたツールは、アクセス制御によって拒否されます。複数システムにわたる検出は費用がかかり、誤検出も発生する。書き込み承認を誤った場所に挿入すると、エージェントが提供するはずだった生産性の大部分が失われてしまう可能性があります。

チームは、エージェントが再び正常に動作するまで、あらゆる制御を緩めたくなるだろう。それは理解できます。厳格な方針によって生じる失敗は即座に顕在化するが、過剰な権限によって生じる失敗は、何らかの事態が発生するまで目に見えないままとなる。

解決策は、管理機能をなくしたり、すべてを人間が承認するようにしたりすることではありません。それは、摩擦を結果に比例させ、故障モードをテストし、運用コストを測定し、それをリスクと潜在的な爆発半径と比較検討することである。

私の仕事のやり方

私は毎日エージェントを使用していますが、十分に能力の高いエージェントであれば、いずれは私が予想していなかったことを試みるだろうと考えています（おそらく毎日…）。

ほとんどの場合、私はあらゆるものにアクセスできる汎用エージェントを1つだけ運用しているわけではありません。私はタスクに特化したエージェントを使用しており、それぞれが個別のキットとしてパッケージ化され、無料のDocker強化イメージをベースに構築され、Dockerサンドボックス内で実行されます。

各キットは特定の作業から始まり、その作業に必要なソフトウェア、ネットワークアクセス、ファイル、認証情報、および外部機能のみを受け取ります。

ほとんどの場合、エージェントはサンドボックス内ではほとんど制約を受けない。それは意図的なものです。重要なのは、サンドボックス内でのゴッドモードが、私のノートパソコン、私の認証情報、あるいは私がアクセスできるすべてのサービスに対するゴッドモードにならないようにすることだ。

私は机上調査をよく行います。これらのエージェントは、オープンインターネットにアクセスできる。できないなら、それらは役に立たない。しかし、彼らのイメージにはコンパイラ、パッケージマネージャ、汎用ネットワークデバッグツール、開発ツールチェーンは含まれておらず、意図的に制限されたシステム権限で実行される。彼らは公開情報を取得・分析することはできるが、遭遇した情報を悪用したり、他のシステムに対して何らかの行動を起こしたりするための手段はほとんど持ち合わせていない。彼らが私のソースコードや本番環境の認証情報を保持する理由は何もない。

私の本番環境のコーディングエージェントは、はるかに豊かな環境を備えています。Raspberry Piが動作し、複数のモデルを使用でき、コードをコンパイルし、テストを実行し、実際のエンジニアリング作業に必要なツールを使用できます。そのネットワークアクセスは、私が使用するDocker、GitHub、Snowflake、Cloudflareなどのサービスを明示的に許可したリストに限定されています。コーディング作業で時折ネットワークが必要になるからといって、インターネットへのアクセス権やツールを無条件に付与されるわけではない。

私のホームキットはArduinoと通信できますが、ホストやデバイスに直接アクセスすることはできません。ホスト側のMCPサーバーは、許可された操作を仲介します。エージェントはそのインターフェースを通じて、定義されたArduinoの機能を要求することはできますが、その許可を、マシンに接続されているすべてのデバイスへの一般的なアクセス権に変換することはできません。

私の開発キットは、実験を行う場所です。バランスの取れたネットワークアクセスで動作しますが、ホストの機密情報は共有されず、ホストファイルへの無制限のアクセスも許可されません。Google Workspace、Snowflake、またはその他のホストサービスが必要な場合、ホスト側のデーモンがそれらの呼び出しを仲介します。エージェントは、私が公開することを選択した機能のみを認識し、基となる認証情報やその他のサービスの内容は認識しません。これらのブローカーは、どの操作が許可され、どの操作がブロックされるかを強制的に実行できる。

これらは意図的に異なる環境である。その研究エージェントは、本番環境でのコーディング能力が低いだろう。コーディングエージェントは、リサーチエージェントがアクセスできるすべてのサイトにアクセスできるわけではない。ホームエージェントは、Arduinoの操作を任意のホストアクセスに変換することはできません。開発エージェントは、クエリを承認する認証情報を持っていなくても、サービスに対してクエリを実行できます。

その制約こそが特徴なのだ。

結論：エージェントのスピードでセキュリティを実現する

OpenAI/Hugging Face事件は、単一の境界の欠陥によるものではなかった。それは一見合理的に見える権限の連鎖と、おなじみの脆弱性だったが、エージェントが何千もの経路をテストし、実行間で状態を保持し、あるシステムから次のシステムへと権限を引き継ぐことができるようになると、全く異なるものへと変貌した。

エージェントが発見する可能性のあるすべての脆弱性や、エージェントが我々が与えたアクセス権限をどのように組み合わせるかを、我々はすべて予測することはできません。このアーキテクチャは、エージェントの完璧な動作、完璧なソフトウェア、あるいは人間がすべての危険な行動をタイムリーに察知することに依存することはできない。

つまり、出発点は依然として最小限の機能と最小限の権限である。エージェントには、そのタスクに必要な最小限のインターフェース、認証情報、ツール、およびネットワークアクセスのみを与える。それらの制御を、決定論的な適用境界に設定する。結果として生じる活動を、個々のリクエストとしてだけでなく、システム全体にわたるシーケンスやパターンとしても観測可能にする。挙動が想定範囲を超えた場合、エージェントの速度で封じ込めを行う必要がある。

Docker SandboxesとDocker AI Governanceは、現在、そのアーキテクチャの重要な要素、すなわち、厳格な実行境界と、それらに関する一元的に適用されるポリシーを提供しています。これらは、エージェントが連絡を許可されているすべてのサービスを保護するものではなく、組織が各エージェントにどのような権限を与えるべきかを決定する必要性をなくすものでもありません。発見、制約、承認、監視、検証、応答といった幅広い作業に関わることが、そもそも私たちがエージェントベースラインの作成を支援した理由です。

目標は、決して間違ったことを試みないエージェントを作ることではない。目標は、間違ったことを試したからといって、それが他のすべてへの鍵となるような事態にならないシステムを構築することです。