MCPの『誰が・どのツールを呼んでいいか』をOAuthの外側で決める──OpenID AuthZENのCOAZ-MCPドラフトを読む

MCP（Model Context Protocol）サーバーが「このツール呼び出しを許可していいか」を、OAuthのスコープよりきめ細かく判断するための標準仕様ドラフト「COAZ-MCP」が、OpenID AuthZENワーキンググループから2026年2月13日付で公開されている。ドラフト本文を確認すると、MCPのJSON-RPCメッセージをAuthZENの認可APIリクエストへ変換する「デフォルトマッピング」と、MCPサーバー自身がCEL（Common Expression Language）式で上書きできる「宣言マッピング」の2階建て構造になっていることが分かる。

3行まとめ

• COAZ-MCPは、MCPのJSON-RPCメッセージをOpenID AuthZENの認可API（Subject-Action-Resource-Context、SARCモデル）へ変換する仕様のドラフト1。著者はCrowdStrikeとCerbosの2社
• 全MCPメソッドに固定のデフォルトマッピングがあり、追加設定なしで動く。ツール単位で上書きしたい場合は、ツールのinput schema内にCEL式でマッピングを宣言する
• AuthZENのsubjectにはユーザー（$token.sub）、contextにはエージェント（$token.?client_id）を分けて入れる設計で、「ユーザーの信頼度」と「エージェントの信頼度」を独立に評価できるとドラフトは説明している

なぜ必要か——OAuth 2.1だけでは足りない2つの穴

ドラフトの導入部は、MCPの現状の認可方式が抱える課題をこう整理している。

The access token may carry scopes, but the resources a given call is actually permitted to touch depend on the user and on dynamic, fine-grained policy that scopes cannot express. If the OAuth access token is issued to the agent […] there is no standard mechanism to capture, per request, the identity of the user on whose behalf the agent acts as distinct from the agent itself.

（アクセストークンはスコープを運べるが、ある呼び出しが実際に触れることを許可されているリソースは、ユーザーと、スコープでは表現できない動的できめ細かいポリシーに依存する。OAuthアクセストークンがエージェントに発行されている場合、〔中略〕エージェント自身とは区別される形で、そのエージェントが誰の代理として動いているのかというユーザーの身元を、リクエストごとに捉える標準的な仕組みが存在しない）

COAZ-MCPはこの2つの穴を、OpenID AuthZENという既存の認可API標準にMCPのメッセージをマッピングすることで埋めようとしている。

Subject（人間）とContext（エージェント）を分ける設計

ドラフトが強調するのが、AuthZENのsubject（誰が）とcontext（どんな文脈で）を、人間とエージェントで明確に分ける設計だ。すべてのデフォルトマッピングが共有する形は次のようになっている。

{
  "evaluation": {
    "subject": { "type": "identity", "id": "$token.sub" },
    "context": { "agent": "$token.?client_id" },
    "action":   { "...": "per-method" },
    "resource": { "...": "per-method" }
  }
}

subject.idにはアクセストークンのsubクレーム（人間ユーザーの身元）、context.agentにはclient_id（エージェント自身の身元）が入る。この分離について、ドラフトのセキュリティ考慮事項セクションはこう説明する。

This binding represents the human user as the AuthZEN Subject and the AI agent as part of the Context. This separation lets policies evaluate the trust level of the user and the agent independently, supporting zero-trust architectures for AI agent interactions.

（このバインディングは、人間のユーザーをAuthZENのSubjectとして、AIエージェントをContextの一部として表現する。この分離により、ポリシーはユーザーとエージェントの信頼レベルを独立に評価でき、AIエージェントのやり取りにおけるゼロトラストアーキテクチャをサポートする）

全メソッドに効く「デフォルトマッピング」

ドラフトは、tools/list・tools/call・resources/list・resources/read・prompts/list・prompts/get・completion/completeなど、MCPの主要メソッドそれぞれについて、追加設定なしで動くデフォルトマッピングを定義している。例えばtools/callのデフォルトはこうだ。

// tools/call  (applies when the tool declares no mapping)
{ "evaluation": {
  "subject": { "type": "identity", "id": "$token.sub" },
  "context": { "agent": "$token.?client_id" },
  "action": { "name": "tools/call" },
  "resource": { "type": "tool", "id": "$params.name" } } }

サーバー全体を対象とするメソッド（tools/list等）では、resource.idにサーバー自身の識別子が入る。ドラフトは、この識別子をアクセストークンのaud（audience）クレームから取得するという解決規則を、RFC 8707（リソースインジケータ）に基づいて詳しく規定している。

全9カテゴリのデフォルトマッピングを一覧にする

記事執筆にあたりドラフト本文の第7節を通読すると、デフォルトマッピングはtools・resources・prompts・completionだけでなく、9つのカテゴリに分かれて定義されていた。

