RBAC対ABAC：AIエージェントのアクセス制御モデルの選択

RBACの実際の姿

ロールベースのアクセス制御（RBAC）は、人間と権限の間に名前付きのレイヤーを配置します。「シークレットグループの参照」権限をPriyaに直接付与するのではなく、「シークレットグループ閲覧者」というロールを定義してその権限を含め、Priyaをそのロールに割り当てます。

ロールベースのアクセス制御モデルは、3つの要素で構成されています。

その価値は「間接参照」にあります。セキュリティチームが「閲覧者はシークレット値を参照すべきではない」と決定した場合、1つのロールを編集するだけで、すべての閲覧者の権限が一度に変更されます。NISTは何十年も前にこのモデルを正式化しました。そのため、すべてのクラウドコンソールにロールページが存在します。

弱点もまた「間接参照」です。ロールは静的なセットです。権限を企業IPからのみ適用したい場合や、リクエスタ自身のリージョンのレコードにのみ適用したい場合、通常のRBACでは表現できません。チームはこれに対して、analyst-eu、analyst-eu-readonly、analyst-eu-readonly-prodといったロールを大量に作成して対応します。これがロールの爆発（role explosion）であり、人々がABACを検討する最大の理由です。

ABACの実際の姿

属性ベースのアクセス制御（ABAC）は、名前付きのセットを排除します。主体がどのロールを保持しているかを問い合わせる代わりに、リクエスト時に4つの属性カテゴリにわたってポリシー式を評価します。

ポリシーの例：subject.department == resource.owning_team かつ resource.classification != "restricted" かつ env.network == "corp" の場合に読み取りを許可する。NIST SP 800-162は標準的なドキュメントです。実践的には、ABACは認可サービスの後ろでXACML、Rego、Cedarなどのポリシー言語として提供されます。

ABACは確かに表現力に優れています。適切に記述された1つのルールで数百のロールを置き換えることができ、RBACではまったく記述できない関係性（例：「この患者を担当する医師」）を処理できます。

しかし、その表現力には代償があります。ポリシーはコードであり、レビュー、テスト、バージョン管理、ルール相互作用の解釈が必要です。そして監査人が最初に尋ねる質問——「誰がこのデータを読めるのか？」——に対する直接的な回答が得られなくなります。すべての主体を列挙し、それぞれに対してポリシーを評価しなければなりません。このため、一部のエンジンには逆引きクエリツールが用意されていますが、ほとんどの導入環境では使用されていません。

RBAC対ABACの比較一覧

表には現れない注意点があります。ABACには前提条件として、信頼できる属性が必要です。resource.data_region に基づくポリシーの精度は、そのフィールドを入力するタグ付けルールと同じレベルにとどまります。ABACを試すほとんどの組織は、認可の問題に直面する前に、タグ付けされていないデータの問題に直面します。また、この2つのモデルは排他的ではありません。運用環境での一般的な構成は、骨組みとしてRBACを使用し、その上に少数の属性条件を重ねる形です。

多くのチームが陥る誤り

ロールの爆発をモデル変更の理由にすること。 ロールの爆発は通常スコープ設定のバグであり、モデルの欠陥ではありません。analyst-team-a、analyst-team-b、analyst-team-c が存在する場合、必要なのは属性ではなく、各チームのリソースに個別にバインドされた1つの analyst ロールです。RBACで発生する問題の多くは、本来単一のリソースにバインドすべきものを、テナント全体に許可を付与してしまうことから生じます。

監査できない表現力を採用すること。 ABACを使用すると、コンプライアンスチームが解読できないルールを書くことができます。そのトレードオフが有益な場合もありますが、意図せず導入すべきではありません。ポリシーエンジンを導入する前に、来四半期のアクセスレビュー質問票に誰がどのように答えるかを考えてください。

権限が付与の組み合わせであることを忘れること。 主体は直接アクセス権を保持することも、チームを介して継承することもあり、一方を削除しても他方は削除されません。ポリシーエンジンが上に重なっている場合、2つのシステムが独立して付与を行う可能性があるため、状況はさらに悪化します。

