AIエージェントはサービスアプリではない：エージェント型アイデンティティのセキュリティを確保する

エグゼクティブサマリー：アイデンティティレイヤーでAIエージェントのセキュリティを確保する

• 重大なセキュリティ上の欠陥：エンタープライズは、導入を迅速化するために、AIエージェントを従来のサービスアプリとして登録しています。しかし、これによりエージェント型スタック内に、特権のエスカレーションにつながる重大なベクトルを意図せず作り出してしまっています。
• 実証されたリスク：財務MCPサーバーに対するテストで、OBOトークン交換を介して実行されるサービスアプリとしてモデル化されたエージェントが、ユーザー固有の制限をバイパスし、標準従業員に会社全体の給与台帳へのアクセスを許可してしまいました。
• ソリューション：サービスアプリからCross-App Access（XAA）を利用するファーストクラスのアイデンティティモデルに移行することで、認可サーバーがユーザーとエージェント両方の権限を評価し、最も制限の厳しいアクセス上限を適用できるようになります。
• 戦略的インパクト：最高レベルのアイデンティティ連携により、エージェントの展開において、既存のエンタープライズディレクトリのガバナンス、コンプライアンス監査、継続的な脅威軽減ツールをネイティブに継承できます。

AIエージェントのアーキテクチャにおける特権のエスカレーションのリスクとは何ですか。

企業がAIエージェントの本番環境への導入を急ぐなか、同じ近道が繰り返し現れています。それは、迅速なリリースとコスト削減のために、AIエージェントに独自のアイデンティティを与えるのではなく、サービスアプリとしてモデル化するというものです。その本能は理解できますが、その行動はやはり間違いです。

技術的証明：財務MCPサーバーのテスト結果

AIエージェントをサービスアプリとしてモデル化すると、エージェント型スタックに特権のエスカレーションを組み込むことになります。エージェントには、そのエージェントが代理で行動する本人よりも多くのアクセス権を付与できます。財務部門のModel Context Protocol（MCP）サーバーに対して行ったテストでは、従業員の給与アシスタントエージェントに従業員本人にはない権限、すなわちCEOを含む社内の全従業員の給与を読み取り、誰の給与でも変更できるスコープが与えられました。

同じエージェントにファーストクラスのアイデンティティを付与すると、同じリクエストが拒否されます。同じユーザー、同じポリシー。変更されたのはアイデンティティモデルだけであり、この記事で紹介するトークンがそれを証明しています。

サービスアプリは、安定したサービス間トラフィックに適したツールであり、その役割は変わりません。AIエージェントのアイデンティティとしては不適切です。エージェントは、実行時にコンテキストに現れるあらゆるものに応じて推論し、動作を変化させます。そのため、共有サービスのアプリ資格情報を使用すると、そのエージェントは他のどの正規ユーザーよりも広範なアクセス権を持つことになります。

エージェントは、アイデンティティの明確なクラスです。1つとしてモデル化しなければ、それらが何を行うかを統制する能力を放棄することになります。以下の表は、2つの選択肢を並べて比較したものです。

AIエージェントのアイデンティティモデルの比較：サービスアプリとファーストクラスアイデンティティ

このパターンは、すべての行で繰り返されます。サービスアプリは、「これはどのアプリケーションか」という1つの問いに答えます。

エージェントは実行時に、「誰がこのアクションを承認し、誰の代理として実行したのか」という、より難しい問いを突きつけます。エージェントのために構築されたアイデンティティだけが、その問いに答えることができます。

アプリとAIエージェントの違いは何ですか？

AIエージェントをシステムと連携させる最も速い方法は、AIエージェントをサービスアプリとして登録し、RFC 8693のトークン交換を実行させてユーザーの代理として動作させることです。なぜなら、すべてが順調にいっているからです。アプリは、コード化されたとおりに動作するだけで、それ以上のことはしません。その権限が、その動作そのものであり、固定化され、予測可能なものとなります。

エージェントには脳があります。実行時に何を呼び出し、何にアクセスするかを決定し、コンテキストに置かれたものに応じて柔軟に対応します。それこそがエージェントの要点であり、そのショートカットが危険である理由です。サービスアプリに広範な共有権限セットを付与しても、リスクは変わりません。エージェントに同じ権限を付与しても、そうはなりません。推論エージェントにそのアクセスの全範囲を付与したことになり、スクリプト化されていない方法でアクセスが使用される可能性があります。

これまでリリースしてきたどのアプリよりもリスクが高くなります。なぜなら、アプリはリダイレクトできませんが、エージェントはリダイレクトできてしまうからです。そして、後からそれに答えることはできません。共有サービスアプリでは、エージェントが代理で操作しているユーザーの権限の範囲内で活動していたかどうかを証明することはできません。何か問題が発生しても、追跡は困難なままです。

