社内エージェントの権限は「誰として・どこ宛てに・どこまで」の3つで決める：MCPの認可仕様とOAuthの公式文書で、ID・トークンの宛先・スコープの考え方を確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。読んだMCPの認可仕様は「draft（草案）」と表示されたページで、確定版と違う部分があるかもしれません。

先に結論

• 「エージェントに権限を渡す」は、1つの設定ではなく、3つの別々の決めごとです。誰として動くか（本人の代理か、エージェント自身か）、どこ宛てか（トークンがどのサーバーのために出されたか）、どこまでか（スコープ）。
• 公式文書は、3つとも「狭く」を勧めています。OWASPは、エージェントの被害の根本原因を、機能・権限・自律の「多すぎ」に分けています。MCPの仕様は、トークンの宛先を厳密に確かめ、スコープを段階的に上げる作りを示しています。
• ただし仕様が保証するのは、通行証が正しく出入りすることです。通行証を持ったエージェントが、その範囲で何をするかは、別に設計します。ここは僕らの見立てを、後半の表にまとめました。

前提：登場人物と言葉

OAuthは、利用者のパスワードを渡さずに、アプリへ限られた権限を預ける標準の仕組みです（この段落は一般的な説明で、読んだ文書からの要約ではありません）。預ける権限の証明書がアクセストークン（通行証）で、権限の範囲を名前で区切ったものがスコープです。本人確認（認証）と、してよいことの決定（認可）は別の話で、OAuthが扱う中心は後者です。

MCPの認可仕様は、役割をOAuth 2.1の言葉に当てはめています。

仕様の前提も確認しておきます。MCPで認可は任意（OPTIONAL）です。HTTP系の通信では、この仕様に従うことが推奨（SHOULD）され、標準入出力（STDIO）の場合は、従わずに環境から資格情報を取る、とされています。

問い1：誰として動くのか

エージェントが外のシステムを呼ぶとき、相手側の記録には「誰が」が残ります。この「誰」を決めるのが、1つ目の問いです。公式文書から、3つの型が読み取れます。

• 本人の代理（委任）。 MCPの仕様は、利用者に代わって動くクライアントを基本に書いています。OWASPも、拡張機能は「その利用者の文脈」で、最小のスコープのOAuthなどを使って動かすことを対策に挙げています。
• エージェント自身。 仕様には、自分自身の名前で動くクライアント（client_credentials）への言及があり、権限不足のときに、再認可を試してもよいし、すぐ中止してもよい、と書かれています。
• 共通の高権限アカウント。 OWASPは、利用者ごとのツールが、共通の高権限アカウントでつながる例を、「権限が多すぎる」例として挙げています。

RFC 8693（トークン交換）は、この区別に言葉を与えています。なりすまし型（impersonation）は、受け手が元の本人として扱う形です。委任（delegation）は、代理側が自分の身元を保ったまま、本人の権利の一部を預かる形で、「本人の代わりに動いている」ことが記録に残ります。委任では、トークンに行為者（actor）を示すactの項目を入れられ、入れ子にすると、過去の行為者の連鎖も表せます。ただしアクセス制御には、最上位の主張と現在の行為者だけを使い、過去の行為者は参考情報とする、と書かれています。

見立てです。本人の代理は、相手の記録で「誰の依頼か」が追え、本人の権限を超えません。エージェント自身のIDは、定期バッチのように特定の人に紐づかない仕事向きですが、権限の棚卸しが別に要ります。共通の高権限アカウントは、誰の依頼かが記録から消え、漏れたときの被害が全員分に広がります。

問い2：どこ宛てのトークンか

2つ目の問いは、トークンの宛先（audience）です。MCPの仕様は、次の3つを決めています。

• クライアントは、トークンを求めるとき、resourceパラメータで、使う先のMCPサーバーを指定する（認可の要求とトークンの要求の両方で必須）。
• MCPサーバーは、受け取ったトークンが、自分宛てに発行されたものかを検証する（必須）。
• MCPサーバーは、自分宛て以外のトークンを受け付けたり、ほかへ転送したりしてはならない（禁止）。

3つ目の禁止は、セキュリティのベストプラクティスの文書で、トークンの素通し（token passthrough）という名前の悪い設計として詳しく説明されています。MCPサーバーが、クライアントから受け取ったトークンを、確かめずに下流のAPIへ流す形です。文書は、起きる問題を4つ挙げています。

• セキュリティ制御の迂回。
• 監査の証跡の問題。
• 信頼の境界の問題。
• 将来の互換性の問題。

（4つの名前のみを、読んだ記録から書いています。それぞれの具体的な中身は、記録に残っていないため、書きません。）

社内でエージェントを使うときは、エージェントとMCPサーバーの間のトークンと、MCPサーバーと社内APIの間のトークンを、別のものとして扱う、という見立てになります。RFC 8693は、あるトークンを元に、宛先（audienceかresource）とスコープを指定した別のトークンを発行する仕組みを定めています。ただし、MCPの仕様のページが、この交換を使うよう書いているかは、読んだ範囲では確認できませんでした。

もう1つ、中継役の落とし穴があります。外部のAPIにつなぐMCPサーバー（プロキシ）が、静的なクライアントID、動的なクライアント登録、同意のクッキーの組み合わせで、利用者の同意なしに認可コードを攻撃者に渡してしまう混乱した代理人（confused deputy）です。条件と対策は、後ろの「くわしく」に入れました。

問い3：どこまで許すのか

3つ目の問いがスコープで、MCPの仕様に、設計の指針がまとまっています。