人間には権限を設定し、エージェントを無視すること。 構築されたエージェントがテナント全体のアクセス権を持つ共有サービストークンで実行されている場合、人間側のすべての管理設定は意味をなしません。

スコープ制限されたアクセスの実際の動作を確認してみませんか？

TrueFoundryを起動して、テナント全体ではなく単一のリソースにロールを付与してみてください。所要時間は約2分です。

無料で始める

AIエージェントがABACの適用例に見える理由

AIエージェントは、実効的な権限が固定されていない非人間の主体（サブジェクト）です。あるターンではパブリックリポジトリを読み取り、次のターンでは顧客レコードに触れるかもしれません。異なる時間帯に異なる人物の代わりに動作します。その入力は敵対的（アドバーサリアル）である可能性があり、悪意のあるIssue本文によって呼び出すべきでないツールへと誘導されることがあります。そして人間に反して、そのアクションが賢明かどうかを立ち止まって考えることはありません。

これを要件として書き出すと、まさにABACの仕様そのものです：実行ユーザーがターゲットへのアップストリームアクセス権限を持ち、ツールが破壊的ではなく、リクエストが信頼できないコンテンツから発生していない場合に、このツール呼び出しを許可する。 3つの属性、1つのルール。では、なぜ実際に運用されているシステムでほとんど採用されていないのでしょうか？

判定時に属性を確実に取得できないからです。「このリクエストが信頼できないコンテンツから発生したか」は単純なフィールドではなく、研究段階の課題です。「実行ユーザーがアップストリームアクセス権限を持っているか」は確認可能ですが、最も低コストで正確に確認する方法は、そのユーザーの権限モデルをポリシーエンジンに複製して更新し続けることではなく、そのユーザー自身のクレデンシャルを使ってアップストリームシステムを呼び出し、処理させることです。

また、監査可能性のコストはエージェントが動作する環境で最も重大になります。エージェントの権限はセキュリティレビューで最も厳しく問われる項目であり、「ポリシーの評価結果がこれらの条件化で許可になる」という回答は、「このエージェントがこれら3つのサーバーでMCP Server Userを保持している」というテーブル表示よりもはるかに不十分な回答となります。

つまり、エージェントには人間よりも狭いアクセス権限と、人間よりも検査しやすい（透明性の高い）アクセス権限が必要です。ABACは前者を提供しますが、後者を損ないます。そのため、厳格なリソーススコープ設定を持つRBACに、コンテキストが真に重要な少数のコンテキストゲートを追加した構成が導入パターンとなっています。

TrueFoundryでの動作モデル

TrueFoundryは、リソーススコープ指定のロールバインディングを備えたRBACを実装しています。ABACポリシーエンジンではないことを明確にしておく価値があります。このモデルは「誰が、どこで、何ができるか？」という1つの問いに答えます。

• 主体（Subject）はアクセスを受けるアイデンティティです：ユーザー、チーム、バーチャルアカウント、またはエージェント。
• リソース（Resource）はアクセスされる対象です：モデルプロバイダーアカウント、MCPサーバー、エージェント、クラスター、ワークスペース、リポジトリ、またはシークレットグループ。
• ロール（Role）は許可されたアクションの名前付きセットです。

リソースに対して主体にロールを割り当てると、ロールバインディングが作成されます。アクセス権はリソースの設定とは独立して管理されるため、何も再デプロイすることなくアクセス権限を持つ人物を変更できます。

権限付与はリソース自体から行います。3点リーダー（...）メニューを開き、Access Controlを選択します。

次に、1つ以上の主体とロールを選択します。ドロワーには各ロールに含まれるアクションが一覧表示されるため、付与する前に付与内容を確認できます。

提供されるロールはリソースタイプによって異なります：モデルプロバイダーアカウントではManagerとUser、MCPサーバーではMCP Server Manager、MCP Server User、MCP Server Approver、エージェントではAgent ManagerとAgent Access。クラスター、ワークスペース、シークレットグループには、それぞれのadmin、member、viewerティアが用意されています。

