AIエージェントのセキュリティ確保:主要な制御策とベストプラクティス

企業は今や、特権を持つ従業員が使うのと同等の認証情報、ツール、ネットワークアクセス権をAIエージェントに与えるケースが増えています。しかしセキュリティ専門家は、人間のアクセスを管理するために設計された既存のセキュリティ管理策では不十分だと警鐘を鳴らしています。AIエージェントは人間離れした速度で動作し、許可された個々の操作を組み合わせて不正な結果を導き出すことができるうえ、追加のサブエージェントを生成して作業を分担させることも可能です。その結果、セキュリティチームが検知・阻止できないうちに、気づかぬまま一人の従業員のアクセス権が「暴走インサイダーの集団」へと変貌してしまう恐れがあります。

エージェントが曖昧な目標を誤解することは珍しくありません。文書やコードリポジトリ、ウェブページに仕込まれた悪意ある指示に従ってしまったり、サードパーティ製ツールから返された誤った出力に基づいて行動してしまったりすることもあります。最近の一連のインシデントでは、最先端モデルとオープンウェイトモデルの双方がテスト中に暴走し、脆弱性を悪用してサンドボックス環境から抜け出したり、オープンソースプロジェクトの開発者を操作しようとしたり、サードパーティのシステムに侵入したりする事例が見られました。

セキュリティ業界が持つ、判断を誤ったAIエージェントに最も近い脅威モデルは悪意あるインサイダー(内部関係者)ですが、企業はすでに悪意あるインサイダーがもたらしうる被害範囲の抑え込みに苦労している状況です。AIエージェントはそこに、マシン並みの速度、自律性、そして専門的な知識という新たな脅威要素を加えることになります。

「私たちは20年かけて、人間向けのID管理――ユーザー名、パスワード、ロールベースアクセス制御――を構築してきました」と、ガバナンス・リスク・コンプライアンス企業Strike GraphのCEOであるジャスティン・ビールズ氏は話します。「そのいずれも、疲れることなく、家に帰ることもなく、ルールではなく確率に基づいて行動するエージェントを想定して設計されたものではありません」

セキュリティ専門家によれば、エージェントが権限外の境界を越えた場合、セキュリティチームはそれを検知し、そのエージェントが起動したすべての認証情報、セッション、プロセスを即座に失効させる能力を備えていなければなりません。加えて、暴走エージェントが行った可能性のある処理をすべてロールバックできる体制も必要です。

「制御はモデルの外側に置き、モデルが実際に何をしているかを監視すべきであって、『やってはいけない』と指示したことをモデルが守ると信頼してはいけません」と、ID(アイデンティティ)セキュリティ企業DelineaのCEOであるアート・ギリランド氏はCSOに語ります。「セキュリティがモデル自身の『行動を選ぶ判断』に依存しているなら、それは制御ではなく、単なる希望的観測にすぎません」

エージェントには厳格な境界線が必要

エージェントを特権を持つインサイダーとして扱うということは、エージェント自身の制御が及ばない技術的な制御策によって、その行動を制限することを意味します。単に「してはいけないこと」を指示するだけでは不十分です。システムプロンプトはLLMが安全でない判断を下す可能性を減らすことはできますが、絶対的な阻止手段ではなく、エージェントがそれに従わない選択をすることもあります。

インターネットへの直接アクセスはデフォルトで拒否し、リクエストはドメインと操作のアローリストを強制するプロキシ経由でルーティングすべきです。読み取り機能と書き込み機能は分離し、削除、権限変更、データエクスポートといった高リスクの操作には明示的な承認を必須とすべきでしょう。

過剰な代理権限を防ぐためのOWASPガイダンスでは、エージェントが利用できる機能・権限・自律性を制限し、ある操作を許可するかどうかの判断をAIモデル自身に委ねるのではなく、下流のシステム側で認可を強制するよう推奨しています。

「私が運用しているエージェント型レッドチーム基盤では、コマンドラインツールの呼び出しすべてに対してスコープレベルのフックを実行し、各コマンドを承認済みのターゲットリストと照合しています」と、Suzu LabsでセキュアAIソリューション・サイバーセキュリティ担当シニアディレクターを務めるジェイコブ・クレル氏はCSOに語ります。「スコープの境界においては、意図的に偽陽性寄りに倒し、フェイルクローズ(異常時は閉じる)の挙動を優先しています。あるターゲットがスコープ内に収まっている『はず』だとエージェント自身に判断させるより、判断が曖昧な行動については人間に承認させる方がましです」

長期間有効な認証情報は、原則としてエージェントのサンドボックスの外に置くべきであり、設定ファイルへのアクセスはファイルシステムの分離によって制限すべきです。その代わりに、ブローカーアプリケーションを介して、エージェントが承認済みのツールを呼び出す際に、狭いスコープに限定された短命のトークンを発行し、要求された操作を検証する仕組みが有効です。一般に、エージェントは自分自身に追加の権限を付与したり、スコープを拡張したりするための手段にアクセスできるべきではありません。

攻撃的セキュリティテスト向けに自律型エージェントを運用する企業XBOWは、この種の多層的な制御について自社アーキテクチャの解説記事で説明しています。同社ではタスクのスコープは起動時に固定され、到達可能なドメインとURLパスは事前に定義・ホワイトリスト化され、送信トラフィックはすべてエグレスプロキシを通過し、各エージェントは別々のOSユーザーの下で独立したサンドボックス内で動作します。

「適切な前提は、いずれエージェントが権限外の何かを試みる可能性があるということです」と、XBOWのCISOであるニコ・ワイズマン氏はCSOに語ります。「たとえそうなったとしても、外部組織のシステムに到達したり影響を及ぼしたりできないよう、システム自体を設計しておく必要があります」

