細粒度なアクセス制御：どこまで細かく設定すべきか？

細粒度なアクセス制御の真の意味

細粒度なアクセス制御（Fine-grained authorization）とは、判断に使用するメカニズムではなく、判定対象のサイズ（単位）に関する概念です。大粒度（Coarse）なアクセス制御が「このアイデンティティはAI Gatewayを使用できるか？」を問うのに対し、細粒度なアクセス制御は「このアイデンティティは、特定の人物のために、今この瞬間に、Linear MCP server上のdelete_issueツールを呼び出せるか？」を問いかけます。

この拡張は、それぞれ異なるコストをもたらす独立した4つの次元に沿って進みます：

アクセス制御に関する多くの解説では、これらを「セキュリティ強化」と書かれた単一のスライダーにまとめ、設定を最大に引き上げようとします。しかし、それこそが誤りです。Subject（主体）およびAction（操作）の粒度化は、ほぼコストがかかりません。グループの代わりにユーザー、まとめてパッケージ化された権限の代わりに個別の権限を1つ指定しても、レビュー時の負担は増えません。問題となり、コストが発生するのはResource（リソース）とOccasion（機会）の粒度化です。

また、粒度の設定はRBAC（ロールベースアクセス制御）かABAC（属性ベースアクセス制御）かという選択とは独立しています。単純なロール構造であってもバインディングのスコープを厳格に絞り込めば非常に細かい権限を表現できますし、逆に属性ポリシーが大粒度すぎて役に立たない場合もあります。モデルは「どのように判定するか」を決める手段であり、粒度は「何を対象に判定するか」を決定するものです。

見落とされがちな隠れたコスト

単純な計算をしてみましょう。エンジニア40名に対してゲートウェイ全体で1つの権限を付与する場合、アクセスレビューで確認すべき状態数は40個です。これを12のMCP serverに対してリソース単位でスコープ設定すると、確認事項は480個に増えます。さらに1サーバーあたり25個のツール単位まで細分化すると、12,000個のセルが存在することになります。そこに実行ごとの承認まで加えると、レビュー対象はもはやグリッド構造ではなく、イベントログそのものになってしまいます。

12,000個ものセルを個別に監査できる人間はいません。その結果、過度な細粒度化による現実的なリスクが発生します：

• モデルの運用が形骸化・簡略化される。 レビュー担当者は個別のセルのチェックをやめ、ロール名だけを確認するようになるため、その配下にある実際の権限の乖離（ドレープ）に気づけなくなります。
• 抜け道（抜け穴）が作成される。 正しい手続きを踏むために3回の承認とチケットが必要になると、広範なアクセス権を持つ共有サービスアカウントが勝手に作られてしまいます。厳重なルート上に用意されたすべての制御策は、単なる飾りと化します。
• 権限付与の累積（権限の放置）。 細粒度なアクセス権の付与は一つひとつが小さいため、付与したまま放置することへの心理的ハードルが下がります。一方で大粒度な権限は目立つため、適切に剥奪されます。
• 承認キューが形骸化する（ラバースタンプ化）。 すべての操作に承認を必須にすると、承認者は内容を読まずにクリックするだけになります。これは何も制限しない状態よりも悪質です。なぜなら、人間が同意したという署名付きの記録だけが残ってしまうからです。

したがって、制約となるのは「回答可能性（Answerability）」です。どの階層にあっても、バックグラウンド処理を実行することなく、次の3つの質問に即答できなければなりません：このリソースに誰がアクセスできるか、何を実行できるか、最後に実行したのはいつか。この原則が崩れた場合、視認性と引き換えに精度の高さを買っただけに過ぎなくなります。

これが、最小権限の原則（Least privilege permissions）と「粒度の最大化」が同一の目標ではない理由でもあります。最小権限とは、業務に必要な権限以上を与えないことであり、システムが許す限り細かく切り刻むことではありません。ある業務に必要な7つの権限のみを正確に保持するロールは、最小権限の原則に叶っています。しかし、同じ権限範囲に到達するために700個の個別の権限付与を行うのは、単に運用コストを増大させるだけです。

アクセス制御の粒度ラダー（階層構造）

粗いものから細かいものまで4つの階層があり、それぞれが固有の役割を持っています。原則として、リスクをコントロールできる最も低い階層にとどめる必要があります。

単なるメニューの選択肢ではなく「段階的なラダー」と呼ぶ理由は、2つの特性にあります。

