セキュリティリーダーの大多数(92%)は、AIエージェントの利用拡大が新たなセキュリティリスクを生み出すことを懸念しています。それには十分な理由があります。AIエージェントは今や、Hugging Faceの事例が示すように、驚くほど短時間で攻撃チェーン全体を実行できるのです。
AIエージェントはHugging Faceの本番環境に侵入し、わずか4日強の間に17,600件のアクションを実行しました。また別のラボテストでは、AIエージェントがわずか40分でドメイン管理者権限を完全に掌握しています。
これまで人間なら数日がかりだったこの種の攻撃が、AIによって人手を介さず自律的かつエンドツーエンドで実行されるようになりました。この結果、備えのないセキュリティチームは大きなプレッシャーにさらされ、対応の遅れを埋められない状況に陥っています。
見慣れた攻撃手法の裏に潜む、未知の攻撃パターン
Hugging Faceへの侵入事件に目新しさを求めても、拍子抜けするでしょう。コード実行、認証情報の窃取、横方向移動、データ流出への防御策は、セキュリティチームがこれまでも講じてきたものだからです。違いは、それを「誰が」実行するかにあります。AIエージェントは目標に向かって作業を進め、その目標を達成する過程で複数の経路を並行してたどることができます。ある試みが失敗しても、そこから学習し、指示や監督なしに自らアプローチを調整していきます。
Hugging Faceの侵害事件は、これが実際にどう機能するかを如実に示しています。AIエージェントは内部データを読み取り、クラウドおよびクラスタの認証情報を入手しました。そしてこれを使って内部サービスにアクセスし、ソースコードへの限定的な書き込み権限を獲得しました。エージェントは最初の試行で的を射る必要はありませんでした。さまざまな経路やアプローチを試し、失敗したものから学習できたのです。こうしてエージェントは、最も成功しそうな単一の攻撃チェーンを組み上げていきました。
AIモデルの真のリスクが、その「推論能力」といった抽象的な部分にあると考えるのは誤りです。実際のリスクは、そのモデルがアクセスできる権限、システム、認証情報、ツール、ネットワークにこそあります。
セキュリティが機能不全に陥る3つの領域
Hugging Faceの事例を通してAIエージェントによる攻撃を追跡すると、単一の対策が機能しなかったという話ではないことがわかります。この攻撃が露呈させたのは、3つの具体的な弱点でした。
アイデンティティ: 多くの企業は、依然として旧来型の手法でAIエージェントを管理しています。ソフトウェアの追跡と同様、ライセンスやデプロイチケットで管理されるアプリケーションのように扱っているのです。しかし、プライベートデータを読み取り、ツールを呼び出し、自律的にタスクを開始できるエージェントは、単なるソフトウェアではありません。そのようなアクセス権は、担当者が明確に割り当てられ、権限の範囲が定義され、いつでも取り消せる仕組みがなければ、新入社員にすら与えられないはずのものです。
対応: Hugging Faceのチームは、侵入によって生成された悪意あるコマンドやトラフィックそのものを分析しようとしました。彼らは商用AIモデルに助けを求めましたが、モデルはこれを拒否しました。共有された情報が実際のマルウェアとあまりにも酷似していたため、AIモデルがこのリクエストを攻撃とみなしてしまったのです。そのため、チームは迅速に答えを必要としているにもかかわらず立ち往生することになりました。結局、そうした制限のないセルフホスト型モデルに切り替えることで対処しましたが、これがうまくいったのは、たまたまチームにその選択肢が用意されていたからに過ぎません。
エスカレーション: ここには非常に大きなギャップがありました。Hugging Faceのセキュリティスタックは、複数の曖昧なシグナルを正しく相関させ、攻撃の全体像を統一的に把握していました。しかしエスカレーションが遅く、そのため結果は変わりませんでした。検知は的確だったものの、エスカレーションが伴っていなかったのです。攻撃者が次の目標に到達する前に行動を起こすための、事前承認された権限が欠けていました。
ギャップを埋めるために
これらのギャップは、次の攻撃がどのようなものになるかを予測するものではありません。むしろ、すでに実際に起きたことへの備えを求めるものです。
アイデンティティの強化: すべてのエージェントは特権アカウントとして扱うべきです。ビジネス上の責任者を定め、その権限が実際のタスクに見合ったものになっているか確認する必要があります。短命な認証情報を使用し、セキュリティチームが実際に照会できる監査証跡を残してください。また、不審な兆候が見られた場合に即座にアクセスを取り消せる仕組みも用意すべきです。同様の規律は、その周辺のインフラにも及ぼす必要があります。具体的には、不要なワークロードからクラウドのメタデータへのアクセスを遮断し、環境ごとにサービスIDを分離することです。
対応態勢の整備: 障害モードは、インシデント発生後ではなく発生前にテストしておく必要があります。これにより、チームが実際の悪意あるアーティファクトを安全かつ迅速に調査できるか、そしてその分析をどこで行うかを確認できます。また、正当な防御目的のタスクをモデルが拒否した場合に備え、承認済みの代替手段も用意しておくべきです。これはセルフホスト型モデルでもよいですし、一部のAIプロバイダーが防御側向けに提供し始めている検証済みアクセスプログラムでも構いません。
権限の是正: Hugging Faceの侵入事件において、アラート自体は問題ではありませんでした。同社のセキュリティスタックは、そのパターンをオンコールチームを呼び出すほど深刻だとは判断しなかったのです。ここでの解決策は、ネットワーク、アイデンティティ、エンドポイント、アプリケーション、データといった複数のソースから証拠を集約し、単一の相関ビューにまとめることです。さらに、特定のパターンに対して明確なエスカレーションルールを割り当て、それぞれに事前承認済みの封じ込め策を紐づける必要があります。こうしたギャップを埋めるアプローチは、セキュリティチームがすでに特権アクセス、封じ込め、事業継続性に対して適用している規律と同じものに根ざしています。しかし今後は、これを監視する側よりも速く動き、さらに速く適応する脅威アクターにも対応できるよう拡張していく必要があります。