ユーザーエンタイトルメントの上限がアクセス制御を決定する仕組み

従業員の報酬情報を公開する財務MCPサーバーを想像してみてください。3つのスコープを定義します。

• Salary:Read:Self：自分の給与の読み取り
• Salary:Read:All：役員やCEOを含む全従業員の給与を読み取ります
• Salary:Write：従業員の給与を変更します

ロールベースのアクセス制御（RBAC）で既に行っているように、グループ単位でアクセス権が付与されます。

Charlieはエンジニアであり、Salary:Read:Selfの権限が付与されています。Aliceは報酬を計画するため、全員の情報を読み取りますが、変更は加えません。ボブは財務部門を統括しており、CEOを含む全員の情報を読み取り、給与を変更します。

3人いれば、上限も3通り。ここで、各ユーザーがアシスタントエージェントに報酬データを扱うよう依頼したところ、エージェントはユーザーに許可されている以上の権限を要求したとします。その話は一旦置いておきましょう。

サービスアプリのアーキテクチャが特権のエスカレーションを引き起こす理由

有効な権限は、エージェントに許可されていること、ユーザーに許可されていること、リソースが公開していることのすべてが重なる部分である必要があります。安全な答えは、重複する部分です。エージェントをサービスアプリとしてモデル化すると、ユーザーがその共通部分から外れ、特権のエスカレーションにつながります。

効果的なユーザー、エージェント、リソースの権限の組み合わせ

OBOトークン交換とCross-App Access（XAA）の比較テスト

同じエージェントを2つの方法でモデル化し、すべてのユーザーに同じ3つのリクエストを実行させました。最初のモデルでは、エージェントは代理（OBO）トークン交換を実行するサービスアプリです。2つ目の方法では、エージェントは、Oktaが共同で策定したCross-App Access（XAA）を使用するファーストクラスのアイデンティティとなります。ID-JAGフローである

同じユーザー、同じグループ、同じリソースサーバーポリシー。変更されたのはアイデンティティモデルだけでした。

以下のトークンはデコードされたものです。ホスト名とEメールアドレスはサニタイズされます。スコープ、sub_profile値、actチェーン、およびエラーは、認可サーバーから受信したとおりに返されます。

1つのモデルがユーザーを運びます。もう一方はそうではありません。

同じエージェント、同じ財務MCPサーバーで、エージェントのアイデンティティをモデル化する2つの方法：

OBOトークン交換を使用するサービスアプリとしてモデル化されたAIエージェント

XAAを使用してファーストクラスのアイデンティティとしてモデル化されたAIエージェント

エスカレーションの証拠：サービスアプリが要求されたすべての権限を付与

各ユーザーに同じ3つのリクエストを実行させました。リクエストごとに、前回よりも少しずつ要求を増やしていきました。以下に、リクエスト、モデルの出力、および各トークンの決定的なクレームを示します。

3件の通話が回線を超えました。いずれのケースでも、サービスアプリはユーザーが持っていないアクセス権を発行しましたが、ファーストクラスのアイデンティティパスがそれを拒否しました。

• エンジニアのCharlieがRead:Allを要求：サービスアプリにより、CharlieのエージェントはCEOを含む社内の全従業員の給与を読み取れるようになります。
• CharlieがRead:AllとWriteを要求：サービスアプリにより、Charlieのエージェントはすべての給与を読み取り、誰の給与でも変更できるようになります。
• 読み取り専用のプランナーであるAliceが書き込み権限を要求：サービスアプリにより、Aliceのエージェントは、Alice自身は決してアクセスできなかった報酬データを変更できます。

ファーストクラスのアイデンティティパスは、その3つすべてを拒否しました。上の表の赤いセルで示されている、セキュリティ障害が発生している箇所に注目してください。CharlieのラインはRead:Allに、AliceのラインはWriteになっています。これは、それぞれが自身のエンタイトルメントを上限としているためです。サービスアプリはその行を認識できないため、要求されたものをすべて許可してしまいます。ファーストクラスのアイデンティティパスは、ユーザーのエンタイトルメントを中心に構築されます。

CFOであるBobが対照となります。このユーザーは3つすべてのスコープに対する権限を持っているため、エスカレーションするものはなく、どちらのモデルでもすべての権限が付与されます。それはシステムが正常に機能しているということであり、不具合ではありません。各アイデンティティにはそれぞれ上限があり、エージェントがユーザーの上限を超えた場合にのみエスカレーションが発生します。

これは仮定の話ではありません。PocketOSのインシデントでは、AIコーディングエージェントが、長期間有効で過剰なスコープを持つ資格情報を見つけ、それを使用して本番データベースを数秒で削除しました。その資格情報にはタスクの実行に必要とされる以上の権限が付与されており、エージェントをより小さな権限セットに限定する仕組みもありませんでした。