階層は下方向へ構成され、横並びには機能しません。 階層3（ツール単位）は、階層2（リソース単位）を通過したアイデンティティに対してのみ意味を持ちます。また、無効化されたツールは、どのようなロールを保持していてもアクセスできません。大粒度の階層で寛容に設定し、細粒度の階層で厳格に制御しても、その厳格さは有効に機能します。

各階層によって記録の形状が異なります。 階層1と2は、人間が読み取る一覧テーブルです。階層3は前四半期と比較（diff）するリストです。階層4はサンプリングして調査するログです。階層4を一覧テーブルのように扱おうとすると、誰も全容を要約できない200ものポリシーを抱え込む結果になります。

チームが陥りがちな過ち

階層2の役割を果たすために階層1を使ってしまう。 最も頻繁に見られるミスです。特定のMCP serverが1つだけ必要な場合に、テナント全体を対象とするmcp-server:ReadMcpServerを含む権限を付与してしまうケースです。これにより、結果としてテナント内のすべてのMCP serverへのアクセスが可能になります。パーミッションのリスト自体は短いため制限されているように見えますが、実際はそうではありません。

階層2についての議論を避けるために、安易に階層4へ飛んでしまう。 承認ポリシーは判断を後回しにできるため魅力的に見えます。しかし、不適切な権限を持つ人がアクセスできてしまうツールに対してアクセス制限をかけても、開いたドアの前にゲートを置いているようなものです。まずはバインディング（権限割り当て）を正しく修復してください。

ツールレベルの切り替えスイッチを、信頼できない呼び出し元に対する境界線として過信してしまう。 ツールを無効化すると、発見（discovery）対象から除外され、呼び出しがブロックされます。これは、長いリストの中から危険なものを選択してしまう可能性のあるAgentに対しては有効です。しかし、認証情報に対する上位システム自体のパーミッション設定の代わりになるものではありません。

細かい階層の定期的な見直しを怠る。 大粒度な権限付与は目立つためレビューされますが、8か月前の単発のマイグレーションのために有効化されたツールは目につきません。ロールを監査するのと同じサイクルで、有効化されたツールのリストも定期的に監査してください。

ひとつのコンソールでこの階層構造を確認してみませんか？

ロールのスコープを単一のリソースに設定し、その上のツールを1つ無効化する手順は、全体で約5分しかかかりません。

無料で試してみる

TrueFoundryにおける各階層の仕組み

TrueFoundryはこれら4つの階層すべてを実装しています。Subject（主体：ユーザー、チーム、Virtual Account、Agent） ＋ Resource（リソース） ＋ Role（ロール） の組み合わせがRole Binding（ロールバインディング）を形成します。これはリソースの設定とは独立して管理されるため、再デプロイすることなくアクセス権を変更できます。

階層1 — テナント全体の機能権限

3つのテナントロールが標準で組み込まれています：Admin（フルコントロール、編集不可）、Member（編集可能な既定のベースライン）、および Read-Only Member（読み取り専用、固定）。

これらが大まかすぎる、あるいは限定的すぎる場合は、Access > Custom Roles からカスタムロールを作成できます。このカタログは細粒度なアクセス制御の中核をなします。各エントリーはリソースタイプごとにグループ化された resource:Action キーであり、設計を開始する前にどのような粒度が存在するかを確認できます。

MCP serverの作成と管理は別々のキーになっています。このように分離されていることで、アクセス制御モデルの設計において実用的な解像度（精度）が得られます。

この階層には1つのルールが存在します：カスタムロールのパーミッションは、選択されたタイプのすべてのリソースに適用されます。 単一のリソースに対して権限を設定する場合は、そのリソースの Access Control ページを使用してください。この適用関係を誤ると、前述した「階層2の役割を階層1で行ってしまう」失敗に陥ります。

階層2 — リソース単位のロール

リソースの3点リーダーメニューを開き、Access Control を選択します。

Subject（主体）とRole（ロール）を選択します。ドロワーには各ロールに含まれるアクションが一覧表示されるため、付与内容をあらかじめ確認できます。

ロールの種類は対象リソースによって異なります：Provider Accountの場合は Manager および User、MCP serverの場合は MCP Server Manager、MCP Server User、および MCP Server Approver、Agentの場合は Agent Manager および Agent Access、ClusterおよびWorkspaceの場合は Admin、Member、Viewer の各階層が用意されています。個々の人物ではなくチームに対して付与する方が効率的です。将来参加するメンバーがアクセス権を継承できるだけでなく、付与状況のテーブルを短く読みやすい状態に維持できます。MCP Access Control モデルはこの階層の上に構築されています。

