何が起きたか
VentureBeatのゲスト投稿プログラムで公開された記事で、Nik Kale氏（エンタープライズAIプラットフォームとセキュリティを専門とするプリンシパルエンジニア）が、AIエージェントの統制順序について異論を提示しました。多くの企業はAIゲートウェイを「最初に入れる統制」として選ぶが、実際にはそれは自社が最も運用できていない統制だ、という指摘です。
理由はシンプルです。ゲートウェイはアイデンティティと帰属（attribution）の層の「上に」乗る仕組みなのに、その下の層が企業にはほぼ存在しない。土台のない場所に検問所を建てているという構図です。
加えて、ゲートウェイ自体が攻撃面になります。6月、CISAはLiteLLMの脆弱性をKEVカタログに追加しました。実際に野良で悪用が確認されたためです。この不具合はゲートウェイ経由でホスト上のコマンドを実行させるもので、別の脆弱性と連鎖させると認証情報すら不要でした。しかもこれは、この1つのAIゲートウェイで1か月に開示された7件のCVEのうちの1件にすぎません。
なぜ「順序」が問題なのか
既存のエージェントセキュリティ成熟度モデルの多くは、あるべき将来像の統制項目を並べます。しかしKale氏が問題視するのは、すでに動いているIAM（アイデンティティ・アクセス管理）にどの順番で統制を差し込むかという、いわばブラウンフィールドの課題です。
制御プレーンが「どのエージェントが動いているのか」「誰が委任したのか」「何のタスクか」「どの資格情報を使っているのか」を知らなければ、判断材料は欠落しています。ゲートウェイは明白なポリシー違反なら止められますが、正当な行為と、技術的には許可されているが運用上は不適切な行為とを見分けられません。
記事が挙げる失敗例が具体的です。財務照合エージェントが本番レコードを書き換えようとする。ゲートウェイはユーザートークンを認証し、APIコールを検査します。しかし、そのリクエストがエージェント発であること、そのエージェントの機能がもっと限定されていること、信頼できない生成物によって起動されたツールチェーンの一部であることは見えません。
エージェントの権限を「そのエージェントが仕える人間と同等以下」に絞る発想も、単独では足りません。人を超えないことは保証しても、別個の帰属を作らないからです。1人の権限の下で20体のエージェントが動くこともあり得るのに、それぞれに固有のID、監査ログ、挙動プロファイル、失効経路が要ります。
依存関係ゲート型デプロイという処方
Kale氏は自らの手法を「dependency-gated deployment（依存関係ゲート型デプロイ）」と呼びます。上流のゲートの合格基準を満たすまで、下流の統制は「運用上完成した」とみなさない。ただし下流を並行して開発すること自体は許容する、という考え方です。6つのゲートは次の順序です。
- エージェント台帳と責任者の明確化 — 本番の全エージェントに、名前のついたオーナー、目的、承認済みツール、ライフサイクル状態を持たせる
- 固有のエージェントIDと委任コンテキスト — エージェント本体、そのオーナー、代理して動く主体を識別できる
- タスク単位・短命の資格情報 — 侵害されてもタスク外のリソースに手が届かない
- 帰属可能なテレメトリ — 完了したタスクを起点から下流影響まで再構成できる
- ランタイムのアクション強制 — トークンの有効性だけでなく、エージェント・主体・タスク・アクションの文脈でポリシー判断する
- 挙動ベースラインと横断的キルパス — エージェントの実効的な権限を、届く範囲すべてで止められる
ゲート1の台帳は、OSSフレームワーク、クラウドサービス、SaaS、開発者ツールに散らばる本番エージェントを網羅し、オーナー・責任・ライフサイクル段階・許可ツール・データ領域・資格情報の出所まで記録します。これを飛ばした代償は「インシデント対応の最初の1時間」で支払うことになる、というのが記事の表現です。
ゲート2は、エージェントを開発者トークンや共有サービスアカウント、人間のセッションに埋没させないこと。IDは「どのアクターが呼んだか」、委任は「誰の権限でなぜ動いたか」に答えます。この紐付けがないと、照合エージェントの行動はトークンを借りた従業員の行為としてログに残ります。
ゲート3を貫く原理は「monotonic delegation（単調な委任）」です。責任の移譲は必ず権限を保つか減らすかであって、増やしてはならない。照合エージェントは従業員の全アクセスを継承するのではなく、1つの元帳だけを見ればよい、というわけです。実装はワークロードID、トークン交換、条件付きアクセ���、期限付きエンタイトルメントなど、既存IAMの機能で足ります。
ゲート4は、Kale氏がレビューしてきた導入事例で「最も抜けているゲート」と述べる部分です。ツール呼び出しを、エージェントID・起点となった主体・タスクID・親アクション・結果に紐付ける。ここが揃って初めて、適応的なランタイムポリシーが意味を持ちます。
そして上流が揃うと、ようやくゲートウェイは「このエージェントは、この主体のために、このタスクの中で、このリソースに対し、このアクションを行う権限があるか」と問えるようになります。最も厳しい統制を置くべきは不可逆な境界、すなわち決済、アクセスポリシー変更、削除、本番環境の変更、データエクスポートです。ゲート6が最後なのは、ベースラインを引くには帰属可能な活動記録が先に要るからです。適切なキルパスは、IDの無効化、アクティブ・派生の資格情報の失効、ツール起動のブロック、実行中タスクの終了、ワークロードの隔離までを含みます。
数字が示す落差
記事は2つの調査に触れています。セキュリティリーダー205人を対象とした2026年のTeleportの調査では、AIに過剰な権限を与えている組織のインシデント発生率が76%だったのに対し、最小権限を適用している組織では17%でした。またOktaの2026年調査では、エージェント型の「労働力」に人間と同じセキュリティ厳格さを常に適用していると答えた経営層は34%にとどまります。
IAMを入れ替える必要はない、というのが結論部です。IdPがエージェントをネイティブなオブジェクト型として扱わないなら、既存のワークロードIDに紐づく権威あるレジストリから始め、エージェントIDとタスクIDを信頼された実行コンテキストとして拡張し、短命な資格情報を加え、識別子をツール呼び出しログに含めてゲートウェイに取り込ませる。
30日間の行動計画も具体的です。本番エージェント10体から着手し、オーナー・目的・承認ツール・資格情報を記録する。IAMとログが各エージェントを委任元の人間やサービスと区別できるかをテストする。そして完了済みのタスクを1件、下流影響まで含めて端から端まで再構成し、鎖のどこが切れているかを見つける。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって刺さるのは「ゲートウェイを買えば統制した気になれる」構図です。国内でもAIエージェント導入時にLLMゲートウェイ製品を先に検討する例は多いですが、記事の主張が正しければ順序が逆で、しかもLiteLLMのように1か月7件のCVEが出る領域を新たな攻撃面として増やすことになります。
特に危ういのは、SaaS事業者と受託開発企業です。SaaSはマルチテナント環境でエージェントが顧客データに触れるため、「1人の権限で20体が動く」状態は監査時に説明不能になります。SOC2やISMSの監査対応、あるいは金融・製造の大手顧客からのセキュリティチェックシートで、「どのエージェントが誰の委任で何をしたか」を再構成できないと商談が止まります。受託開発では、開発者トークンや共有サービスアカウントでエージェントを動かす実装が納品物に混ざりやすく、後から帰属を分離するコストは初期設計の比ではありません。ECでは決済・在庫・顧客データ書き換えが不可逆な境界に直結します。
経営者が今週やるべきことは明確です。CIO/CISOに「本番で動いているエージェントの一覧とオーナー名」を出させる。出てこなければゲート1未達で、ゲートウェイ製品のPoCは順序を誤っています。そのうえで30日計画に沿い、エージェント10体の棚卸しと、完了タスク1件の端から端までの再現テストまでを期限付きで課すのが現実的な第一歩です。Teleportの76%対17%という差は、これを投資判断の材料にできる数字です。