9月27日、startuphub.aiが「AI agents have an authorization problem」と題した記事を公開した。AIエージェントが「認可されている」という証拠なしにツールやAPIを実行してしまう構造的なガバナンス問題を取り上げており、PoC（概念実証）段階では見えにくく、本番移行前後に露見するという点でエンタープライズ導入の現場に直接刺さる内容だ。
「認可ギャップ」とは何か
BCG Globalは、エンタープライズにおけるAIエージェント導入の最大の障害を「認可ギャップ（authorization gap）」と名付けた。なお、本記事が参照するBCGの知見は元記事経由の引用であり、BCG側の原典レポートの直接URLは元記事中で明示されていない。
仕組みは単純だ。エージェントはプロンプト、ツール群、そしてクレデンシャル（認証情報）を与えられる。モデルがプラグインやAPIを呼び出し、ツールが実行され、システムはその事実をログに記録する。しかし「この特定のアクションが、この特定のデータに対して、この特定のユーザーのために、その瞬間に明示的に認可されていたか」を検証可能な形で確認するステップが、ほぼ存在しない。
これがパイロット段階では露見しない。デモが成功すると、チームはエージェントの権限を「推薦」から「実行」へ、「読み取り」から「書き込み」へと拡大しようとする。基盤となるモデルは同じままなのに、エージェントが持つ「権限の範囲」だけが肥大していく。コントロールプレーン（制御層）はそのままに、権限だけが膨らむ構図だ。
PoC成功後こそが危ない
この問題の厄介さは、失敗するのがデモではなくパイロット（本番移行前の試験運用）のフェーズである点にある。
読み取り専用のエージェントがデモで完璧に動いた。だから次のステップとしてメール送信・ファイル削除・外部APIへの書き込みを追加する——この判断は現場では自然に見えるが、認可の仕組みを変えずに権限だけ広げることになる。エージェントは「できる」ようになるが、「やっていいか確認された」わけではない。
PoC段階では関与するデータ量もユーザー数も限られており、認可の抜け穴が問題として表面化しにくい。しかし本番移行に伴ってスコープが拡大した瞬間、同じ設計上の欠陥が取り返しのつかない操作を引き起こすリスクに変わる。
具体的なインシデントが示す問題の実在
記事はこの問題が理論ではないことを、実際のインシデントで裏付けている。
- Plugin4Shell：ChatGPTプラグインエコシステムにおいて、エージェントがプラグイン経由で認可なしに外部サービスへアクセス・操作できてしまった事例として報告されたインシデント。プラグインに渡されたクレデンシャルが意図しない範囲のアクションに使われた点が問題視された（※元記事での紹介に基づく。インシデントの詳細は現時点で公開情報が限られる）
- OpenAIのミスアラインメント報告：OpenAIが内部的に確認・報告したケースで、エージェントが明示的な認可の証拠なしに行動を完了させたことが記録されたもの。OpenAIの安全性に関する取り組みの文脈で継続的に議論されている問題領域に該当する
これらのインシデントを受け、ガバナンスの議論は「悪い動作を検知する」方向から、「アクションを実行する前に、暗号的またはポリシーベースの証拠を要求する」方向にシフトしている。
解決策は「検知」ではなく「証拠の要求」
BCGが提示する方向性は明快だ。エージェントは実行前に以下を提示しなければならない：
- 誰が認可したか
- 何を認可したか
- いつ認可されたか
- どのスコープ（範囲）の下で認可されたか
そしてツール側がこれを強制（enforce）する必要がある。ログに残すだけでは不十分であり、実行レイヤー自体が認可の証拠を受け取るまでアクションを走らせない設計が求められる。
現状のほとんどのエージェント実装では、この「ツール側での強制」が欠けている。プロンプトとクレデンシャルを渡せばツールは動く——それ自体が問題の核心だ。この考え方は、OAuth 2.0やOpenID Connectといった既存の認可フレームワークがWebサービス層で実現してきたことを、エージェントのツール呼び出しレイヤーにも適用すべきだという発想に近い。
エンジニアへの含意
AIエージェントのアーキテクチャを設計・レビューする立場にあるエンジニアにとって、この問題はツール呼び出しレイヤーの設計に直結する。「エージェントが何を実行できるか（capability）」と「エージェントが何を実行してよいか（authorization）」を切り分けて管理する仕組みが、本番運用の前提として問われるようになっている。
既存のIAM（Identity and Access Management）設計の知見をエージェント設計に持ち込む動きも始まっており、AWS IAMやGoogle Cloud IAMのようなポリシーベースの認可モデルをエージェントのツール実行フローに組み込む実装パターンが注目されつつある。capability設計だけでなく、認可証拠の設計を最初から組み込む姿勢が、堅牢なエージェント実装の条件になりつつある。
詳細はAI agents have an authorization problemを参照していただきたい。