階層3 — リソース内のツール単位

この階層は、チームが最後に到達する段階であり、Agentにとって最も必要とされるものです。RemoteまたはTrueFoundry管理下のMCP serverでは、Tools タブを使用して呼び出し可能なツールを個別に制御します。

無効化されたツールは tools/list のレスポンスから除外され、実行することができません。 この両方が重要です。モデルは可視化されていないものを選択できず、万が一呼び出しが試みられた場合でもゲートウェイがそれを拒否します。

Enable new tools by default のトグルスイッチは基本方針を決定するものであり、重要な設計上の選択肢となります。オンにすると拒否リスト（デニィリスト）として機能し、新しく追加されたベンダーツールが自動的に使用可能になります。オフにすると許可リスト（アロウリスト）となり、新しい上位ツールは手動で有効化されるまで非表示に保たれます。本番環境に接続するリソースにおいては、許可リスト形式が適しています。

Edit Tool では、より細かな設定が可能です。説明文のオーバーライドに加えて、MCP Tool Annotations を None、Read-only、または Destructive に設定できます。これにより、readOnlyHint または destructiveHint が割り当てられます。

このアノテーションは階層4が読み取るラベルとなるため、一度分類設定を行えば、ツール名を二重に定義することなく継続的なポリシー運用が可能になります。

階層4 — 実行（呼び出し）ごとの承認

ツール承認ポリシーは、制限された tools/call をゲートウェイで保留し、承認待ちリクエストを作成して承認者に通知します。その間、ツールは実行されません。一度承認されると、指定された有効期間内は呼び出しが成功し、有効期限が切れると再度新たな承認が必要になります。

粒度は2つの設定項目（ダイヤル）によって決定され、どちらにも明確に文書化された優先順位ルールが存在します：

アクセス権限はリクエスト実行者、特定のサーバー、およびツールに紐づけられてスコープ設定され、ユーザー間で共有されることはありません。承認者は、ツール、ポリシー、リクエスト実行者、有効期間、およびツールの引数が表示される Pending Requests（保留中のリクエスト）一覧から作業を行います。

このプロセスにおける権限自体も階層ごとに分離されています。ポリシーの作成、更新、削除が行えるのはテナント管理者のみです。承認または拒否を行うには、テナント管理者権限、または該当サーバーの Collaborators リストから追加された MCP Server Approver ロールが必要です。

ポリシーで指定されたサーバーに Approver の権限を持つ協働者が設定されていない場合、テナント管理者のみしか判断を行えなくなります。これは、すべての承認作業が特定の数人に集中してしまう原因となります。

注意点として、拒否（Denial）は完全なブロックを意味しません。拒否された事象は記録されますが、次回の呼び出し時には再び新しいリクエストが作成されます。アクセスを永続的に停止するには、ラダーを一段降りて、該当サーバーへのSubjectのアクセス権を削除するか、ツール自体を無効化してください。階層4は権限そのものではなく、「特定の機会・タイミング」を制御するためのものです。

具体的な適用例：Secret Groupにおける参照権限と使用権限の分離

Secret Group（シークレットグループ）は、操作（Action）の粒度を細分化する価値が最も分かりやすく現れる例です。なぜなら、値そのものを確認することと、それに依存して処理を実行することを明確に分離できるからです。

Secret Groupは関連するシークレットを整理し、シークレット個選ごとではなく一括でアクセス管理を行えるようにします。シークレットを保存すると、その値は運用環境のシークレットマネージャー（AWS SSM、GCP Secret Manager、HashiCorp Vault、Azure Vaultなど）に書き込まれ、TrueFoundryには完全修飾名（FQN）のみが保存されます。このFQNは、デプロイ、ボリュームマウント、インテグレーション、ゲートウェイのモデルAPIキーなどから参照されます。

この間接参照の仕組みにより、FQNを使用してシークレットを利用するデプロイメントは、人間がその実際の値を読み取る必要がありません。これにより、以下の明確な権限分離が意味を持つようになります：

この Viewer の設定が大きなメリットをもたらします。担当者は、画面上に実際の値を表示させることなく、「ここに stripe-live-key が存在する」という事実だけを確認できます。これだけでプロジェクトの依存関係をレビューするには十分です。権限カタログでも同様の分離が明示されています：secret-group:ReadSecretGroup はグループの表示、secret-group:ReadData は値の読み取りを制御します。キーが分かれているため、カスタムロールを作成する際に一方のみを付与することが可能です。

