MCPだけじゃない──『どんなプロトコルの認可判断もAuthZENに変換する』フレームワークCOAZを読む

MCPサーバーの認可を標準化する「COAZ-MCP」というドラフトが、OpenID AuthZENワーキンググループから公開されている。だが、そのCOAZ-MCPが依存している土台となる仕様が別に存在することは、あまり知られていない。「COAZ」（Compatible with OpenID AuthZEN、Cerbos社とCrowdStrike社の2名が著者）というドラフトの本文を確認すると、これはMCP専用の仕様ではなく、HTTPリクエスト・JSON-RPCメッセージ・スキーマで記述されたツール呼び出し・OpenAPIのルートなど、「任意のプロトコルや操作の入力を、AuthZENの認可APIリクエストへ変換するための共通の型」を定義する、より一段抽象度の高いフレームワークだと分かる。

3行まとめ

• COAZは、任意のプロトコルの操作入力を、OpenID AuthZEN認可API（Subject-Action-Resource-Context、SARCモデル）へのリクエストに変換するための「プロトコル非依存」フレームワークのドラフト1（2026年2月13日公開）
• 変換ルールは「リテラル（固定値）」か「式（CEL式などでの計算値）」のどちらかで書く。式かどうかは先頭の$記号で見分ける、というシンプルな判別規則を定義している
• MCP向けの実装である「COAZ-MCP」は、このCOAZフレームワークが定める適合要件を満たす「バインディング」の一つという位置づけ。ドラフトはHTTP APIやOpenAPI向けのバインディングも将来ありうる例として挙げている

出力側は固定、入力側だけがプロトコルごとに違う

ドラフトの導入部は、COAZが解決する問題をこう説明している。

A wide range of systems need to make fine-grained authorization decisions about operations expressed in some protocol or interface, for example: An HTTP request […] A JSON-RPC message […] An invocation of a tool described by a schema […] A route described by an OpenAPI document.

（幅広いシステムが、何らかのプロトコルやインターフェースで表現された操作について、きめ細かい認可判断を必要としている。例えば、HTTPリクエスト、JSON-RPCメッセージ、スキーマで記述されたツールの呼び出し、OpenAPIで記述されたルートなどだ）

AuthZENの認可API自体はSARCモデル（Subject-誰が・Action-何を・Resource-どのリソースに・Context-どんな文脈で）に基づく判断を標準化しているが、「特定のプロトコルの入力から、どうやってAuthZENリクエストを組み立てるか」までは定義していない。この隙間を埋めるのがCOAZだと、ドラフトは位置づけている。

COAZ deliberately separates two concerns: The output side is fixed [...] identical for every protocol. The input side is specialized [...] and are defined by a COAZ binding.

（COAZは意図的に2つの関心事を分離する。出力側は固定であり、あらゆるプロトコルで同一だ。入力側は特化しており、COAZの「バインディング」ごとに定義される）

つまりCOAZ自体が定めるのは「どんな入力からでも、こういう形のAuthZENリクエストにまとめる」という共通の型（出力側）と、各プロトコル向けの実装が満たすべき適合要件だけで、「MCPのこのメッセージはこう変換する」という具体的な対応表は、COAZ-MCPのような個別のバインディング文書が別途定義する。

$で始まれば式、それ以外はリテラル

具体的な変換ルールの書き方はシンプルだ。ドラフトが挙げる例を見ると、値が文字列で先頭が$ならCEL（Common Expression Language）式として評価され、そうでなければ固定値（リテラル）として扱われる。

{
  "evaluation": {
    "subject": { "type": "identity", "id": "$token.sub" },
    "action": { "name": "read" },
    "resource": { "type": "document", "id": "$request.document_id" }
  }
}

この例では"identity"と"read"と"document"はリテラル、"$token.sub"と"$request.document_id"は式として評価される。単一の判断を求める場合はevaluationエンベロープ、複数の判断（例えばファイル移動を「移動元の読み取り」と「移動先の書き込み」の2つの判断として扱う場合）を求める場合はevaluationsエンベロープを使う、という使い分けも定義している。式の言語はデフォルトでCELだが、バインディングが別の言語を指定してもよい（MAY）という拡張性も持たせている。

発音は「cozy」、適合バインディングに求められる10項目

ドラフト本文のAbstractには、名称の読み方まで明記されている。

This specification defines COAZ (Compatible with OpenID AuthZEN, pronounced "cozy")...

