認証を突破した AI エージェントもドリフトやデータ露出のリスクがある

エージェントの導入には明確な反復パターンが存在します。チームが最初に手を付けるのはゲートウェイですが、実際には最も準備ができていないのがこの部分です。その理由は、ゲートウェイがアイデンティティや帰属関係（アトリビューション）のレイヤーの上に位置しているにもかかわらず、これらの基盤がほとんど整備されていないからです。

最初のリスクは仮説的なものではありません。今年6月、CISA は攻撃者が実環境で悪用した事例を踏まえ、LiteLLM の脆弱性を既知の悪用済み脆弱性カタログに登録しました。このバグはゲートウェイ自体を通じてホスト上でコマンドを実行するものであり、2 つ目の脆弱性と組み合わせれば認証情報なしでも利用可能でした。これはわずか1か月の間に同 AI ゲートウェイで報告された7つの一般的な脆弱性情報（CVE）の一つです。多くの企業がまずセキュリティ対策として手を付けるのがこのレイヤーですが、実はそこが最も脆いのです。

安全なエージェントアーキテクチャを構築する際、ゲートウェイによる制御は最初の手段にしてはいけません。むしろ5番目に位置づけるべきです。

エージェントセキュリティの成熟度モデルでは、企業が将来必要とする制御策が説明されることが一般的です。しかし私の経験則では、こうした記述はより困難な課題を見落としています。それは「ブラウンフィールド（既存環境）」におけるシナリオをどう扱うかという問題です。すでに導入済みのアイデンティティ・アクセス管理システムと連携させる際、これらの制御策をどのような順序で重ねていくべきなのか——その指針が欠けているのです。

制御プレーンが、どのエージェントが動作しているのか、誰から業務を委任されたのか、何を実行すべきなのか、そしてどの認証情報が使用されているのかを把握できていない場合、その文脈は不十分です。ゲートウェイが明確なポリシー違反をブロックすることはできても、正当な行動と、技術的には許可されているものの運用上不適切な行動を見分けるのは困難になります。

エージェントの生産環境への導入において、これらの制御を順序立てて適用した際の失敗パターンは明白です。実装は早期に行われますが、その依存関係となるアイデンティティや帰属文脈はまだ構築されていません。エージェントセキュリティは依存チェーンとして機能しており、各制御は上流で生成された文脈に依存しています。

間違った出発点

新しいランタイムゲートウェイを介してエージェントのトラフィックをルーティングすることを考えてみましょう。財務照合用のエージェントが生産環境のレコードを変更しようとしたとします。ゲートウェイはユーザートークンの認証を行い、API 呼び出しをチェックします。しかし、そのリクエストがエージェントによって開始されたものなのか、エージェントがより限定的な機能を実行しているのか、あるいは信頼できないアーティファクトによって呼び出されたツールチェーンの一部であるのかといった点を、ゲートウェイは観測できません。

認証情報は有効です。API 呼び出しも許可されています。しかし、その行動は委任の目的に反しています。ゲートウェイは存在しますが、それを支えるべき要素が欠けているため、全体像のごく一部に対してのみ、コストのかかる制御が適用されてしまうことになります。

エージェントの権限を、そのエージェントが代行する人間の所有者と同じ範囲に制限することは有用です。これにより、エージェントが所有者を超えて行動することを防げます。しかし、権限の上限を設定しただけでは、個別の責任所在（アトリビューション）は確保されません。1 つの人間アカウントの下で 20 個のエージェントが動作していても、それぞれに固有の ID、監査ログ、行動プロファイル、そして権限剥奪パスが必要になります。

依存関係に基づくデプロイメント

私はこのプロセスを「依存関係ゲート付きデプロイメント」と呼んでいます。下流側の制御を実用的に完了とみなすためには、上流側の出口テスト（exit tests）がすべて満たされている必要があります。ただし、下流側の制御の開発は並行して進めることは可能です。

以下の 6 つのゲートと、その有効性を証明する根拠を示します。

