COAZでくつろぐ: 標準化された認可によるAPIとAIエージェントの保護

著者: Atul Tulshibagwale、Alex Olivier(OpenID Foundation AuthZENワーキンググループ共同議長)

本記事で述べられている見解は、AuthZENワーキンググループ共同議長としての著者個人の見解であり、OpenID Foundation全体の立場を必ずしも代表するものではありません。

AuthZENは認可を外部化するための優れた方法です。しかし、あなたのAPI、プロトコル、システムには、そうした外部化された認可判断を行うために必要なパラメータを表現する独自の方法があるかもしれません。COAZ(「コージー」と発音します)は、APIやプロトコルなど任意のソースシステムにおける操作を、AuthZENの評価呼び出しにマッピングするフレームワークであり、その結果、呼び出し元はその操作を続行させてよいかどうかを知ることができます。

これを踏まえ、OpenID FoundationのAuthZENワーキンググループは、2つの新しいドラフト仕様の公開を発表します。COAZ FrameworkとCOAZ-MCP Bindingです。

セキュリティはリンクの最も強度の弱い部分で決まるため、企業にとって、組織全体のポリシーをすべての資産にわたって一貫して、継続的に、そして文脈に応じて適用することが重要です。しかし、これをシステムごとに独自の方法で行うのはコストがかかり、対応が分断され、結果としてポリシーの適用に一貫性がなくなりかねません。

AuthZEN Authorization APIは、Subject-Action-Resource-Context(SARC)モデルを用いて、きめ細かな認可判断を要求するための標準的な方法を提供します。しかし、これを組織全体の技術基盤にわたって行うには、開発者は依然として、自らのアプリケーション固有の入力をAuthZEN形式に変換する標準化された方法を必要とします。

そこで登場するのがCOAZです。

COAZ Framework: あらゆるプロトコルのための汎用マッピング

COAZ(Compatible with OpenID AuthZENの略)は、任意のプロトコルやインターフェースの情報モデルをAuthZENの認可リクエストにマッピングするための汎用フレームワークです。

HTTPリクエストであれ、JSON-RPCメッセージであれ、OpenAPIで記述されたルートであれ、COAZは単一のプロトコルに依存しないパターンを確立します。COAZは、受信した操作の入力(リクエストフィールド、ヘッダー、認可トークンなど)を受け取り、宣言的なマッピングを通じてそれらをAuthZENのSARC構造へ射影します。

新しいAPIやプロトコルが登場するたびに独自のミドルウェアを書く代わりに、PEP(Policy Enforcement Point)はCOAZマッピングに頼ることができます。これらのマッピングは、リテラル定数と式(既定ではCommon Expression Language(CEL)で記述)を用いて、PDP(Policy Decision Point)へのAuthZEN認可リクエストを動的に構築します。COAZ Frameworkは抽象的なものですが、MCP向けに私たちが行ったように、特定のプロトコルやAPI向けに具体化することができます。以下をご覧ください。

MCPマッピングの例:

COAZ-MCP: AIエージェント時代のセキュリティ確保

私たちは同時に、Model Context Protocol(MCP)向けのCOAZバインディングのドラフトであるCOAZ-MCPも公開します。

AIエージェントがMCPを通じて企業のワークフローに深く統合されるにつれ、エージェントはさまざまな委任アクセスモードでユーザーに代わって行動するようになります。個々のMCPリソースやツール呼び出しをどのように認可するかについて注意を払わないと、上位レベルでの意図した認可が下位レベルでの不正アクセスをもたらしてしまう、いわゆる「Confused-deputy(混乱した代理人)」問題に容易に陥ってしまいます。

さらに、エージェントが関わる認可判断には、ユーザープリンシパルだけでなく、エージェントのIDと両者の関係も含まれます。COAZ-MCPはこの点にも対応しています。

COAZ-MCPは、COAZフレームワークをMCPの情報モデルに直接適用し、AIクライアントからのすべてのJSON-RPCメッセージが実行前に認可されることを保証します。

