MCP アクセスガバナンス：誰がどのツールとデータを使えるか

MCP アクセスガバナンスとは

Model Context Protocol（MCP）を使うと、Claude Code、Cursor、Codex などの AI クライアントが、ツールを提供するサーバーを通じて社内システムに接続できます。ツールとは、チケットキューの検索、ドキュメントの読み取り、顧客レコードの更新といった機能です。ツールのリクエストはいずれも、誰かに代わってシステムにアクセスします。

アクセスガバナンスでは、ID 管理チームがあらゆるアプリケーションについてすでに確認している問いを、こうしたリクエストに当てはめます。この接続を誰が使えるのか？　各自にどのツールとデータが必要なのか？　そのアクセスを誰が認め、役割が変わったときにどれだけ早くアクセスが終了するのか？

ただし、重要な違いが一つあります。エージェントは、直前に読んだコンテンツをもとに、どのツールを呼び出し、何を送るかを決めることがよくあります。ある人がツールの利用を認められていても、エージェントがそのツールで行いうるすべてのリクエストを意図しているとは限りません。そのため、権限を絞ることと、リクエストごとの明確な記録が、通常以上に重要になります。

アクセスは複数の層で判定される

1 件のツールリクエストは、いくつものアクセス判定を通過します。それらを書き出してみると、どのシステムがそれぞれの判定を担い、どこに抜けが残っているかがわかります。

上限となるのは、接続先システム自体の権限です。ゲートウェイのルールで、ゲートウェイ経由でできることを絞り込むことはできますが、その人の認証情報が持っていない権限を与えることはできません。

すべてのリクエストを個人にひも付ける

共有の API キーは、アクセスガバナンスが破綻しやすい典型的な箇所です。全員のエージェントが 1 つのトークンを使うと、接続先システムからは 1 人のユーザーに見え、トークンを取り消せば全員に影響し、記録からは誰が何を依頼したのかがわかりません。

接続先システムへの認可は、通常は OAuth を使い、各自が個別に行う方法を優先しましょう。ゲートウェイにも、普段使っている ID プロバイダーでサインインしてもらいます。MCP の認可仕様は OAuth 2.1 をベースにしています。サーバーには、自身に向けて発行されたトークンだけを受け入れることが求められ、クライアントのトークンを別のサービスにそのまま渡すことは禁止されています。

人が介在しない定期ジョブのように、サービス ID が適した業務もあります。そうした ID には、責任を負う担当者、機能する範囲で最小限の権限、専用の記録を用意し、その活動が個人の活動と混同されないようにしましょう。

チーム単位でアクセスを付与する

接続を一人ひとりに割り当てる方法は、レビューしにくく、対応漏れも起きやすくなります。代わりにチームに割り当てましょう。理想は ID プロバイダーから取り込んだグループを使うことです。そうすれば、ディレクトリが変更されたときに、新しく加わった人には適切なアクセス権が付与され、離れた人はアクセス権を失います。

最初は範囲を狭くして始めます。機密性の高い接続は組織全体ではなく、必要とするチームだけが使えるようにし、そのうえで特定のツールやリソースに条件を追加します。たとえば経理チームの例では、全員が特定のフォルダーにある請求書を閲覧でき、一部のメンバーだけが支払い情報を更新できる、といった形が考えられます。

間接的に付与されるアクセスにも注意してください。2 つのチームに所属している人は、どちらのチームからでも接続にアクセスできる可能性があるため、一方のチームから外しても、アクセス権がなくなるとは限りません。

エージェントのアクセスを業務に必要な範囲に絞る

OWASP は、大規模言語モデルを用いたアプリケーションの主なリスクの一つに、過剰なエージェンシー（Excessive Agency）を挙げています。タスクに必要以上の機能、権限、自律性を与えられたエージェントは、誤誘導されたときや単に判断を誤ったときに損害を引き起こすおそれがあります。エージェントが読み取ったテキストがその行動をそらそうとするプロンプトインジェクションは、そうした事態が起こる経路の一つです。

MCP における最小権限は、3 つのレベルで考えます。まず、業務フローに必要なツールだけを有効にします。次に、そのツールを業務に関係するリソースに限定します。そして、有効にしたツールに必要な OAuth スコープだけを要求します。接続のトークンは通常、その接続上のすべてのツールから利用できるためです。MCP のセキュリティガイダンスでは、最小限のスコープから始め、必要になったときだけ追加を求めることを推奨しています。

