本記事は、AIセキュリティとしてのアイデンティティセキュリティをテーマとした7部構成のシリーズの第6回目のブログです。
要約：
AIエージェントは、認証されたユーザー（チェック済み）の権限を使用してデータを取得しますが、アウトプットするのは、さまざまな権限（チェックされず）の受信者がいる共有ワークスペースです。たとえば、Slackチャネル内のCFOのエージェントが、幹部の報酬をジュニアアナリストに公開してしまう可能性があります。2025年には重大な4件の脆弱性（CVSS 9.3～9.4）が、Anthropic、Microsoft、ServiceNow、Salesforceに影響を与えました。その原因は、許可された取得と不正な受信者という、同じパターンでした。これを修正するには、データが取得レイヤーを離れる前に、すべての受信者の権限の共通部分を計算する、きめ細かな認可が必要です。このステップは、OAuthの処理が完了した後に行われます。
問題点
OAuthは、1人のユーザー、1つのアプリケーション、1つの権限セットという、よりシンプルな世界のために構築されました。AIエージェントはこのモデルを覆し、複数のユーザーがアウトプットを見る、共有コンテキストで動作しています。プロトコルも、その上に構築されたプラットフォームも、このような状況を想定していませんでした。
その結果、AIエージェントはある幹部のアクセス権を継承するものの、その場にいる全員に公開してしまいます。McKinseyによると、組織の80％はすでに不適切なデータ漏えいや承認なしのシステムへのアクセスなど、AIエージェントによる危険な行動に遭遇しています。組織が心配するのも当然です。
このような状況は、実際にはどのように発生するのでしょうか。OpenID FoundationのエージェンティックAIに関するホワイトペーパーに、このシナリオが記載されています。
CFOがSlackチャネルにAIエージェントを導入します。エージェントはCFOの認証情報で認証され、報酬データ、役員会の資料および人事システムへのアクセスを継承します。ジュニアアナリストが「第3四半期の報酬予算はいくらですか？」と質問すると、エージェントは予算スプレッドシート、報酬プラン、役員給与のスケジュールを取得します。認可チェックでは、CFOはこれらのファイルへのアクセス権限があり、エージェントはチャネルに応答します。こうして、ジュニアアナリストとチャネルの他のメンバーは、CEOの給与を知ることになります。
エージェントは設計どおり正確に動作しましたが、認可モデルが失敗しました。
パターン：4つのプラットフォーム、1つの共通スレッド
2025年6月から10月にかけて、4つの重大な脆弱性で、一つのパターンを明らかになりました。これらの脆弱性は同一ではありませんが、共通点があります。それは、認可がアウトプット時ではなく、取得時にチェックされることです。
Anthropic Slack MCP Server、2025年7月
Johann Rehberger氏は、最初の重大なMCPの脆弱性を発見しました。エージェントがSlackに投稿すると、プラットフォームはハイパーリンクを「展開」してプレビューを生成します。攻撃者は、管理者OAuth権限で動作するエージェントにプロンプトを注入し、機密ファイルを読み取り、そのデータをURLに組み込みます。SlackのプレビューボットがURLを取得し、クリックなしでデータ流出を完了します。Anthropicは、パッチを適用する代わりにサーバーをアーカイブしました。取得：管理者権限（チェック済み）。アウトプット先：攻撃者のサーバー（チェックされず）。
Microsoft 365 Copilot (EchoLeak)、2025年6月
Aim Securityは、本番環境のAIエージェントに対する初のゼロクリック攻撃を公表しました。攻撃者は隠された指示が記載されたEメールを送信し、それを受信者が開くことはありません。CopilotのRAGエンジンは、SharePointファイルおよびOneDriveファイルとともにペイロードを取り込み、機密データをコンテンツセキュリティポリシーをバイパスするアウトバウンドURLにエンコードします。調査員は、これを「LLMスコープ違反」と呼びました。エージェントは信頼境界を分離せずに、信頼されていないインプットを信頼されたデータと統合してしまうものです。Microsoftは修正プログラムをデプロイしましたが、このパターンは依然として続いています。取得：被害者のM365権限（チェック済み）。アウトプット先：攻撃者のURL（チェックされず）。
ServiceNow AI Platform（BodySnatcher）、2025年10月
AppOmniのAaron Costello氏は、Virtual AgentとNow Assistが、アカウント連携のためにハードコードされたシークレットとEメールアドレスを信頼していることを発見しました。攻撃者は、ターゲットのEメールさえ知っていれば、管理者を含む任意のユーザーを偽装し、MFAを完全にバイパスできます。いったん偽装できると、攻撃者は被害者の完全な権限を持つAIエージェントを呼び出して、ITSMレコードにアクセスしたり、特権付きワークフローをトリガーしたりします。Costello氏はこの脆弱性を「これまでに見つかったAI主導の最も深刻な脆弱性」と呼んでいます。取得：偽装されたユーザーの権限（チェック済み）。リクエストした人のアイデンティティ：攻撃者（チェックされず）。
Salesforce Agentforce (ForcedLeak)、2025年9月
Noma Securityは、Web-toリードフォームを介し、CRMデータの流出を可能にするプロンプトインジェクションを発見しました。攻撃者は隠された指示を組み込んだフォームを送信します。後で従業員がその見込み客についてAIに問い合わせると、エージェントは両方のリクエストを実行します。さらに悪いことに、my-salesforce-cms.comのドメインは、期限が切れていたにもかかわらず、ホワイトリストに残っていました。攻撃者はそのドメインを5ドルで購入し、信頼できるデータ流出経路を確立しました。取得：従業員のCRM権限（チェック済み）。アウトプット先：攻撃者のドメイン（チェックされず）。
共通点：各システムは、呼び出し元のユーザーがデータにアクセスできるかどうかをチェックしましたが、アウトプットの受信者すべてがアクセスできるかどうかはチェックしませんでした。
OAuthに要求されなかったこと
過去20年間、OAuthが機能していたのは、アプリケーションがアクセスを認可した同一のユーザーにデータを返していたからです。AIエージェントはこの前提を覆します。エージェントは、委任されたユーザー認証情報、独自のサービスアイデンティティ、または他のユーザーと共有されるユーザー構築の自動化を利用し、さまざまな方法で認証を行います。パターンは異なりますが、問題は変わりません。複数の人がアウトプットを見る共有コンテキストで対応してしまいます。
結果として、認可は取得時に行われますが、アウトプット時にチェックはされません。複数のオーディエンスが関わるコンテキストでは、オーディエンスを理解した認可でOAuthを拡張する必要があります。OAuthの仕様では、「オーディエンス」はターゲットAPIを指します。ここで言うオーディエンスは、エージェントのアウトプットを見る人々を意味します。
OAuthは基盤を提供します。その基盤をオーディエンスを理解した認可に拡張することで、AIエージェントの安全を確保します。
問題を解決するアーキテクチャ
この問題を解決するには、オーディエンスを理解した認可が必要です。つまり、認可レイヤーは、取得前にオーディエンスを認識し、リアルタイムで権限の共通部分を計算する必要があります。エージェントは、すべてのオーディエンスメンバーが閲覧を認可されるデータのみに対応します。
このアーキテクチャには、連携して動作する3つのコンポーネントが必要です。
きめ細かな認証エンジン。権限を静的なロールではなく、関係性としてモデル化します。すべてのオーディエンスがアクセスできる情報の共通部分を、ミリ秒単位で計算します。
認証情報管理レイヤー。接続されたアプリケーションのOAuthトークンを保存します。計算された権限の共通部分に基づいて、スコープの認証情報をエージェントに発行します。
アイデンティティガバナンス。継続的なレビューと修復を通じて、権限グラフの精度を維持します。正確な権限がなければ、共通部分の計算で誤った結果が出ます。
権限の共通部分のフロー
重要ポイント：CEOの給与データはそもそも取得されません。エージェントに発行されたトークンでは、給与データにアクセスできません。取得後にフィルタリングは行いません。取得前にスコープを設定します。
なぜDLPだけでは不十分なのでしょうか。データ漏えい対策（DLP）は、機密データが応答に表示された後に検知します。きめ細かな認可では、まずデータの取得を防ぎます。DLPはシートベルトのようなものです。スコープを設定した取得とは、壁に衝突しないようにすることです。
OktaとAuth0でどのように実現するか
Fine Grained Authorization（FGA）
従来のRBACは、静的なロールを割り当てます。FGAは、権限を関係性としてモデル化します。例えば、「VP of Salesは、財務チャネルのメンバーであるため、予算データを表示できる」などです。この関係性グラフにより、共通部分の計算が可能になります。すべてのチャネルメンバーがアクセスできるデータをエージェントが把握する必要がある場合、FGAのbatchCheck APIは、数十億の関係性にミリ秒単位で応答します。
Token Vaultは、あらゆるSaaSアプリケーションのOAuthリフレッシュトークンを保存し、トークンのライフサイクルを自動的に処理します。オーケストレーションレイヤーでは、ボールトからトークンを取得し、計算された権限の共通部分に基づいて、スコープの認証情報をエージェントに発行します。
エージェントが複数のアプリケーションにまたがる場合、認可はそれらすべてにまたがる必要があります。Cross App Accessは、同意とポリシーの適用をアイデンティティプロバイダーに移行することでOAuthを拡張して、エンタープライズITでエージェントとアプリ間の接続を一元的に管理できるようにします。
リアルタイムの認可の精度は、基盤となる権限データによって決まります。Identity Governanceは、権限が継続的にレビューおよび修正されるようにします。権限が逸脱したり、孤立アカウントが蓄積したりすると、共通部分の計算は誤った答えを出します。Governanceにより、権限グラフの精度を保つことができます。
規制上のリスク
GDPR第32条および第5条（1）（f）。第32条では、「個人データの不正な開示またはアクセス」に対する保護を含む「適切な技術的および組織的措置」を要求しています。第5条（1）（f）では、「適切なセキュリティを確保する方法で」処理することを義務付けています。AIエージェントが、従業員のPIIを認可されていない社内ユーザーに公開する場合、両方の条項が適用されます。罰金は2,000万ユーロ、すなわち世界の年間総収入の4％に達する可能性があります。
CCPA第1798.150条。カリフォルニア州の私的請求権では、消費者は、個人情報が「事業者による合理的なセキュリティ手順の実装および維持義務の違反の結果として、不正アクセスおよび流出、盗難、または開示の対象となる」場合に、訴訟を起こすことができます。AIエージェントによる社内での情報の過剰な露出は、この基準にあてはまる可能性があります。法定損害賠償：インシデントごとに消費者1人あたり100ドル～750ドル。
サーベンスオクスリー法第404条。第404条では、公開企業は「適切な内部統制構造を確立および維持する」ことが求められています。 実行権限を持つAIエージェントが、認可されていない従業員に重要な非公開情報を公開する可能性がある場合、適切な統制を実証する能力は著しく損なわれます。監査役はこれを重大な欠陥として指摘する可能性があります。
McKinseyの調査が示しているように、組織の80％は、不適切なデータ露出を含む、AIエージェントの危険な行動にすでに遭遇しています。FGAは、取得前に権限の共通部分を計算し、これらのコンプライアンス義務に直接対処するために役立ちます。
次回のセキュリティレビューに向けた質問
セキュリティチームに、「共有ワークスペースにデプロイされているすべてのAIエージェントでは、エージェントのアウトプットが、そのワークスペースの全メンバーに閲覧が認可されるデータに制限されることを実証できますか？」と質問してみてください。
答えが「いいえ」の場合、規制違反を指摘される可能性があります。
この問題を解決するテクノロジーは、すでに存在しています。okta.com/aiおよびauth0.com/aiで、OktaとAuth0がAIエージェントをどのように保護するかをご覧ください。AIエージェントの保護に関するホワイトペーパーをダウンロードするか、Oktaの担当者に連絡して、貴社のAIデプロイメントにおける権限の共通部分のギャップを評価しましょう。
次回：第7回目のブログでは、6つのアイデンティティに関する課題をすべて統合フレームワークにまとめます。