1つではなく3つのスコープ

ロールは3つのスコープで動作します。これらを正確に区別して運用することが重要です。

AdminおよびRead-Only Memberは編集できません。Memberは編集可能です。これはすべてのユーザーが保持するベースラインであり、デフォルトでは cluster:ReadCluster、environment:ListEnvironments、settings:ListSettings、user:ListUsers、repository:CreateRepository、secret-group:CreateSecretGroup、agent:CreateAgent のみが含まれます。個別のモデル、MCPサーバー、ワークスペースには適用されず、これらはリソースバインディングまたはチームメンバーシップから提供されます。

チームロールは、本モデルの中で属性条件に最も近いものであり、その類似性は有用です。Team Memberは virtual-account:ReadVirtualAccount を含みますが、これはユーザーが実際に所属するチームが所有する Virtual Accounts にスコープ指定されています。権限自体は全員に対して同一ですが、アクセスできるオブジェクトのセットが人によって異なります。

これは所有権スコープ設定であり、ABACではありません。ポリシー式も属性評価もなく、チームと所有物の間の固定された関係にすぎません。これにより、人々が属性を必要とする一般的なユースケースをカバーしつつ、可読性を維持できます。

きめ細かな権限のためのカスタムロール

組み込みのテナントロールが広すぎる、または狭すぎる場合は、権限カタログから独自のロールを作成します。すべての権限は リソース:アクション の形式に従い、リソースタイプごとにグループ化されています。

これを使用する際には、1つのルールに従います：カスタムロール権限は、選択したタイプのすべてのリソースに適用されます。 mcp-server:ReadMcpServer を持つカスタムロールは、選択された特定のものだけでなく、すべてのMCPサーバーに適用されます。単一のリソースに限定したい場合は、代わりにそのリソースのAccess Controlページを使用します。これを誤ると、単一のサーバー用であったロールが意図せずテナント全体の参照アクセス権限になってしまいます。

精密に指定されたコンテキストゲート

TrueFoundryは4つの場所でコンテキスト感度を追加します。これらはいずれも属性ポリシーではなく、それぞれ検査可能です。

2つ目のメカニズムは、人々がABACに期待する処理の多くを果たします。エージェントがユーザーごとのOAuthを介して特定のユーザーのためにツールを呼び出すと、アップストリームサービスはそのユーザーの実際の権限を評価します。ポリシーエンジン内にGitHubのリポジトリACLをモデル化する必要はありません。それらを所有するシステムに委任しているため、そのコピーが古くなることはありません。MCPアクセス制御モデルは、この構造の上に構築されています。

制限事項：Virtual Accountトークンは、すべてのリクエストに同一のアクセス権を付与します。これらはサービス間呼び出しに適しており、ユーザーごとの権限が重要な場合には適していません。

2つのアプローチによる具体例

ドキュメントからの2つの実際のシナリオは、モデルが逆方向から機能することを示しています。

監査人に参照専用アクセス権を付与する。 Access > Users から Read-Only Member を割り当てます。これは組み込みのテナントロールであり、サポートされているリソースタイプ全体に参照専用アクセス権を提供し、編集することはできません。意図せず範囲を広げられるような監査ロールは監査ロールとして機能しないため、これがポイントになります。監査人のグループに対してはチームに割り当て、将来の参加者がそれを継承するようにします。監査人に特定のリソースのみを表示させたい場合は、テナントロールを完全にスキップし、各リソースで viewer または access ロールを付与します。

管理者権限を与えずにMCPサーバーの作成を許可する。 サーバーの作成には Member が持っていない権限が必要なため、管理者権限（Admin）を付与したくなります。代わりに、mcp-server:CreateMcpServer のみを厳密に含むカスタムロールを作成します。

次に、Access > Users または Access > Teams から割り当てます。