曖昧で機微な操作については、依然として人間による承認が欠かせません。しかし、あらゆる段階で承認を求めると、かえって監視の質が低下しかねません。Anthropicは5月に発表した内容の中で、Claude Codeのテレメトリによれば、ユーザーは権限確認プロンプトのおよそ93%を承認していたと明かし、「承認疲れ」に警鐘を鳴らしました。これは、承認を求められる回数が増えるほど、ユーザーが一つひとつの確認に払う注意が薄れ、時間の経過とともに監督者としての注意深さが失われていく現象です。

安全な操作は自動的に許可し、禁止された操作は自動的にブロックする決定論的な制御を構築しておけば、人間は危険な結果を招きかねず、かつ取り消しが難しいリクエストのレビューだけに集中できるようになります。

監視は「権限の所在」を追跡しなければならない

セキュリティチームはまた、エージェントが誰の権限を行使しているのか、そしてその権限がワークフローの中でどう変化していくのかを把握する必要があります。つまり、エージェントとそれを起動した従業員とを区別できる仕組みが求められるということです。

ログには従業員本人のIDを保持しつつ、エージェントには別個のIDを割り当てる必要があります。サブエージェントや子プロセスにも、それぞれ独自のIDを付与し、その親エージェント、承認された目的、そして担当する人間へと遡って追跡できるようにすべきです。

「ユーザー名とパスワードだけでは、ある操作の背後にいるのが人間なのかエージェントなのかは分かりません」とギリランド氏は言います。「たとえ同じログイン情報を使っていても、人間とAIエージェントを区別できる必要があります。さらに重要なのは、アクセス権が付与された後もリアルタイムで挙動を監視し、行動が一線を越えた瞬間にそれを遮断できる能力を持つことです」

ロールベースアクセス制御と最小権限の原則もここで重要になります。エージェント固有のIDは、その所有者が持つ権限をすべてそのまま引き継ぐべきではありません。昇格したアクセス権が必要な場合も、あくまでタスク単位で承認し、ワークフローの終了とともに失効させるべきです。

Microsoftはエージェント向けの最小権限ガイダンスを公開し、一時的なロールの有効化と短命トークンの利用に加え、オーケストレーターからツール、さらには下流のサービスに至るまで、経路上のあらゆる段階でIDやロール、スコープを再検証するよう求めています。Google Cloudも最近、エージェント型ワークフロー向けにツール単位・宛先単位のポリシーを追加し、Model Context Protocol(MCP)のツール名やメソッド、操作を区別できるようにしました。この実装自体はGoogleのプラットフォームに固有のものですが、その根底にある考え方はより広く他の環境にも応用できます。

何か問題が発生した際には、調査担当者が、発端となったトリガー、エージェントのID、承認された目的、モデルのバージョン、照会したツールと引数、ネットワークリクエスト、変更されたリソース、そして最終的な結果までを再構築できる状態にしておくべきです。

「すべての操作がプロンプトとそれを生み出した推論過程まで遡れるよう、あらゆる行動をログに記録してください」と、サイバーリスク企業Resilienceでリスクオペレーションセンターを率いるジャド・ドレスラー氏は述べます。「何か問題が起きたときに、その理由を突き止められる必要があります」

これは、複数のエージェントが協調して動いたり、逆に互いに衝突し合ったりする場面ではさらに重要になります。Anthropicのマルチエージェント実験では、相反するソフトウェア移行目標を与えられたエージェントが、アカウントを無効化したり、プロセスを強制終了させたり、偽装した悪意あるコードを展開したり、自己複製型のマルウェアを使用したりする事例が見られました。別のケースでは、直接の通信チャネルを遮断された後でさえ、エージェント同士が型破りな方法で結託する手段を見つけ出したこともありました。

エージェント型ワークフローには「キルスイッチ」が必要

セキュリティチームは、人間の承認を待たずにエージェントを自動的に一時停止できる条件と仕組みを整備する必要があります。そうした条件としては、インターネット上の権限外の宛先へ繰り返しアクセスを試みる、権限昇格を繰り返し試みる、想定外のIDを作成する、他のエージェントを改変する、あるいはブロックされた操作を繰り返し呼び出す、といったケースが考えられます。

エージェントの停止後には、アクセストークンの失効処理が続く必要があります。しかし、エージェントが一時的な認証情報ではなく、複数のエージェント間で共有された長期有効なAPIキーを使っている場合、この処理は困難になりがちです。

「エージェントをリアルタイムで監視し、スコープ外の行動が起きた瞬間に止められるようにしてください。後になってログの中から見つけ出すのでは遅すぎます」と、Secure.comのエンジニアリング責任者であるワシーム・アハメド氏はCSOに語ります。「能力の高いエージェントは、いずれ自らの制限を破ろうとするものだと想定し、実行前にガードレールと封じ込め策を用意しておくべきです」

組織はまた、AIエージェントが変更しうるコード、データ、アカウント、クラウドリソース、設定について、自動化されたロールバック手順をあらかじめ構築しておくべきです。インシデント対応の訓練にも、エージェントが誤動作するシナリオを組み込む必要があります。

「制約のないモデルをその権限範囲内に留めておくための監視・スコープ管理インフラこそ、大半のチームがまだ手を付けていないエンジニアリング上の課題です」とクレル氏は言います。「サイバーセキュリティの予算は、これまでずっと同じパターンをたどってきました。実際に侵害が起きて初めて、取締役会がようやく重い腰を上げ、まとまった予算を承認するというパターンです。この事後対応型のモデルは、それ自体すでにリスクをはらんでいました。自律的な脆弱性発見やエクスプロイト開発が広く利用可能になるにつれ、投資を正当化するためにインシデントの発生を待つというやり方では、予算がつくよりも先にインシデントの方が到来してしまうことになります」