• ゲート：制御項目 / 実効性の証明
• 1：エージェントのインベントリ管理と責任所有者の明確化 / 全生産環境のエージェントには、名前の付いた所有者、目的、承認されたツール、ライフサイクル状態が設定されている
• 2：固有のエージェント ID と委譲コンテキスト / システムは、エージェント自体、その所有者、およびエージェントが代行している本権限者（プリンシパル）を識別できる
• 3：タスク限定の短期有効な認証情報 / 侵害されたエージェントであっても、割り当てられたタスクに関連しないリソースにはアクセスできない
• 4：追跡可能なテレメトリ / 完了したタスクは、開始から下流への影響に至るまで再構築可能である
• 5：ランタイム時の行動強制 / ポリシー判断は、単なるトークンの有効性だけでなく、エージェント、所有者、タスク、アクションの文脈をすべて含む
• 6：行動ベースラインと全システムでの停止経路 / エージェントの有効な権限は、到達するあらゆる場所で即時停止可能である

エージェントのセキュリティ制御における 6 つの依存ゲート。各制御は、その上位にあるゲートによって文脈が定義されます。これは、著者が本番環境のエージェント導入事例を分析した結果に基づくものです。

まず、実際に名指し可能なエージェントから始めましょう

まずは、オープンソースフレームワーク、クラウドサービス、SaaS、開発者ツールなどで稼働している本番環境のエージェントを特定することから始めます。各エージェントについて、所有者、責任範囲、ライフサイクルの段階、許可されたツール、取り扱うデータドメイン、そして認証情報の出所を記録してください。

このステップをスキップすると、組織はインシデント対応の最初の 1 時間を、「何が当然のこととして認識されるべきだったのか」を特定する作業に費やしてしまい、損失を被ることになります。資産目録を作成することで、その後のすべての制御が管理対象とする資産を明確にできます。

エージェントには独自のアイデンティティが必要ですが、背後にいる人間とのつながりを断ってはなりません

エージェントは開発者トークンや共有サービスアカウント、あるいは人間のセッションの中に埋もれてはいけません。単に「呼び出し元がエージェントである」という事実だけでは不十分です。制御プレーンでは、追加の委任コンテキストが必要です。「誰が業務を委任したのか」「エージェントに実行すべき特定のタスクは何なのか」「どのリソースへのアクセス権限が必要なのか」です。アイデンティティは「誰が呼び出しを行ったか」を特定し、委任は「誰の権限で、どのような理由で行動しているか」に対する答えとなります。

このつながりが断たれてしまうと、後続のログでは、トークンを借用した従業員の肩書きにリコンシリエーションエージェントが紐付けられ、そのエージェントが行ったすべてのアクションが、実際には開始者ではない人物のものとして記録されてしまいます。

振る舞いを監査する前に権限を縮小せよ

エージェントが識別可能になった段階で、その能力は制限されるべきです。アクセス権限はタスクに限定され、タスク実行に必要なツールとリソースのみを対象とする時間制限付きである必要があります。これは、組織がすでに保有しているワークロードアイデンティティ、トークン交換、条件付きアクセス、時間制限付きエンタイトルメントといった、ID アクセス管理（IAM）機能を用いて実装できます。

205 人のセキュリティリーダーを対象とした 2026 年の Teleport 調査によると、アクセス範囲は業界の予測能力や成熟度、自己評価に基づく AI インシデントの予測精度を超えています。例えば、権限が過剰に付与された AI を導入している組織ではインシデント発生率が 76% に達する一方、最小権限原則に基づいて運用されている組織では 17% にとどまりました。これは、依存チェーンにおけるアクセス範囲が、文脈を認識したランタイムでの強制よりも重要であることを示しています。

基本原則は「単調な委譲」です。責任の移転においては、権限を維持するか縮小するものであり、決して権限を増加させてはいけません。リコンシリエーションエージェントの場合、これは全システムへのアクセス権を持つ従業員とは対照的に、1 つの台帳のみを閲覧できるエージェントを指します。

自動化による強制を実行する前に、まず帰属（アトリビューション）の問題を解決する必要があります。

監査スタックの多くは、どのリソースがアクセスされたか、およびどの認証情報でアクセスが許可されたかを記録できます。私がレビューしたエージェント導入事例において、このチェックポイントが最も見落とされがちです。

