7月6日、Matt Saundersが「AI Model Context Protocol Adds Centralised Auth for Enterprise」と題した記事を公開した。MCPのエンタープライズ向け集中認証拡張「Enterprise-Managed Authorisation（EMA）」がStableに昇格し、組織のIDプロバイダーを通じたMCPサーバーアクセス管理が可能になった経緯と技術詳細を解説している。

繰り返しの認証プロンプトが「最大の痛点」だった

Model Context Protocol（MCP）は、AIエージェントが外部ツールやデータソースと接続するためのAnthropicが主導するオープンプロトコルだ。エンタープライズ環境での採用が進む中で、ひとつの問題が繰り返し指摘されていた。MCPサーバーごとに毎回認証プロンプトが表示されるという問題だ。

従来のMCPの認証モデルはユーザースコープで設計されており、インタラクティブな認証フローを前提としている。社員が複数のMCPサーバーを使おうとするたびに個別の同意が必要になり、セキュリティチームがポリシーを一元管理しにくく、私用アカウントと業務アカウントの境界も曖昧になりやすかった。

MCPチームはこれを「エンタープライズ展開における最大の痛点のひとつ」と明言している。EMAはこうした現場の声を受け、DraftからStableへの昇格プロセスを経て今回の正式仕様となった。MCPの仕様策定はGitHub上のオープンなレビュープロセスで行われており、EMAもコミュニティからのフィードバックを取り込みながら段階的に成熟してきた経緯がある。

EMAがやること・やらないこと

EMA（Enterprise-Managed Authorisation）の核心は、認証の意思決定を「各ユーザーと各サーバーの間」から「企業のIDプロバイダー」へ移すことにある。

技術的な仕組みとしては、Identity Assertion JWT Authorisation Grant（ID-JAG）というOAuth 2.0拡張を使う。ID-JAGはクライアントがIDプロバイダーとの既存の信頼関係を証明するJWTアサーションを取得し、それをMCPサーバー側の認可サーバーへのAssertionとして提示してアクセストークンに交換する仕組みだ。フローの核心はIDプロバイダーとMCPサーバー側認可サーバーの間に確立される信頼チェーンにあり、ユーザーは一度組織のIDプロバイダーにサインインすれば、組織が承認済みのMCPサーバーには追加の認証プロンプトなしでアクセスできる。

ただし、EMAが対象とするのはあくまで「接続レベルの認可」であり、エージェントが接続後に実行する個別アクションへの認可ではない。公式ガイドも「これはランタイムの個別アクションに対する認可ではない」と明示しており、エージェントがシステム内に入った後の操作制御については、組織側で別途ポリシーを用意する必要がある。

この点についてエンジニアのEhsan Hosseiniは自身のブログで、「EMAは接続レベルの制御であり、センシティブなランタイム判断に対する個別ポリシー適用の代替にはならない」と整理している。

現時点の対応状況

現状は「有望だが部分的」という段階だ。EMAはIDプロバイダーとMCPサーバーの両方が拡張をサポートしている必要がある。

今回の立ち上げで名前が挙がっているのは以下の通り：

• IDプロバイダー：Okta（Cross App Accessアプローチで最初にサポート）、Microsoft
• クライアント：Anthropic（Claude、Claude Code、Cowork向けの共有MCPレイヤー）、Visual Studio Code
• MCPサーバー：Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase（Slackなどは対応進行中）

HosseiniのブログでもEMAはあくまでadditive（追加的）な拡張であると指摘されており、対応IDプロバイダーを使っていない組織は従来のフォールバックパスが引き続き必要になる。

コミュニティの反応

コミュニティの反応は概ね肯定的だ。Jiquan NgiamはLinkedInで、「EMAはエージェントとデータを組み合わせる際に最も厄介な部分のひとつに対処するもので、awkwardな認証フローを避けることでセキュリティと可観測性の両方を改善できる」と評価している。またNgiamは同投稿の中で次のようにも述べている。

「EMAはMCPサーバーアクセスの構造的な修正だ。ユーザーごとのプロンプトから、企業共有のコントロールプレーンへの移行を意味する」

エンタープライズでAIエージェントを内部ツールと接続しようとしているチームにとって、今回のStable昇格は認証まわりの運用コスト削減に直結する可能性がある。一方で、接続後のアクション制御という「次の課題」はまだ各社が独自に解決する必要がある状況だ。

詳細はAI Model Context Protocol Adds Centralised Auth for Enterpriseを参照していただきたい。