• サーバーは、401の応答のWWW-Authenticateヘッダに、必要なスコープを入れることが推奨される。
• クライアントは、必要な分だけを求める（最小権限）。初回は、まず上の指定を使い、なければ、サーバーが公開しているスコープの一覧（scopes_supported）を使う。この一覧は、基本の機能に必要な最小の集合を表すことが意図されている。
• 実行中に権限が足りないと、サーバーは403と、error="insufficient_scope"、必要なスコープを返す。クライアントは、すでに持つスコープに、要求されたスコープを足して、再度認可を受ける（ステップアップ）。再試行は数回までにとどめる。

仕様が定める項目（error、scope、resource_metadata）に沿って僕らが書いた応答の例です。値は架空で、動かしていません。

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

書き込みが必要になった時点で、書き込みのスコープを足す流れです。

ベストプラクティスの文書は、スコープ設計の失敗例も挙げています。全部のスコープをscopes_supportedに載せる、*やallのような包括的なスコープを作る、無関係な権限を束ねる、トークンの中のスコープの主張だけで、サーバー側の認可の確認を省く、などです。さらに注意点として、チャレンジにスコープがないとき、クライアントはscopes_supportedの全部を求める流れなので、サーバーが全部を載せていると、最初から全権限が要求されます。

スコープの粒度は、サービスごとに違います。GitHubの公式文書では、きめ細かい（fine-grained）個人用トークンは、1つの所有者に限られ、特定のリポジトリに絞れ、権限も個別に付けられます。従来型（classic）のトークンは、所属する組織の全リポジトリなどへのアクセスを与える、と書かれています。GitHubは、可能な限り前者を使うよう勧め、期限をつけることも強く勧めています。

エージェントを動かす製品側にも、絞る手段があります。Claude Codeの公式文書では、MCPサーバーごとにoauth.scopesで要求するスコープを固定できます（oauth.scopesの項目と値の例は公式の記載にあります。周りの構造やURLは、読んだ記録では確認できていないため、この記事で補ったもので、動作確認はしていません）。

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": { "scopes": "channels:read chat:write search:read" }
    }
  }
}

同じ文書は、403のinsufficient_scopeが出たときは、oauth.scopesにスコープを足してから再認証する、と書いています。

仕様が決めないこと：許す操作、承認、記録

ここまでの仕様は、通行証の出入りを決めるものです。通行証を持ったエージェントが、何をしてよいかは決めません。OWASPの「過剰な主体性」の文書は、この部分の考え方を、いくつか挙げています。

• 例：メールを読む拡張に、送信の機能も含まれていると、受信したメールに仕込まれた指示（間接プロンプトインジェクション）で、受信箱の内容を外へ転送される。対策として、拡張の機能と権限を最小にすること、最小スコープのOAuthで利用者の文脈で動かすこと、高影響の操作に人の承認を挟むこと、が挙げられています。
• 完全な仲介。 許可するかどうかは、AIに判断させず、下流のシステムで強制する。
• 高い影響の操作は、人の承認を挟む。
• 防止にはならないが被害を減らす措置として、ログと監視、回数制限。

MCPのベストプラクティスも、スコープが上がった出来事（要求したスコープと、与えられた範囲）を、相関のIDつきで記録することを勧めています。

社内用の設計表（見立て）

ここからは、僕らの見立てです。公式の文書を、エージェント1つごとの「権限の台帳」にまとめる形にしてみます。例のスコープ名は架空です。

見立てとしては、こう考えます。

• 最初は、読むだけから始め、書く権限は必要になった時点で足します。仕様のステップアップと同じ流れです。
• 「送る」「払う」「消す」は、スコープが付いていても、人の承認を残します。OWASPの高影響の操作の考え方に沿っています。
• エージェントごとに、台帳を1枚持ちます。使われなくなったエージェントの権限を、棚卸しで外すためです。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。コードや設定の例は、公式の項目名をもとにこの記事で書いたもので、動作確認はしていません。
• MCPの認可仕様は、URLに「draft」と入った（草案版の）ページを読みました。セキュリティのベストプラクティスのページには2026年7月28日付の版へのリンクがありますが、版ごとの違いは確認していません。実装の前に、使う版の仕様を読んでください。
• 公式ページは、WebFetchという取得の仕組みを通して読んでいます。この仕組みはページを要約して返すため、細部の取りこぼしがありえます。RFC 9700は末尾の約4,600字、Claude CodeのMCPの文書は末尾の約16,000字を読めていません。
• 「社内のID基盤で、エージェントにどのIDを発行するか」について、読んだ文書は具体的な推奨を書いていません。3つの型の比較と設計表は、僕らの見立てです。
• トークン交換（RFC 8693）が、MCPの文脈で推奨されているかは、確認できていません。
• スコープの意味は、サービスごとに違います。同じ名前に見えても、許す操作が同じとは限りません。使うサービスの文書で確かめてください。
• GitHubとClaude Codeの記述は、読んだ時点のものです。変わることがあります。
• セキュリティや契約についての助言ではありません。実際の設計は、社内のセキュリティ担当や専門家と決めてください。

出典

• Authorization（Model Context Protocol、draft版、10月16日確認）
• Security Best Practices（Model Context Protocol、10月16日確認）
• RFC 8693 OAuth 2.0 Token Exchange（IETF、10月16日確認）
• RFC 9700 Best Current Practice for OAuth 2.0 Security（IETF、10月16日確認）
• LLM06:2025 Excessive Agency（OWASP GenAI Security Project、10月16日確認）
• Connect Claude Code to tools via MCP（Claude Code Docs、Anthropic、10月16日確認）
• Managing your personal access tokens（GitHub Docs、GitHub、10月16日確認）

更新履歴

• 2026年10月25日 書き方を直しました。
  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した