変更だけでなく、読み取りにも注意が必要です。顧客レコードを読み取ることしかできないツールでも、その内容を漏らしてしまう可能性があります。実践的な進め方としては、まず試験導入のグループに読み取り専用のアクセスを与え、制限が機能していることを確認し、エージェントの挙動をチームが理解できた段階で変更操作を許可します。

アクセス権を見直し、取り消しをテストする

アクセス権は、時間とともに実態からずれていきます。プロジェクトが終わり、人はチームを異動し、一時的な例外が恒久化します。すでに実施しているアクセスレビューに MCP の接続も含め、各接続の担当者に、誰がアクセス権を持ち続けるべきかを確認してもらいましょう。役に立つレビューでは、次の点を確認します。

そのうえで、取り消しを直接テストします。テスト用のメンバーを削除し、すでにサインイン済みのクライアントから同じリクエストをもう一度送ります。リクエストは拒否されるべきであり、以前の承認によってアクセス権が復活してはなりません。

• 現在、各接続を誰が、どのチームまたは例外を通じて使えるか。
• どのツールとリソースが有効になっていて、それぞれが今も必要か。
• 接続が誰の認証情報を使い、それがどのスコープを付与しているか。
• どのクライアントセッションが有効なまま残っているか（特に、組織を離れた人のもの）。
• 期間中に実際に使われたものと、許可されているものとの比較。

申請と承認を分ける

支払いの送金、レコードの削除、顧客へのメール送信など、重大な結果を伴う操作では、アクセス権だけでは不十分な場合があります。提案された操作を、実行前に別の人がレビューすることもできます。このレビュー担当者は、申請者本人以外であるべきです。また、その判断は無期限の許可を与えるものではなく、特定の操作を対象とするべきです。

このレビューは、リスクに見合った範囲にとどめましょう。小さな操作まですべてレビューを必須にすると、担当者が疲弊し、重要なリクエストを見落としやすくなります。レビューが必要な操作は、誤りが起きた場合の損害の大きさに基づいて選びます。

アクセスと利用の証跡を残す

2 種類の証跡は、それぞれ異なる問いに答えます。現在のアクセス権からは、今その接続を誰が使えるのか、そしてその理由がわかります。リクエストの記録からは、実際に誰が使い、どう判定され、その後どうなったかがわかります。アクセスレビューには両方が必要です。

記録も必要な範囲にとどめましょう。判定の記録にプロンプトやレスポンスの全文が必要になることはほとんどなく、それらを保存すると、それ自体がプライバシー上の義務を生みます。また、記録が対象とするのは観測できる経路だけです。ゲートウェイを経由しないリクエストには、別の対策が必要です。

Durinが適している場所

Durin は、Durin のゲートウェイを経由する MCP リクエストにアクセスガバナンスを適用します。チームのルールが適用される前に、各リクエストは、その時点の ID、メンバーシップ、チーム、接続、認証情報、レビュー済みツール、リソース、検査の各チェックを通過する必要があります。接続の利用範囲はチームごとに限定でき、チームのルールでは特定のツール、リソース、人に対する条件を追加できます。

利用者は自分専用の Durin エンドポイントにサインインし、接続先へのリクエストには、その接続に設定されたプロバイダーの認証情報が使われます。Durin が自身のトークンをプロバイダーに渡すことはありません。メンバーシップやクライアントセッションを取り消すと以降のリクエストに適用され、以前の承認によってアクセス権が復活することはありません。Enterprise の組織では ID プロバイダーからユーザーとグループを同期でき、ローカルのユーザー、グループ、招待はすべてのパッケージで利用できます。

これらのチェックを通過したレビュー済みのリクエストは、デフォルトで実行に進めます。管理者は、デフォルトでツールへのアクセスを拒否する設定や、提案された変更操作を別の管理者がレビューする設定を選択できます。「アクセスグラフ」では現在誰がその接続を使えるのかとその理由を、「監査」ではリクエストの実行時に記録された判定を確認できます。Durin を経由しないリクエストには、別の対策が必要です。