アイデンティティとアクセス管理は、より単純な世界のために構築されました。最も難しい問題が人間のログインであり、「あなたは誰ですか？」が誰かが何ができるかを決定するのに十分だった世界です。そのモデルは数十年間、企業に良いサービスを提供してきました。
非人間的なアイデンティティがすべての認証の90%以上を占める世界、AIエージェントがシステム全体で機能し、APIコールの連鎖をトリガーし、人間を介さずに数ミリ秒でアクセス決定を下す世界のために構築されていません。従来のIAMを信頼性のあるものにした前提は、企業が今日導入しているものにとって不適切である理由そのものです。
必要なのは、既存のアーキテクチャに固定された新しい製品ではありません。ユーザーではなくアプリケーションに焦点を当てる異なるメンタルモデルであり、認可を一度通過するゲートではなく、各ステップで評価される継続的なプロセスとして扱うものです。
認証は一瞬のもの。認可はプロセス
ほとんどのIAMプラットフォームに組み込まれている基本的な前提は、アクセスが一度通過するゲートであるということです。認証し、トークンを受け取り、進行します。システムは、最初にゲートを通過した者が、マルチエージェントワークフローの12番目のステップで同じアクションを実行する同じエンティティのままであることを信頼します。人間にとっては、その前提はほぼ問題ありません。エージェントにとっては、構造的な脆弱性です。
ほとんどのIAMシステムは単一の質問を中心に構築されています。このユーザーはこのアクションを実行することが許可されていますか？これはログイン画面に適した質問です。ユーザーが直接存在しないAPIチェーンの場合、これは間違った質問です。技術的には、ユーザーは決して自分自身でリクエストを送信することはなく、常にアプリケーションがそれらの代わりにリクエストを送信しています。認可決定がユーザー権限のみに基づいている場合、システムはリクエストがどのように行われているか、またはそのコンテキストで予期されているかどうかを理解する方法がありません。
AIエージェントがユーザーの代わりに機能する場合、2つのアイデンティティが即座に関与しています。エージェントが誰であるか、そしてユーザーが誰であるかです。ほとんどのIAMシステムは1つを追跡するために構築されました。エージェントはユーザーの権限で機能し、多くの場合は事前にプロビジョニングされた広範な権限で機能し、システムはエージェントがチェーンの各ステップで実際に何をしているかを可視化することができません。これは設定の問題ではありません。アーキテクチャの問題です。
アイデンティティ拡大の罠
IAM市場の本能は、エージェントを新しいタイプのアイデンティティとして扱うことで、これを解決することです。エージェントを登録します。プロファイルを与えます。ライフサイクルを管理します。アクセスレビューを実行します。不要になったら廃止します。これは企業が人間のアイデンティティをどのように処理するかを反映しており、これはまさに問題です。
AIエージェントは従業員ではありません。従業員は参加し、数年間働き、去ります。MCPクライアントは接続し、タスクを実行し、切断します。マルチエージェントシステムでは、エージェントは動的に他のエージェントを生成します。何秒間存在するものもあります。これらのエンティティにディレクトリベースのライフサイクル管理を適用しても、セキュリティの問題は解決されず、新しい問題が生まれます。プロビジョニングするエントリが増えます。クリーンアップするオーファンなアイデンティティが増えます。もう存在しないエンティティに対するアクセスレビューが増えます。これはマシンスピードでのアイデンティティ拡大です。
問題はエージェントが誰であるかではありません。問題は、それが今このコンテキストで何をすることが許可されているか、そして誰の代わりにそれが許可されているかです。
ランタイム認可の実際の見た目
より有用な出発点はユーザーではなくアプリケーションです。アプリケーションは目的を果たすために存在します。彼らはAPIと相互作用し、一部はユーザーの代わりに、その他は独立して相互作用します。アプリケーション中心のモデルは、アプリケーションが何をすることが許可されているかをユーザーが何をすることが許可されているかから切り離し、1つのアプリケーションがユーザーの代わりにどのように機能するか対別のアプリケーションについての正確なルールを定義することができます。
これはAIにとって非常に重要です。エージェントは特定のアクション、特定のデータ、特定の瞬間を対象とした、ジャストインタイムの最小権限アクセスが必要です。そのコンテキストを伝える仕組みはアクセストークンです。あなたが入ることが許可されていることを証明する単純な認証情報としてではなく、コンテキストの担い手として。誰が行動しているのか、誰を代表しているのか、何をしようとしているのか、そして今どれだけ信頼されるべきなのか。APIはその情報が必要です。正しいアクセス決定を下すために。トークンがそれを運ばない場合、APIは強制の根拠がありません。
エージェントは認証し、それが実行する必要があるアクションに正確にスコープされたトークンを受け取るべきです。タスクが完了したら、その認可は消えます。ディレクトリエントリはありません。管理するライフサイクルはありません。侵害される可能性のあるスタンディングアクセスはありません。
あなたのAPIが既に話しているアーキテクチャ
これらのいずれも既存のインフラストラクチャを交換する必要はありません。これを機能させる標準は、OAuth 2.0、トークン交換、および動的で一時的なクライアント登録は、エンタープライズAPIが既に実装している同じ標準です。問題は、正しいプリミティブが存在しないことではありません。それらはエージェントが動作するレイヤーに適用されていないということであり、通常はこれを処理するのに十分な動的性をもって構築されていません。
良いニュースは、あなたのAPIが既にOAuthを話しているのであれば、これを正しく実装するのに長く待つ必要がないということです。プリミティブは既にあります。トークン交換、柔軟なクライアントアクセス、および短命のスコープ付きトークン。あなたはゼロから再構築していません。あなたは既に持っているものをより正確に、エージェントが実際に動作するレイヤーで適用しています。
これを正しく実装するウィンドウが閉じています
企業はエージェントをデプロイする前にセキュリティチームがエージェントガバナンスを理解するのを待っていません。デプロイメントは現在、非人間的なアイデンティティのために設計されなかったIAMインフラストラクチャで実行されており、トークンが広すぎて、権限が個々のタスクにスコープされていず、APIチェーン全体でエージェントが何をしているかを可視化することができません。
質問はあなたのIAMプラットフォームがAIエージェントをサポートしているかどうかではありません。ほとんどのベンダーはイエスと言うでしょう。質問は、それがエージェントがランタイムで実際に何をするかを支配しているのか、それとも単にドアで認証してベストを期待するだけなのかです。それはCurity Access Intelligenceが埋めるように設計されているギャップです。
認証は常に一瞬のものでした。今重要な部分は、その後に続くすべてです。
翻訳元: https://www.helpnetsecurity.com/2026/04/27/ai-agents-access-control-model/
