チーム運営

AIエージェントのワークスペースへのアクセスを絞る方法:MCPスコープ、最小権限、監査ログ

AIエージェントのMCPアクセスを最小権限で設計する手順。読み取りから始め、書き込みは1つずつ、トークンは本人の権限を超えない、全呼び出しを監査。実例付き。

執筆 Atrix team公開日 10分で読めます
目次
  1. エージェントの権限がユーザー権限と違う理由
  2. MCP認可仕様が提供するもの
  3. レシピ:読み取りから始め、書き込みごとに広げ、本人を超えない
  4. 実例:Atrix AIの49スコープ
  5. ステップアップ:タスクが求めたときに広げる、その前ではなく
  6. セキュリティポリシーに貼れるチェックリスト
  7. よくある質問
  8. 次のステップ

AIエージェントのアクセスは、新しい外部委託先に与えるのと同じ要領で絞ります。必要な少数の領域だけに読み取りを許可し、具体的なタスクがそれを必要とした時点で書き込みスコープを1つずつ加え、トークンが作成者本人以上のことをできないようにし、何に触れたか分かるようにすべての呼び出しを記録します。MCPの言葉で言えば、同意画面で選ぶOAuth 2.1スコープ、エージェントがその外に出たときの403、そしてサーバー側の監査ログです。

この記事はAtrixで自社のエージェントに使っているレシピです。標準に関する部分はMCPの認可仕様から、製品に関する部分は2026年10月時点で49個の付与可能なスコープを持つ自社サーバーから取っています。

エージェントの権限がユーザー権限と違う理由

人は行動する前に画面を読みます。エージェントはツールの説明を読み、ミリ秒で、1時間に何百回も行動します。しかもその入力はWebページ、メール、社外の人が書いたチケットかもしれません。プロンプトインジェクションがよく挙げられる例ですが、ありふれたミスのほうが多いです。「古いissueを整理して」と頼まれたエージェントが「整理」を「削除」と解釈する、といったものです。

ここから2つの帰結が出ます。第一に、誤った行動の被害範囲はトークンにできることだけで決まるので、トークンは小さくなければなりません。第二に、各行動を事前に確認することはできないので、事後に確認できる程度のログが必要です。

ユーザー権限は「この人は何を見て、何を変えてよいか」に答えます。エージェント権限は「このプログラムは、この人の代わりに、このタスクのために、今週、何をしてよいか」に答えます。2つ目の問いの答えのほうが狭くなります。

MCP認可仕様が提供するもの

Model Context Protocolの認可仕様(2025-06-18版、2026年10月時点の現行版)は、MCPサーバーをOAuth 2.1のリソースサーバー、MCPクライアントをOAuth 2.1クライアントとして扱います。スコープ設計に関わる部分は次のとおりです。

要件あなたにとっての意味
サーバーはProtected Resource Metadata(RFC 9728)を公開し、WWW-Authenticate 付きの401を返さなければならないクライアントが認可サーバーを自力で発見する。設定ファイルにトークンを貼る人はいない
クライアントはPKCEを使わなければならず、動的クライアント登録(RFC 7591)をサポートすべきエージェントのホストが自分で登録し、ブラウザで同意フローを実行する
クライアントは resource パラメータ(RFC 8707)を送らなければならず、サーバーはトークンのaudienceを検証しなければならないあるサーバー向けに発行されたトークンは別のサーバーに再利用できない
トークンがない・無効なら401、スコープが無効・権限不足なら403スコープ違反が明示的なので、エージェントは「許可されていない」と「ログインしていない」を区別できる
認可サーバーは短命なアクセストークンを発行すべきで、パブリッククライアントのリフレッシュトークンはローテーションしなければならない漏れたトークンは期限切れになり、盗まれたリフレッシュトークンは次の使用時に検知される
トークンのパススルーは禁止サーバーはあなたのトークンを下流のAPIに転送できない