適応型ランタイムポリシーを導入する前に、関連するツールの呼び出しを必ずエージェントのアイデンティティと紐付けます。その際、初期化された主体（プリンシパル）、タスク ID、親アクション、そして結果も併せて記録してください。そうして収集したテレメトリデータを精査すれば、完了したタスクについて、誰が開始し、どのエージェントが実行し、どのような権限の下で行われ、どのツールが使われ、最終的にどうなったかを追跡できます。規制の厳しい環境では、責任所在が不明瞭な監視は正当化されません。

ゲートウェイの真価が発揮されるのはここです

ゲートウェイは、登録されたアイデンティティ、明示的な委任、スコープ限定の認証情報、そして責任追跡可能なテレメトリを活用して、このエージェントが「この主体のために」「このタスク内で」「このリソースを扱う」権限を持っているかを問い質します。ユーザーの認証情報が財務照合用エージェントへの書き込みアクセスを付与していたとしても、ゲートウェイは状況文脈を把握しているため、「これはスコープ外だ」と判断できます。これが制御において最も価値の高いポイントです。

不可逆的な境界線——支払い処理、アクセスポリシーの変更、データ削除、本番環境の改変、データエクスポートなど——においては、最も厳格な制御を適用すべきです。

検知とキルパス（停止経路）は最後の手段として機能します

行動ベースラインは、エージェントの活動が明確に区別・追跡可能であることを確認した上で設定されるため、最終的に策定されます。これによりセキュリティチームは、ツールの使用における異常パターンや、予期せぬドメイン間アクセス、割り当てられたタスクからの逸脱を検出できるようになります。

封じ込めとは単一のディレクトリオブジェクトを無効化するだけではありません。適切なキルパスには、エージェントのID無効化、アクティブおよび派生クレデンシャルの失効、ツール起動のブロック、進行中のタスクの終了、そしてエージェントを含むワークロードの隔離が含まれます。

IAM の置き換えから始めないでください

新しいアイデンティティプログラムをゼロから設計する必要はありません。既存の ID プロバイダーがエージェントをネイティブオブジェクトタイプとして扱っていない場合でも、既存のワークロード ID と連携する権威あるレジストリから始めることができます。その後、エージェントとタスクの識別子を信頼された実行コンテキストとして拡張し、継承特権を緩和するための短期有効クレデンシャルを実装します。さらに、これらの識別子をツール呼び出しログに含め、後続のゲートウェイでの取り込みを可能にします。

ベンダーサポートが成熟するにつれて、依存関係モデル自体は変更されません。

制御ギャップは測定可能です。Okta の 2026 年調査では、回答した経営層のうちわずか 34% が、組織内のエージェント workforce を人間 workforce と同じレベルのセキュリティ厳格さで管理していると回答しました。このギャップを埋めるために、チェーン最後の制御を最初に適用することはできません。

今後 30 日で取り組むべきこと

まず、10 台の運用環境にあるエージェントを用意します。それぞれについて、所有者、目的、許可されたツール、認証情報を特定してください。これまでに、エージェント登録簿の雛形が作成され、ガバナンスに関する最初の洞察が得られているはずです。

権限付与の追跡可能性をテストしましょう。IAM（アイデンティティ・アクセス管理）やログ記録が、タスクを委任した人間またはサービスと各エージェントを区別できるかを確認します。もしこの種の識別ができない場合、ゲートウェイは全くのブラックボックス状態で運用されていることになります。

アクションチェーン内で完了したエージェントタスクを、開始から終了まで、下流への影響も含めて再構築してください。チェーンがどこで分断されるかが、デプロイの弱点を示す箇所です。

必要なコンテキストが欠落する前に下流での強制措置を追加すると、エージェントのセキュリティが損なわれます。成熟度モデルは到達すべき目的地を示しますが、適切なビルド順序に従えば、運用中に支障をきたさずにその目標に達できます。

ニク・カール氏は、エンタープライズ AI プラットフォームとセキュリティを専門とするシニアエンジニアです。