この挙動が重要なポイントです。Create MCP Server は新しいサーバーを作成できるようにします。既存のサーバーへのアクセス権を付与するものではありません。サーバーを作成した後、所有者はそのサーバー自体の Access Control ページから自分自身に MCP Server Manager を付与します。

作成権限とアクセス権限は分離されており、互いに漏洩することはありません。ABACポリシーでも同じ内容を表現できますが、確実を期すためにルールを注意深く読み込む必要があります。ここでの設定は2つのテーブルの2行にすぎません。このパターンはスケールダウンも可能です：Admin権限なしで全員にゲートウェイコントロールの表示を許可するには、Member を編集して gateway-controls:ListGatewayControls を追加します。

最初のエージェントのスコープを設定する準備はできましたか？

カスタムロールを作成し、それを1つのMCPサーバーにバインドして、エージェントがアクセスできる範囲を正確に確認してみましょう。

TrueFoundryを無料で試す

知っておくべき注意点

権限付与は組み合わされ、一方を削除しても他方は削除されません。 主体は直接アクセス権を受けることも、チームメンバーシップを通じて受けることもできます。誰かがまだリソースを参照できる理由を調べる際は、直接のバインディングとチームから継承されたすべての権限の両方を確認してください。これは常に最初に調べるべきポイントです。

チームのデフォルトロールを編集すると、すべてのチームに対して変更が適用されます。 Team Member および Team Manager は Access > Default Roles の下で編集され、その編集はグローバルに適用されます。あるチームがトークンを取得できるように virtual-account:ManageVirtualAccount を追加すると、すべてのチームのメンバーにそれが付与されます。各人物は自分のチームに制限されたままですが、機能自体は全体に広がります。

テナントロールはチームテナントロールと組み合わされます。 ユーザーは直接割り当てられた1つのテナントロールを保持します。テナントロールを持つチームにも所属している場合、その実効権限は両方の和集合になります。そのため、ユーザーの実際の権限はユーザーレコード単体では確認できません。チームは手動で作成することも、SCIMを介してIdPからプロビジョニングすることも、チームYAMLで tfy apply を使用して適用することもでき、IdPのクレーム値をチームに直接マッピングできます。

関連ドキュメント

• AI GatewayにおけるAPI認証とRBAC — ゲートウェイトラフィックでこれらのロールがどのように適用されるか
• MCPアクセス制御：MCP GatewayによるAIエージェントの保護 — ツールおよびサーバーレベルの実践的な権限設定
• エンタープライズMCPアクセス制御 — 多数のサーバーやチームへのモデルの拡張
• MCP Gatewayとは：アーキテクチャとユースケース — 制御ポイントの配置場所
• AIガバナンスフレームワークの構築 — アクセス制御を取り巻く広範なポリシーの全体像

結論

RBAC対ABACの議論は、うやむやに終わることがよくあります。しかし、そうすべきではありません。アクセスが測定可能かつ信頼できる実行時コンテキストに真に依存しており、ポリシーコードを配置する場所と所有する担当者が存在する場合、ABACが適しています。それ以外のすべてについては、適切にスコープ指定されたバインディングを持つRBACが役割を果たし、人間が解読可能な状態を保ちます。

AIエージェントは例外に思えるかもしれません。実際に、人間よりも厳しいスコープ制限、共有トークンではなくユーザーごとのクレデンシャル、損害を引き起こす操作に対する人間の確認ゲートなど、適切な状態の基準を変化させます。しかし、それらのいずれもポリシーエンジンを必要としません。テナント全体ではなく個別のリソースにバインドされたロールと、実行時の適切に選択されたいくつかのチェックがあれば十分です。

それがTrueFoundryの求める実装であり、大層な名前ではなく「RBAC」と呼ぶことこそが本質です。次のアクセスレビューで「このエージェントは何にアクセスできるか？」と問われたとき、その回答は証明式ではなく、単なるリストであるべきです。

TrueFoundryで最初のエージェントのスコープを設定する

無料で始める