• 既定マッピング: このバインディングは各MCPメソッドに対して固定の既定マッピングを定義しており、操作ごとの設定なしにすべての基本メッセージを認可できるようにします。
• 宣言マッピング: 個々のツールは、ツールの入力スキーマ内で(CELを用いて)カスタムのCOAZマッピングを宣言することで既定を上書きできます。これにより、動的なツール引数がAuthZENパラメータへ直接変換されます。
• Subject ID: このバインディングは、エージェントが代わりに行動している人間のユーザーの明確なIDを取得するための標準的な方法を提供します。

セキュリティロジックを基盤となるビジネスコードから切り離すことで、開発者は標準的なWeb APIで使用しているのとまったく同じ、外部化されたAuthZENポリシーエンジンを用いてMCPツールを保護できます。

また、COAZ-MCPは、MCPゲートウェイのような仲介者がこのバインディングを実施できるようにし、それによってビジネスロジック(バインディングを表現する側)を、ゲートウェイを管理する集中的なITチームが制御できるポリシー実施から分離します。

参加するには

COAZ FrameworkとCOAZ-MCP Bindingのドラフト公開は、従来型のAPIと新興のエージェント型Webの両方における、相互運用可能な外部化認可にとって重要な前進を意味します。これらは現時点では単なるドラフトであり、今後成熟のプロセスを経て、将来のバージョンがOpenID Foundation全体によって承認される「Implementer's Draft」として提案され、最終的にはOpenID Foundationが「最終版」を承認することになります。

そこで、今こそID専門家、セキュリティアーキテクト、開発者の皆さんに、OpenID AuthZEN GitHubホームページで公開されているドラフト仕様をレビューし、貢献していただく絶好の機会です。COAZとCOAZ-MCPはあなたの直近のニーズに応えるものでしょうか。現行のドラフトが対応していない、COAZに求めたい機能はあるでしょうか。ドラフトに矛盾や不整合な点はないでしょうか。ご意見があれば、issueを作成してください。

AuthZENワーキンググループに参加し、GitHub上のディスカッションに参加して、標準化された認可の未来を共に形作っていきましょう。

著者について:

Atul Tulshibagwaleは、OpenID AuthZENワーキンググループの共同議長であり、SGNL買収後のCrowdStrikeでContinuous Identity Strategy担当のシニアディレクターを務めています(SGNLではCTOでした)。Atulはフェデレーテッドアイデンティティのパイオニアであり、CAEPの発明者です。以前はGoogleのソフトウェアエンジニアとして、OpenID FoundationのShared Signals and Eventsワーキンググループの基盤となっているContinuous Access Evaluation Protocol(CAEP)を構想しました。それ以前は、Trustgenix(Hewlett Packardに買収)の共同創業者兼CEOとして、後にほぼすべてのIDベンダーに採用されることになる「フェデレーションサーバー」という概念を定義しました。彼はLiberty AllianceやSAML 2.0といったオープンスタンダードの策定にも貢献しました。その後、HPでFederation担当ディレクターを務めました。

Alex Olivierは、OpenID AuthZENワーキンググループの共同議長であり、AuthZEN標準の実装者であるAuthorization Management PlatformCerbosの共同創業者兼最高製品責任者でもあります。認可システムを専門とし、近年はワークロードIDとAIセキュリティに注力しています。Microsoft、Qubit、Zencargo、複数のスタートアップで10年以上にわたり認可システムの構築とスケーリングに携わった経験を持ち、Model Context Protocol(MCP)サーバーおよびAIエージェントの保護について幅広く執筆・発表してきました。ISC2 Congress、Identiverse、EIC、KubeCon、Google Cloud NEXTなど、認可・AI・セキュリティ・IDに関するイベントで頻繁に登壇しており、標準の策定と実践的な実装経験を組み合わせながら、従来型アプリケーション、分散ワークロード、新興のAIシステムにおける認可の未来に注力しています。