AIエージェントのアクセス制御におけるABACとRBACの比較：ロールだけでは不十分な理由
多くのエンタープライズ向けアクセス制御アーキテクチャは、ロール（役割）を中心に構築されています。たとえば、臨床医は患者記録へのアクセス権を持ち、クリアランスを受けた従業員はCUIリポジトリへのアクセス権を持ち、ファイナンシャルアドバイザーは顧客ポートフォリオへのアクセス権を持ちます。ロールはプロビジョニング時に割り当てられ、アクセス権はロールに従って付与されます。このモデルは、職務内容が安定しており、勤務時間が限定されている人間にとっては十分に機能します。
AIエージェントには安定した職務内容がありません。AIエージェントは特定のタスクのために導入され、可変的なデータスコープを横断し、マシンの速度で実行され、同時に多数の並列ワークフローインスタンスを動作させることもあります。「臨床ドキュメント作成エージェント」ロールがPHIリポジトリへのアクセス権を与えても、この特定のエージェントインスタンスが、特定の臨床医から委任された、特定の患者の特定の記録3件に対し、特定のドキュメント作成タスクのため、現在のセッション終了時までアクセスを許可されていることまでは表現できません。RBACは前者のタイプのアクセスに適しており、ABACは後者のために設計されています。
本記事では、2つのモデルのアーキテクチャ上の違い、エージェント環境でRBACが機能しなくなる理由、そしてAIエージェントのデータアクセスにおいてHIPAA、CMMC、その他の規制フレームワークが求める要件を満たすのは属性ベースアクセス制御（ABAC）モデルである理由を解説します。
要約
主なポイント：RBACは「誰か」というユーザー属性に基づいてアクセス権を割り当てます。ABACは「誰か」「何をしようとしているか」「どのデータを要求しているか」「現在のワークフローの状況」など、複数の属性を同時に評価し、リクエストごとにアクセス権を決定します。職務が安定している人間ユーザーには、シンプルなRBACモデルで十分な場合が多いですが、動的なタスクスコープで大規模に動作するAIエージェントには、RBACだけではオペレーションレベルで最小限必要なアクセス権を強制できません。ABACなら可能です。
なぜ重要なのか：HIPAAの最小限必要性原則、CMMCのAC.2.006、NIST 800-171の3.1.2はいずれも、「ユーザーのロールが一般的に許可する範囲」ではなく、「特定の認可されたタスクに必要な範囲」にアクセスを限定することを求めています。AIエージェントの場合、これらの要件を満たすには、リクエストごとに状況を評価するポリシーモデルが必要です。RBACはこれを実現できません。RBACだけで管理されたAI導入では、ロール設計がどれだけ優れていても、これらの要件を構造的に満たすことができません。
主なポイント
- RBACはロールに基づいてアクセスを付与し、ABACは評価されたコンテキストに基づいてアクセスを付与します。違いはアクセス決定のタイミングです。RBACはプロビジョニング時に決定し、ABACはリクエスト時に「誰が、何を、なぜ、どのような状況で」要求しているかをすべて考慮して決定します。
- 最小限必要なアクセス権は、RBACだけではオペレーションレベルで強制できません。ロールはアクセスのカテゴリを付与しますが、「この特定のレコードに対するこの特定の操作が、現在のワークフローの認可範囲内かどうか」を評価できません。その評価には属性が必要であり、ABACがそれを実現します。
- AIエージェントは、RBACの限界を構成上の問題ではなく構造上の問題にします。人間ユーザーの場合、過剰な権限のロールは厳格なプロビジョニングで緩和できますが、AIエージェントが高速かつ大量のインタラクションを行う場合、ロールレベルのアクセスとタスクレベルの認可のギャップは単なるポリシーの問題ではなく、ロール設計をいくら見直しても解消できないシステム的なコンプライアンスリスクとなります。
- ABACとRBACは排他的ではありません。規制環境に最適なアクセス制御アーキテクチャは両者を組み合わせて使います。RBACはエージェントタイプごとにアクセスの外枠を定め、ABACはその枠内で各操作ごとに個別の認可を強制します。RBACが「天井」を設定し、ABACが「現場」で細かく制御します。
- ABACは委任チェーンを実際に機能させる仕組みです。エージェントAがユーザーBからタスクCの実行を認可されたという情報があっても、アクセス制御レイヤーがその認可を各データリクエスト時に評価できなければ意味がありません。ABACは委任チェーンを読み取り、すべてのアクセス決定にリアルタイムで適用するポリシーエンジンです。
RBACの仕組みとAIエージェントにおける限界
ロールベースアクセス制御（RBAC）は、権限をロールに割り当て、ロールをユーザーやシステムに割り当てます。たとえば、臨床ドキュメント作成エージェントには「PHI読み取り」ロールが割り当てられ、患者記録システムへの読み取りアクセス権が付与されます。CUI処理エージェントには「CUIリポジトリアクセス」ロールが割り当てられます。割り当てはプロビジョニング時に行われ、アクセス権は自動的に付与されます。
人間の臨床医の場合、このモデルは機能します。臨床医のロールは職務内容を反映し、付与されるアクセス権はその職務に広く適合し、実際に何にアクセスするかは人間の専門的判断に委ねられます。人間の職務内容は安定しており予測可能なため、ロールは認可されたアクセスの合理的な代理となります。
AIエージェントの場合、同じモデルでは異なる結果になります。「PHI読み取り」ロールは、エージェントにロールがカバーするすべての患者記録への読み取りアクセス権を与えますが、現在のタスクに関連する記録だけには限定されません。「CUIリポジトリアクセス」ロールも、現在のワークフローで必要な特定の文書だけでなく、リポジトリ全体へのアクセス権を与えます。ロールは、エージェントがその時点で実際に認可されている内容を大まかにしか表現できません。しかもエージェントは多数の並列ワークフローを高速で処理するため、過剰アクセスの累積は単なる誤差ではなく、デプロイメントのデフォルト状態となります。
自社のセキュリティを信じていますか？本当に証明できますか？
Read Now
AIエージェントにおけるRBACが生む3つのコンプライアンスギャップ
| ギャップ | 現れ方 | 違反するフレームワーク要件 |
|---|---|---|
| スコープの過剰許可 | エージェントロールがリポジトリ全体へのアクセスを許可しているが、タスクで必要なのは3件の記録のみ。エージェントは技術的には数千件の記録にアクセス可能だが、現時点での認可はない。 | HIPAA最小限必要性（§164.502(b)）；CMMC AC.2.006；NIST 800-171 3.1.2 |
| 操作種別の盲点 | ロールが「PHI読み取り」アクセスを許可しても、記録の閲覧・ダウンロード・移動・転送の区別はしない。要約タスクを実行するエージェントも、データ抽出タスクを実行するエージェントも同じアクセス権を持つ。 | CMMC AC.2.006；NIST 800-171 3.1.1 および 3.1.2 |
| コンテキスト非感知 | ロールはワークフローの状況、時間帯、データの機微度、リクエストエージェントが有効な委任を持っているかどうかなどを考慮しない。状況にかかわらずアクセス権は同じ。 | NYDFSセクション500.7；SEC監督義務；NIST 800-171 3.1.3 |
ABACがRBACの限界をどう解決するか
属性ベースアクセス制御（ABAC）は、リクエスト時に複数の属性を同時に評価するポリシーに基づき、アクセス可否を決定します。ポリシーは静的な割り当てではなく、「誰が」「どのリソースに」「どんな操作を」「どんな環境で」行うかを条件式としてまとめ、許可または拒否を返します。
AIエージェントによるデータアクセスリクエストの場合、ABACのポリシー評価は以下のようになります：
| 属性カテゴリ | 評価される属性 | 例 |
|---|---|---|
| サブジェクト（エージェント） | エージェントID、認証済みワークフロー認証情報、人間の認可者、委任の有効期限 | エージェント：doc-agent-4471；認可者：Dr. Chen；認証有効期限：17:00まで |
| リソース（データ） | データ分類、記録ID、機微度、適用規制 | 分類：PHI；記録：Encounter #4471；機微度：高 |
| アクション（操作） | 操作種別、委任範囲内かどうか | 操作：読み取り；委任範囲：読み取りのみ |
| 環境（コンテキスト） | 時間、ワークフロー状況、当セッション内の過去の操作、異常シグナル | 時間：認可ウィンドウ内；異常フラグなし；セッション進行中 |
4つすべての属性評価を通過したリクエストのみ許可されます。いずれか1つでも失敗すれば拒否され、その理由となった属性とともにログに記録されます。これが、HIPAAの最小限必要性原則やCMMC AC.2.006が求める「オペレーションレベルでのアクセススコープ管理」です。つまり「このエージェントタイプがPHIにアクセス可能か？」ではなく、「この特定のエージェントインスタンスが、この特定の認可のもと、今この瞬間にこの特定の記録に対してこの特定の操作を実行することが許可されているか？」を評価します。
委任チェーンのポリシーエンジンとしてのABAC
ここで、ABACとPost 11で説明した認証済みエージェントIDが結びつきます。委任チェーンは「誰が、何を、誰に、どの範囲で、どんな制約で」委任したかという認可情報を確立します。ABACは、その委任情報を読み取り、すべてのデータリクエストにリアルタイムで適用する強制メカニズムです。ABACがなければ、委任チェーンは単なる記録に過ぎず、監査には役立ちますが制御としては機能しません。ABACがあれば、委任チェーンは生きたポリシーとなり、エージェントのすべてのリクエストが現在の認可条件に照らして評価され、逸脱したリクエストはアクセス前にブロックされます。
RBAC＋ABAC：推奨アーキテクチャ
RBACを完全にABACに置き換える必要はなく、推奨もされません。RBACは明確で監査可能な外枠を提供します。たとえば「臨床ドキュメント作成」エージェントタイプは、どんな認証情報があっても財務データにはアクセスできません。このようなカテゴリ除外はロールで効率的に表現・強制できます。しかし、RBACだけではその枠内でのオペレーションレベル・コンテキスト認識・タスク特化のスコープ管理はできません。それがABACの役割です。
推奨されるアーキテクチャは、RBACが各エージェントタイプの外部アクセス境界を定義し、ABACがその枠内で各操作ごとに委任チェーンを参照して認可を強制します。RBACで拒否されたリクエストはABAC評価に進みません。RBACを通過したリクエストも、アクセス許可前にABACポリシーで再評価されます。どちらか一方だけでは不十分であり、両者を組み合わせることで、カテゴリレベルのアクセスガバナンスとオペレーションレベルのコンプライアンス強制の両方を実現します。
KiteworksがAIエージェントアクセス制御にABACを実装する方法
Kiteworksのプライベートデータネットワークは、RBAC/ABACの複合アーキテクチャでアクセス制御を実現しており、データポリシーエンジンがすべてのAIエージェントのデータリクエストに対するABAC評価レイヤーとして機能します。
エージェントが規制対象データへのアクセスを要求すると、データポリシーエンジンは4つの属性カテゴリ（エージェントの認証済みIDと委任チェーン属性、要求データの分類と機微度、要求される具体的な操作、時間・セッション状態・異常シグナルなどのワークフローコンテキスト）を同時に評価します。4カテゴリすべてが許可と評価された場合のみアクセスが許可され、いずれか1つでも拒否された場合は、完全な属性情報とともに拒否がログに記録されます。
この評価はデータ層で行われ、モデルとは独立しています。エージェントの挙動を変えるモデルアップデートや、リクエストを誘導するプロンプトインジェクション、システムプロンプトの設定ミスがあっても、ポリシー評価を上書きすることはできません。データポリシーエンジンはモデルの指示を解釈せず、リクエストをポリシーに照らして評価します。ガバナンスはモデルが到達できない層で強制されます。
その結果、Kiteworksは、記録レベルでのHIPAA最小限必要性原則、オペレーションレベルでのCMMC AC.2.006、AIエージェントによるCUI操作に関するNIST 800-171の3.1.1〜3.1.3の各要件を満たし、すべての許可・拒否判断を完全かつ改ざん検知可能な監査証跡として組織のSIEMに直接連携します。
AIエージェントに対してオペレーションレベルのアクセス制御（単なるロールレベルのアクセス管理ではなく）が必要な規制対象組織には、Kiteworksがその実現を可能にするアーキテクチャを提供します。KiteworksのコンプライアントAIについて詳しく知るか、デモを申し込むことができます。
よくある質問
HIPAAの最小限必要性基準は、PHIへのアクセスを「特定の認可された目的を達成するために必要最小限」に限定することを求めています。ロールはアクセスのカテゴリを付与しますが（例：エージェントがPHIを閲覧できる）、進行中の特定タスクに必要な特定の記録かどうかまでは評価しません。リソース・操作・ワークフローコンテキストをリクエストごとに評価するABACだけが、HIPAAが求める記録・操作レベルでの最小限必要性アクセスを強制できます。
CMMC AC.2.006は、認可されたユーザーが実行できるトランザクションや機能の種類にアクセスを限定することを求めています。つまり、ロールがカバーするデータカテゴリだけでなく、操作レベルでの最小限必要性強制が必要です。CMMC評価者がAIエージェントのCUIアクセスを評価する際は、「エージェントは閲覧のみ可能でダウンロードは不可か？」「隣接フォルダへのアクセスは不可か？」といった細かい証拠を求めます。ロールベースの「CUIアクセス」だけではこの粒度の証跡は出せません。ABACによる操作レベルのポリシー評価なら可能であり、監査証跡も残せます。
RBACは各エージェントタイプの外部アクセス境界（ワークフローの状況に関係なく変わらないカテゴリ除外）を定義します。ABACはその枠内で、委任チェーンをポリシー入力として各操作ごとに個別の認可を強制します。RBACで拒否されたリクエストはABAC評価前に却下され、RBACを通過したリクエストもABACポリシーで再評価されます。どちらか一方が他方を置き換えるのではなく、RBACが「天井」を設定し、ABACが「現場」で操作レベルの強制を担います。
SEC規則S-PおよびNYDFSパート500はいずれも、顧客データやNPIへのアクセスを認可された目的に限定することを求めています。ABACは、リクエストごとにワークフローコンテキストを評価することでこれを実現します。例えば、四半期レビューのために顧客Aのポートフォリオへのアクセスを認可されたエージェントは、顧客Bの記録にはアクセスできず、レビュー範囲外の操作もできず、認可された時間枠外のデータにもアクセスできません。金融機関がABACを使えば、操作ごとのアクセススコープ証跡を監査用に提出できます（単なるロール割り当て記録だけでなく）。
委任チェーンは、ABACが評価するサブジェクト属性（エージェントID、人間の認可者、認可されたデータスコープ、許可操作、有効期限）を提供します。ABACは委任チェーンを制御として機能させる仕組みであり、これらの属性を読み取り、すべてのデータリクエストをリアルタイムで評価します。ABACがなければ委任チェーンは監査記録に過ぎませんが、ABACがあれば生きたアクセスポリシーとなり、すべての操作で認可条件を強制します。両者は一体となって機能し、IDが認可を確立し、ABACがそれを強制します。
追加リソース
- ブログ記事
手頃なAIプライバシー保護のためのゼロトラスト戦略 - ブログ記事
77%の組織がAIデータセキュリティで失敗している理由 - eBook
AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に - ブログ記事
あなたのデータに「–dangerously-skip-permissions」は存在しない - ブログ記事
規制当局は「AIポリシーがあるか」を問うのをやめた。今求められるのは「機能している証拠」