出典: openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html第7節（2026年8月30日確認）

特に7.8「Unknown Methods」の規定は、このバインディングの設計思想を象徴している。ドラフトは「デフォルトマッピングも宣言マッピングも無く、pass-through対象でもないメソッドは、PEPがPDPを呼ばずに通してしまうのではなく、必ず認可拒否として扱わなければならない（MUST be denied）」と明記しており、将来MCPに追加される未知のメソッドが、認可チェックをすり抜けて素通りしてしまう事態を防ぐ「fail closed」設計になっている。一方で7.9が示す通り、サーバー発信のリクエスト（サンプリング要求・引き出し要求・ルート一覧要求）は、今回のドラフトの認可モデルでは扱えないと明示的に認め、スコープ外としている。

ツールごとに上書きできる「宣言マッピング」

デフォルトマッピングだけでは、resource.idにツール名しか入らず、「このツールのこのパラメータ値なら許可・別の値なら拒否」というきめ細かい判断ができない。そこでCOAZ-MCPは、ツールのinput schema内にCEL式でマッピングを宣言する仕組みを用意している。ドラフトの概要はこうだ。

allows MCP servers to override the default for a specific tool by declaring a mapping in the tool's input schema using Common Expression Language (CEL). It also defines how an MCP server advertises declared mappings so that clients can understand how authorization will be performed.

（MCPサーバーが、ツールのinput schema内でCommon Expression Language（CEL）を使ってマッピングを宣言することで、特定のツールについてデフォルトを上書きできるようにする。また、MCPサーバーが宣言済みマッピングをどう広告し、クライアントが認可がどう行われるかを理解できるようにするかも定義する）

第8節をさらに読むと、この宣言は具体的にはツールのinputSchemaにx-authzen-mappingという拡張フィールドを含める形で行うと定義されていた。宣言マッピングは、そのツールのtools/callに対するデフォルトマッピングだけを上書きし、他のメソッドや他のツールには影響しない。また1回の呼び出しに対して単一の認可判断で済むevaluationエンベロープと、複数の判断が必要なツール向けのevaluationsエンベロープの2種類が使える、とも定義されている。

「サーバーは信用できない前提」で設計されたセキュリティ考慮

宣言マッピングを使う場合、そのマッピング自体はMCPサーバー（＝これから認可判断を受ける当事者）が作る。ドラフトはこの利害の衝突を明示的に警戒している。

A declared mapping is supplied by the MCP server, which is the party whose operation is being authorized. Every attribute it produces — action, resource, context, and all subject attributes other than the veri[fied one]…

（宣言マッピングはMCPサーバーによって提供されるが、そのサーバー自身がまさに認可判断を受ける当事者だ。サーバーが生成するすべての属性——action、resource、context、そして検証済みのもの以外のすべてのsubject属性は……）

subject.idについても、原則はアクセストークンの検証済みクレームに固定すべき（SHOULD）としつつ、次のような警戒を明記している。

without it, the server — the party being authorized — could assert the identity of any principal and obtain a decision for a user the caller never authenticated as.

（この検証がなければ、認可される側であるサーバー自身が、任意のプリンシパルの身元を主張し、呼び出し元が実際には認証していないユーザーについての認可判断を得られてしまう）

ドラフトのその後の標準化状況は追えていない

この記事はCOAZ-MCPドラフト1の本文、AuthZENリポジトリのREADME、そしてCOAZ-MCPが依拠するAuthZEN本体の仕様「Authorization API 1.0」とCOAZフレームワーク仕様「COAZ Framework - Draft 1」を一次ソースとしている。AuthZEN本体はPDP（Policy Decision Point）とPEP（Policy Enforcement Point）が互いの内部実装を知らなくても通信できるようにする、という設計目的をAbstractで確認でき、COAZ-MCPが依拠するSubject-Action-Resource-Context（SARC）の枠組みも本体側の情報モデル（Subject／Resource／Action／Context／Decision）と対応していることを確認できた。

一方で、このドラフトは「Draft 1」（草案の第1版）であり、IETF/OpenID Foundationの標準化プロセスにおいてどの段階にあるか（Working Group Draftとして正式に採択済みか、今後の内容変更の可能性がどの程度あるか）は、確認した4つのページ本文からは明確に読み取れなかった。日付は2026年2月13日公開とドラフト冒頭に記載されているが、これが最新版かどうかは、GitHubのコミット履歴を取得しようとしたところAPIのレート制限にかかり、本記事では確認できなかった。

実際にCOAZ-MCPを実装したMCPサーバーやゲートウェイの実例、相互運用性テストの結果についても、この記事では触れていない。この記事を書いている自分自身は、OAuth/AuthZEN周りの認可設計を実務で構築した経験がなく、CEL式の宣言マッピングを実際に書いて動かす検証は行っていない。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。