（本仕様はCOAZ〔Compatible with OpenID AuthZEN、「cozy」と発音する〕を定義する……）

Section 4「Binding Conformance Requirements」は、あるプロトコル向けの実装が「COAZバインディング」を名乗るために満たすべき条件を、10項目の箇条書きで定義している。ドラフト本文を要約すると次の通り。

このほかDiscoverability(発見可能性の仕組み)がOPTIONAL項目として挙げられている。ドラフトは「バインディングはAuthZENのリクエスト構造・デフォルトと上書きの意味論・エンベロープのルールを再定義してはならない(MUST NOT)」とも明記しており、この10+1項目の外側はCOAZフレームワーク側が固定していることが分かる。

Section 5.2「Fail-Closed Enforcement」は、認可判断が下せない場合の挙動を強く規定している。

As required by Section 3, a PEP MUST fail closed. A mapping error, a denial, or a PDP communication failure all result in the operation being refused. Bindings and deployments MUST NOT define fallbacks that permit an operation in the absence of an explicit permit decision.

（Section 3で要求される通り、PEPはフェイルクローズしなければならない。マッピングのエラー、拒否判断、PDPとの通信障害のいずれも、操作の拒否という結果になる。バインディングやデプロイメントは、明示的な許可判断が無い状態で操作を許可してしまうフォールバックを定義してはならない）

COAZ-MCPの実際のデフォルトマッピングを読む

COAZフレームワークのドラフトと同じ2026年2月13日付で、著者2名(順序が入れ替わっているがA. TulshibagwaleとA. Olivier)によって、MCP向けの具体的なバインディングであるCOAZ-MCPのドラフトも公開されている。このドラフト本文のSection 7には、MCPの各メソッドに対するデフォルトマッピングが、実際のJSON形式で列挙されている。

いずれの操作でもsubjectは$token.sub(検証済みアクセストークンのsub claim)に固定され、contextには$token.?client_id(存在すればクライアントID)が入る。つまりtools/callの認可判断は、ツール個別のマッピングを宣言していない限り、ツール名($params.name)だけを見て行われる。ツールの引数の中身(何を渡そうとしているか)までを見た、パラメータレベルのきめ細かい認可を行うには、各ツールが個別に宣言的マッピングを定義する必要がある設計だ。

MCP特有のセキュリティ上の考え方として、Section 11.2「Zero-Trust for AI Agents」は次のように述べている。

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エージェントのやり取りにおけるゼロトラストアーキテクチャをサポートする）

つまりCOAZ-MCPの設計では、「誰の代理としてエージェントが動いているか(人間=Subject)」と「どのエージェントが動いているか(Context)」を分けて扱うことで、エージェント自体の信頼度と、そのエージェントを使っている人間の権限を別々にポリシーで評価できるようにしている。

誰がこのフレームワークの上で何を作れるか

ドラフトのAppendix Aは、既存仕様との関係を「AuthZEN認可APIとの関係」「COAZバインディングとの関係」の2節に分けて整理している。本文中で名前が挙がっているのは、MCP向けのCOAZ-MCPのほか、「HTTP APIやOpenAPIで記述されたルート向けのバインディング」が将来ありうる例として言及されている程度で、この記事の執筆時点で実際に存在するバインディングはCOAZ-MCPのみだと、確認できた範囲の一次ソースからは読み取れる。

CEL式を自分で書いて動かす検証はしていない

COAZフレームワーク自体は「MCPの認可」という具体的な話題からは一段抽象的な、認可API設計の基盤仕様であるぶん、単体で読んでも実務的な使いどころがすぐには見えにくい。この記事を書いている自分自身は、認可（authorization）の実装経験がなく、COAZ・COAZ-MCPどちらのドラフトについても、CEL式を使ったマッピングを実際に書いて動かす検証は行っていない。今回COAZ-MCPのデフォルトマッピングの具体例までは読み込んだが、「宣言的マッピング」(Section 8、各ツールが個別に定義するマッピング)の実例や、Section 9のPEP(policy enforcement point)の詳細な振る舞いまでは本記事では扱っていない。ドラフトがWorking Group内でどの段階の合意を得ているか（今後どの程度内容が変わりうるか）についても、確認したドラフト本文とREADMEからは明確に読み取れなかった。GitHubリポジトリの更新履歴やIssueでの議論までは追っていない。

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

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