なぜエージェント・ゲートウェイをAIエージェント保護の第一層にしてはならないのか？

企業向けAIプラットフォームとセキュリティの専門家であるNik Kaleは、多くの組織がエージェント運用ゲートウェイを主要な制御ポイントとみなしてそこから始める一方で、こうしたゲートウェイは、十分に整備または成熟していないアイデンティティと帰属の層に依存していると指摘する。その結果、ゲートウェイはトークンとAPIリクエストの有効性を確認できても、どのエージェントがリクエストを実行したのか、誰がそのエージェントに委任したのか、どのタスクを実行していたのか、あるいはそのリクエストが信頼できないコンポーネントによって開始されたツール連鎖の一部だったのかを、常に把握できるとは限らない。

エージェントの導入が拡大するにつれて、この問題は実務上の重要性を増している。6月、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、実際に悪用されていることが確認された後、LiteLLMの脆弱性を既知の悪用された脆弱性カタログに追加した。この脆弱性により、ゲートウェイ自体を介してホスト上でコマンドを実行できた。また、別の脆弱性と組み合わせることで、認証情報なしに悪用することも可能だった。情報源によれば、このゲートウェイでは1か月の間に7件の共通脆弱性（CVE）が公表された。

ここでのセキュリティは単一の制御ポイントではなく、信頼の連鎖である

Kaleは「信頼に基づくデプロイ」と呼ぶ考え方を提案している。つまり、先行する層に必要なテストを通過するまで、後続の層を運用上完成したものとみなさないということである。制御策は並行して開発できるが、本番環境で有効化する際には、明確な順序に従うべきである。

エージェントの棚卸しと責任ある所有権：本番環境の各エージェントには、既知の所有者、明確な目的、承認済みのツール、ライフサイクル上の状態が必要である。
独立したアイデンティティと委任コンテキスト：システムは、エージェント、その所有者、そしてエージェントが誰またはどの組織の代理として業務を実行しているのかを把握すべきである。
短期かつタスク限定の認証情報：侵害されたエージェントが、委任されたタスクに関係のないリソースへアクセスできないようにしなければならない。
帰属可能な計測：タスクの開始から他のシステムへの最終的な影響まで、タスクを再構成できるようにすべきである。
実行時の措置の強制：ポリシーの判断は、トークンの有効性だけでなく、エージェントのアイデンティティ、委任者、タスク、アクションに基づくべきである。
行動ベースラインとシステム横断型の停止経路：セキュリティチームは、エージェントがアクセスするすべての場所で、その実効権限を停止できなければならない。

定義と帰属が可能なものから始める

提案されたフレームワークによれば、最初のステップは、オープンソースのフレームワーク、クラウドサービス、SaaS製品、開発者ツール内に存在する本番エージェントを把握することである。台帳には、エージェントの所有者、責任、ライフサイクルの段階、許可されたツール、データ範囲、認証情報の出所を含める。こうした棚卸しの欠如は、単なる文書化上の問題ではない。組織があらかじめ把握しているはずの元を特定しようとして、インシデント対応の時間の一部を費やす可能性があるからだ。

筆者は、エージェントのアイデンティティを開発者のコード、共有サービスアカウント、またはユーザーセッションの内部に埋め込むべきではないと強調する。呼び出し元が「エージェント」であると知るだけでは不十分である。誰がその業務を委任したのか、具体的なタスクは何か、エージェントが使用する必要のあるリソースは何かも記録しなければならない。アイデンティティは行為者を特定し、委任はエージェントが誰の権限で行動しているのか、またなぜその権限が付与されたのかを明らかにする。

行動を分析する前に権限を縮小する

エージェントのアイデンティティを特定した後は、その能力を、時間、タスク、必要なツール、必要なリソースに応じて制限すべきである。情報源は、ワークロード・アイデンティティ、トークン交換、条件付きアクセス、期間限定の資格など、既存のID・アクセス管理（IAM）システムの機能を活用できると指摘している。

Kaleは、205人のセキュリティ責任者を対象にしたTeleportの2026年の調査を引用している。過剰な権限を持つAIを使用している組織では、インシデント率が76%だったのに対し、最小権限の原則を適用している組織では17%だった。彼の分析によれば、これはアクセス範囲が、コンテキストを認識した実行時ポリシーの強制よりも、信頼の連鎖における先行要因である可能性を示している。

筆者が提示する原則は「単調な委任」である。責任が移るたびに、権限は維持または縮小されなければならず、増加してはならない。金融決済エージェントの例では、これは依頼者である従業員がアクセスできるすべてのシステムを継承させるのではなく、特定の台帳を閲覧する権限だけを与えることを意味する。

ゲートウェイが本当に有用になるのはいつか？

運用ゲートウェイがその価値を十分に発揮するのは、登録されたエージェントのアイデンティティ、明示的な委任コンテキスト、限定された認証情報、帰属可能なログが整った後である。その時点で、特定の主体のために、特定のタスクの範囲内で、特定のリソースに対して、エージェントが特定のアクションを実行する権限を持つかどうかを評価できる。ユーザートークンは決済エージェントに書き込み権限を与えるうえで有効かもしれないが、完全なコンテキストによって、そのアクションがタスクの範囲外であることが明らかになる場合もある。

最も厳格な制御は、支払い、アクセス・ポリシーの変更、削除、本番環境の変更、データのエクスポートなど、影響を元に戻すことが難しい境界に適用すべきである。行動ベースラインはその後に来る。エージェントの活動が識別・帰属可能になって初めて、ツールの通常ではない利用、データ範囲間での予期しないアクセス、タスクからの逸脱を検知できるからである。

停止経路は、アイデンティティディレクトリ内の単一オブジェクトを無効化するだけにとどまらない。情報源が説明する完全な停止には、エージェントのアイデンティティの無効化、アクティブおよび派生した認証情報の失効、ツールの実行阻止、進行中のタスクの終了、エージェントを含むワークロードの隔離が必要である。

30日間のテスト計画

筆者は、既存のアイデンティティ管理プログラムを置き換えることを提案しているわけではない。アイデンティティ・プロバイダーがエージェントをネイティブな資産種別として扱っていない場合は、既存のワークロード・アイデンティティに紐付けた信頼できる台帳から始め、エージェントIDとタスクIDを信頼できる実行コンテキストとして追加し、短期認証情報を使用し、ツール呼び出しログにこれらの識別子を含めればよい。

実務上は、10体の本番エージェントから始め、それぞれの所有者、目的、ツール、認証情報を記録することを提案している。その後、ID管理システムとログシステムが、エージェントを、タスクを委任した人間またはサービスから区別できるかをテストし、派生した影響を含め、完全なタスクを最初から最後まで再構成すべきである。連鎖が途切れる箇所は、新たな運用上の強制を追加する前に対処すべきギャップを明らかにする。

編集部の見解：このフレームワークの価値は、新しいゲートウェイを提案することではなく、出発点の順序を組み替えることにある。LiteLLMについて言及された事実に加え、TeleportとOktaの数値は、権限の縮小と帰属の重要性を裏付けている。しかし、それだけで提案された層の順序が唯一の解決策であることや、すべての企業アーキテクチャに適していることを証明するものではない。また、この内容は筆者による分析であり、公式基準ではない。そのため、適用にあたっては、各組織に存在するアイデンティティシステム、ロギング、停止経路の詳細を見直す必要がある。