その経路はOktaとは異なり、エクスチェンジによって過剰に発行されたトークンではなく、ファイル内の永続的なトークンでしたが、このインシデントは、状況によって決して正当化されない権限でエージェントが操作するという、同じ種類の障害に分類されます。エージェントをユーザーの権限に紐付けることで、そのエージェントがアクセスできる範囲はユーザーがアクセスできる範囲に限定されます。

必要なのは、わずか1回の通知だけです。エージェントが読み取るドキュメントへのプロンプトインジェクションやエージェントのハイジャックによって、「自分の報酬を表示」という指示が、「すべての給与をエクスポート」や「この人物の給与を設定」といった指示にすり替えられてしまいます。ユーザーはどちらの操作も許可されていませんでしたが、サービスアプリのアイデンティティをまとったエージェントは許可されています。

3つのエスカレーション、完全なフローの並列表示

サービスアプリとファーストクラスのアイデンティティモデルを使用した完全なフローとして、各エスカレーションを並べて比較したものを以下に示します。ユーザーがサインインすると、エージェントがその委任を示し、トークンが給与計算ツールに到達します。サインインはリクエストごとに同じであるため、相違点はそれ以下のすべてにあります。

シナリオ1：エンジニアのCharlieがRead:Allを要求する

シナリオ2：CharlieがRead:AllとWriteを要求する

シナリオ3：読み取り専用のプランナーであるAliceがWriteを要求する

このパターンが繰り返されます。

• サービスアプリのパスは、リクエストと自身の権限のみをチェックするため、使用可能なトークンを返します。
• ファーストクラスのアイデンティティパスはこれら3つすべてを拒否します。エージェントの背後にいるユーザーを認識し、そのユーザーにこれらの操作を実行する権限がないことを把握できるためです。

リクエストがユーザーのエンタイトルメントの範囲内である場合、同じパスでトークンが発行され、委任チェーンが付随するため、アクションの帰属は維持されます。

プラットフォームのアイデンティティと可用性に関する懸念への対応

反論：「エージェント型プラットフォームが、すでにエージェントにアイデンティティを付与している」

これらのプラットフォームは各エージェントのアイデンティティを生成し、ゲートウェイがそれを伝達します。そのアイデンティティは実在しますが、エンタープライズのディレクトリではなく、Platform内に存在します。プラットフォーム内のどのエージェントがアクションを実行したかはわかりますが、そのエージェントには人間のエンタイトルメントが引き継がれず、既存のガバナンスに組み込むこともできません。他のアイデンティティの場合と同じ方法でエージェントのアクセスを認定または失効させることはできません。

ゲートウェイのみに依存すると、ゲートウェイがコントロールプレーンとなり、IdPはその背後にあるトークンエンドポイントになります。エージェントには、それがサービスを提供するユーザーに紐付けられたエンタープライズアイデンティティが依然として必要ですが、Platformアイデンティティではこれは提供されません。

反論：「現在、サービスアプリのパスが利用できるのに、なぜそれを使わないのですか？」

これこそが、私たちがテストしたパスです。委任元のユーザーアイデンティティのアクセス権限は無視し、自身のアクセス権限のみに制約された上で、呼び出し元が要求したスコープを返します。認定とプロビジョニングはカスタム開発に委ねられます。セットアップは可能ですが、エージェントをユーザーのエンタイトルメントに紐付けたり、他のアイデンティティと同様に管理したりすることはできません。その制約があるからこそ、エージェントには専用のファーストクラスのアイデンティティが必要なのです。

要するに、エージェントに独自のアイデンティティを与えるということです。

すべてのツールには目的があります。サービスアプリは、安定したサービス間トラフィックに適しており、今後も変わらず利用され続けます。AIエージェントは、これまでとは異なる種類のアクターです。共有サービスアプリの資格情報を付与することは、組織内で最も有能なアクターに、最もアカウンタビリティの低いアイデンティティを渡すことになります。

エージェントに、それが仕えるユーザーに紐付けられた独自のアイデンティティを付与します。そうすることで、トークンはいずれ問われることになる「これを実行したのはどのエージェントか、そして誰の権限に基づいているのか」という問いに答えられるようになります。

自社で発生しているAIアイデンティティの危機を解決する準備はできましたか？

• アカウンタビリティ（説明責任）の詳細：『The AI Attribution Gap』をお読みになり、自動化されたエージェントのActionsを人間の所有者まで遡って追跡し、明確な法的帰属を確立する方法をご確認ください。
• Oktaのソリューション：OktaとAuth0がAIエージェントのセキュリティを確保し、エージェント型ライフサイクル全体を単一の統合コントロールプレーンで管理する方法をご紹介します。
• ロードマップの策定：貴社のエンタープライズアーキテクチャに合わせた、アイデンティティファーストのAIセキュリティ戦略の策定については、Oktaのエキスパートにご相談ください。