AI対応RBAC
AIエージェントがユーザーの代わりに行動する際に従来のアクセス制御が機能しなくなる理由と、Edison Watchがソースオーディエンスを追跡してデータ境界を適用する方法。
アルファ機能: AI対応RBACは現在活発に開発中です。機能とAPIは変更される場合があります。詳細な分析については、Agentic AI Disrupts Traditional Data Security Postureをご覧ください。
MCPツール呼び出しはバックエンドアクセスIDを持ちません。エージェントがGoogle Driveのドキュメントを読み取る場合、レスポンスにはファイルの内容が含まれますが、誰がそれを見ることを許可されているかは含まれません。エージェントがその後メールを送信する場合、ツール呼び出しには受信者が含まれますが、ソースドキュメントのアクセスリストに紐づくものは何もありません。従来のRBACは認証で止まります - 宛先オーディエンスがソースオーディエンスのサブセットであるかどうかを追跡しません。
問題
Google DriveとGmailに接続されたエージェントは、ユーザーAとBに共有されたドキュメントを読み取り、その内容をユーザーCに送信できます。IDプロバイダーの観点からは、違反は発生していません - AliceのクレデンシャルはAliceのファイルにアクセスし、Aliceのメールを送信しました。しかし、データは元のアクセスリスト外の人物に届きました。
根本原因：MCPツール呼び出しは返すデータのアクセス制御リストを伝播しません。エージェントのセッションはすべてを単一のコンテキストにフラット化し、誰が何を見ることを許可されていたかの記憶がありません。
なぜこれがAI固有の脅威なのか
従来のアプリケーションはAPIレイヤーでRBACを適用します - 各リクエストは1人のユーザー、1つのリソース、1つのアクションにスコープされます。AIエージェントは以下の理由でこのモデルを壊します：
- コンテキストの蓄積 - エージェントは1つのセッションで複数のソースから読み取り、アクセス制御されたデータを単一のコンテキストウィンドウに混合する
- 暗黙的なデータフロー - エージェントがソースAからの情報をツールBを介して送信するメッセージに要約する場合、DLPがフラグを立てるための明示的な「コピー」操作が存在しない
- IDの崩壊 - エージェントは1人のユーザーとして行動するが、複数のアクセススコープのデータを扱う
Edison Watchがこれを解決する方法
Edison WatchはLethal Trifectaをデータの出所と宛先の追跡で拡張し、受信者がソースデータの読み取りアクセスを持つ者の厳密なサブセットであることを保証します。
出所の追跡 - エージェントがソース（Drive、Confluence、OneDrive）から読み取る場合、Edisonはそのリソースのアクセスリストを記録します：誰がこのデータを見ることができるか。
宛先の検証 - エージェントがデータを送信しようとする場合（メール、Slackメッセージ、ファイル共有）、Edisonは受信者セットを解決し確認します：すべての受信者が元のアクセスリストに含まれているか？ そうでなければ、アクションはブロックされます。
サブセットの適用 - ルールはシンプルです：受信者 ⊆ ソース読者。ユーザーCがエージェントが読み取ったドキュメントのアクセスリストにない場合、送信は拒否されます - Alice自身がCにメールを送信する権限を持っていても。
これは標準的なLethal Trifecta（リスクの広範なカテゴリをフラグする）を超えて、関与する実際のIDに基づいたアクションごとの正確な判断を行います。