なお、実際の仕様にはいくつかの補足点があります。テナント管理者はデフォルトですべての Secret Group にアクセスできますが、メンバーやチームに対してはグループごとに個別でロールを割り当てる必要があります。また、リソースロールのリストには Admin、Editor、Viewer のほかに4つ目のロールとして Secret Group Access が存在します。ただし、シークレット管理ページには前述の3つのみが記載されているため、この4つ目のロールが何を許可するかについての安易な断定は避けます。運用プロセスを構築する前に、実際のコンソール画面で確認してください。

このパターンは他のリソースにも共通します。リソースに「メタデータ（説明）」と「ペイロード（中身）」の両方が存在する場合は、それぞれをカバーする別々のキーを探してください。リポジトリ管理にも同様の ReadRepository と ReadData の分離が存在します。単に情報を確認するだけで十分な場合は、ペイロード権限を与えずにメタデータ権限のみを付与してください。

参照権限と使用権限を分離する準備はできましたか？

Secret Group を作成してチームメンバーに Viewer 権限を割り当て、実際の実効値が隠蔽されたまま維持される様子をご確認ください。

TrueFoundry を無料で試す

知っておくべき注意点（ハマりどころ）

付与された権限は合成され、一方を削除しても他方は残り続けます。 Subjectは直接アクセス権を付与されていると同時に、チーム経由で権限を継承している場合があります。TrueFoundryは両方を結合して評価するため、直接の権限付与を取り消しても、継承されたアクセス権はそのまま残ります。必ず両方の設定を確認してください。粒度を細かくするほど、小さな権限付与が増えて確認すべき場所が多くなるため、この点への注意が必要です。

チームのデフォルトロールを変更すると、すべてのチームに影響が及びます。 Team Member および Team Manager は Access > Default Roles から編集できますが、この変更は全体に適用されます。特定の1つのチームがトークンを取得できるように virtual-account:ManageVirtualAccount を追加すると、すべてのチームにその機能が付与されてしまいます。利用者は自身のチーム内に限定されますが、機能自体は広がってしまいます。これは「階層2の見た目をした階層1の変更」にあたります。

承認待ちの状態はエラーではなく、成功レスポンスとして処理されます。 リクエストが保留中の間、ゲートウェイは isError: false かつ _meta.approval_status: "pending" を含む JSON-RPC レスポンスを返し、呼び出し元に待機を促すテキストを含めます。エラー判定のみを行うAgentは、これをツールからの正常な実行結果とみなして処理を継続してしまう可能性があります。_meta.approval_status を確認し、再試行を行うロジックを実装してください。

関連トピック

• MCP Access Control: Securing AI Agents with an MCP Gateway — Agentツールにおける階層2と3の活用
• What Is MCP Authorization? — ツールの呼び出しに判定が届く仕組み
• Enterprise MCP Access Control — 多数のサーバーにわたって階層の視認性を維持する方法
• API Auth and RBAC in the AI Gateway — トラフィックに対して権限が適用される場所
• Virtual MCP Servers — 複数のサーバーから調整されたツール領域を構築する手法

まとめ

細粒度なアクセス制御は、単に「設定を厳しくするスライダー」として語られがちです。しかし実際には、意図を持って登るべき階層構造（ラダー）であり、プラットフォームの機能限界まで細かくするのではなく、リスクの増加が止まった時点で階層を登るのを止めるべきものです。

それぞれの階層は異なる問いに対応しています。テナント全体の機能権限は「実行可能か」、リソース単位のロールは「どこで実行可能か」、ツールレベルのパーミッションは「どの操作が存在するか」、実行ごとの承認は「今、この呼び出しを実行すべきか」を問います。この順序に従うことで、各階層が直前の階層を制限し、全体としての可読性を維持できます。

順序を誤ると — 広すぎる権限バインディングを呼び出しごとのゲートで保護したり、リソースごとの付与の代わりにテナント全体のロールを使用したりすると — 構成図上は厳密に見えても、監査時に説明がつかないモデルになってしまいます。最も細かく設定されたアクセス制御モデルが、必ずしも最適なモデルとは限りません。自らの言葉で第三者に明確に説明できる「最も適切な粒度のモデル」こそが、真に優れたモデルです。

TrueFoundry で最初の Agent のスコープを設定してみましょう

無料ですぐに始める