仕様はスコープの名前と粒度を意図的に各サーバーに委ねています。仕組み(同意、audience、403)を提供し、方針はあなたに任せるということです。この記事の残りがその方針です。

レシピ:読み取りから始め、書き込みごとに広げ、本人を超えない

私たちが適用する順に5つのルールを挙げます。

  1. タスクが触れる領域の読み取りスコープだけで始める。 週次ステータスを下書きするエージェントはissue、ゴール、フィードを読む必要があります。顧客、給与、採用を読む必要はありません。3〜4個の読み取りスコープを選んで止めます。
  2. 名前のあるタスクが必要とするときだけ、そのスコープだけ書き込みを加える。 「実装したissueにコメントする」にはissueの書き込みが必要です。プロジェクトの書き込み、ページの書き込み、チームフィードへの投稿は不要です。書き込みスコープが読み取りを含むのは構いませんが、逆は決して成り立ちません。
  3. 破壊的な操作と外に向かう操作は別の付与として扱う。 削除、公開、メール送信、通知の投稿は取り消せない操作です。それぞれ専用のスコープの後ろに置き、できれば人が目にする確認の後ろに置きます。
  4. トークンは発行者本人を超えてはならない。 エージェントのトークンが所有者には読めないものを読めるなら、スコープは権限昇格の手段になっています。所有者の権限は発行時ではなく呼び出しごとに解決し、所有者のアクセスを取り消せばエージェントのアクセスも取り消されるようにします。
  5. すべての呼び出しを監査し、監査を読む。 ツール名、結果、触れた対象の種類とid。内容は記録しません。顧客データで満たされた監査ログは、次の情報漏えいの種です。

避けるべき失敗は「すべて接続」の同意画面です。エージェントのホストがすべてのスコープを一度に要求し、リストが長いので人は承認してしまいます。短いリストは読まれます。

実例:Atrix AIの49スコープ

AtrixのMCPサーバーは私たちが管理しているものなので、正直に語れる例です。2026年10月時点で、開発者ドキュメントに載る49の付与可能なスコープの後ろに85のツールがあります。設計上の選択は上のルールに対応しています。

  • 領域ごとの読み取り・書き込みのペア:work.read、work.write、crm.read、crm.write、pages.read、pages.write など。書き込みスコープは読み取りを含みますが、それ以外は何も含みません。
  • 取り消せない操作や外に向かう操作には名前付きスコープ:destructive、publish、email.send、feed.post。書き込みスコープから暗黙に付与されることはありません。feed.post が feed.write と別なのは、投稿がオプトアウトなしで人々の電話に通知を送るからです。
  • 9つのスコープは、トークンの背後にあるアカウントの対応する権限も必要とする:取引金額、雇用記録、契約、採用、連携、請求、請求書、製品の変更。権限は呼び出しごとに確認されるので、トークンは作成者以上のことはできず、誰かのアクセスを取り消せばその人のトークンの到達範囲も即座に消えます。
  • 給与はそもそも付与できない。 給与に届くスコープはなく、報酬記録を選択するツールもありません。エージェントから同意クリック1回の距離に置くべきでないデータがあり、それを保証する方法はスコープ一覧から外すことです。
  • 制限と監査:トークンごとに毎分120呼び出し、30書き込み。すべての呼び出しをツール、結果、対象の種類とidで記録し、内容は記録しません。

この設計のコスト:ClaudeやCursorを接続するメンバーはスコープ選択画面を見て、30秒考える必要があります。比較するとLinearのサーバーは別の読み取り専用URLを提供しており、「読み取りだけ」を表現するより単純な方法です。どちらも機能します。私たちは判断を人に、Linearは判断をURLに置いています。

ステップアップ:タスクが求めたときに広げる、その前ではなく

書き込みスコープを最初から付与する代わりになるのがステップアップ認可です。エージェントは読み取りで動き、最初の書き込みで403を受け、ホストがそのセッションのための追加スコープの承認を人に求めます。ステップアップ認可の用語集の項目がこのパターンを説明しており、仕様は403と新たな同意ラウンドによってこれを支えています。

実際にはこう動きます。エージェントがステータスレポートを下書きします(読み取りのみ)。あなたが下書きを承認します。エージェントが公開のために feed.post を求めます。そのトークンに付与するか、自分で下書きを投稿します。書き込みスコープはタスクが必要とする間だけ存在します。

ステップアップは初日は広い付与より遅く、2日目からは速くなります。タスクが安定すれば、あるエージェントが獲得したスコープの集合は増えなくなるからです。

セキュリティポリシーに貼れるチェックリスト

  • エージェントはホストの同意フローを通じてOAuth 2.1で認証する。CI以外では設定ファイルに長期キーを置かない。
  • 各エージェントトークンはスコープ、所有者、作成日、最終使用日を一覧できる。
  • デフォルトの付与は最大4領域の読み取り専用。
  • 書き込みスコープはタスクごとに付与し、毎月見直す。
  • 破壊、公開、メール、通知の操作は専用スコープと人の確認を必要とする。
  • 所有者の権限は呼び出しごとに解決する。所有者を取り消せばエージェントも取り消される。
  • レート制限はトークンごとに存在する。
  • 監査ログはツール、結果、対象の種類とidを記録し、毎週確認する。
  • 一部のデータ(最低でも給与)はどのスコープからも到達できない。

よくある質問

MCPスコープとは何ですか?

MCPサーバーがトークンにできることを制限するために定義するOAuth 2.1のスコープで、同意画面で人が選びます。MCP仕様は、呼び出しがトークンのスコープを超えたときサーバーが403を返すことを求めています。名前と粒度は各サーバー次第です。スコープの用語集の項目を参照してください。

AIエージェントにユーザーと同じ権限を与えるべきですか?

いいえ。ユーザーの権限は上限であってデフォルトではありません。タスクが触れる領域の読み取りスコープから始め、書き込みは1つずつ加えます。トークンは呼び出しごとにユーザーの権限を解決し、決してそれを超えないようにすべきです。

エージェント用に設定ファイルへAPIキーを書くのは許容できますか?

ブラウザのないCIなら、最も狭いスコープとローテーション計画を伴えば可です。個人のラップトップではOAuthフローを優先してください。トークンはスコープ付きで短命、更新と失効が可能で、仕様はPKCEとaudienceの束縛を要求しています。

エージェントが実際に何をしたかはどう分かりますか?

サーバーの監査ログからです。ツール名、結果、触れた対象の種類とid、タイムスタンプを求めてください。サーバーが内容だけ、あるいはエラーだけを記録しているなら、セッションを再構成できません。

エージェントに決して付与すべきでないものは?

公開されたら取り消せず、エージェントが使う日常的な目的のないもの。私たちにとっては給与です。あなたのリストには健康データ、銀行情報、ソースコードのシークレットが加わるかもしれません。保護は構造的であるべきです。スコープがなければツールもない。

MCPにおけるステップアップ認可とは?

エージェントを狭いスコープで動かし、特定の呼び出しが403を返したときだけ、追加スコープのための新たな同意ラウンドを経て広げること。付与を最初の推測ではなくタスクに結びつけておけます。

次のステップ

使っているエージェントホストの同意画面を開き、デフォルトで要求されるスコープの数を数えてください。答えが「全部」なら、それが最初に変えるべきことです。AtrixのMCPページには49のスコープと各スコープで何ができるかが、開発者ドキュメントにはツールごとに必要なスコープが載っています。

この記事をシェア

この記事をシェア

あわせて読みたい

すべての記事

この記事の考え方を、今日から実践に。

まずは7日間お試し。開始にはカード登録が必要で、解約しなければトライアル終了時に課金されます。トライアル中の解約は無料です。

7日間お試し · カード登録が必要 · いつでも解約可