MCP の認可を IdP に寄せる: Enterprise-Managed Authorization（EMA）と managed-mcp
社員が MCP コネクタごとに個別 OAuth 同意する運用をやめ、IdP（現状 Okta）のポリシーで一元的に付与・失効する。勝手な MCP 接続は別途 Claude 側の配布統制で止める。
EMA は MCP の公式拡張で、仕様は2026-06-18に安定版。基盤は IETF で標準化中の ID-JAG（Okta の実装名が Cross App Access）。ユーザーは SSO でログインするだけで、同意画面なしに承認済みコネクタにつながる。
今すぐできること
- 社内の AI クライアントと、各 SaaS との OAuth 連携・API キーを棚卸しする
- Claude Code では
managed-mcp.jsonを MDM で配り、allowedMcpServers/deniedMcpServers/allowManagedMcpServersOnly: trueで接続できる MCP を限定する（EMA を待たずに効く） - claude.ai の Team/Enterprise では、組織設定のコネクタ管理で許可・ブロックする
- EMA を試すなら、Okta で Cross App Access（Early Access）を有効化し、Claude 側のベータに申し込んで1〜2連携で試す
注意点
- 対応範囲は限定的: Claude EMA の IdP は Okta のみ、クライアントは Claude 系と VS Code など、ChatGPT は非対応（記事執筆時点の2026-06）
- EMA が統制するのは「誰がどのコネクタにつなげるか」だけ。接続後のプロンプトインジェクションや悪性 MCP サーバーは別の対策が要る
- IdP に集約するほど、IdP 侵害時の影響範囲が広がる
出典
- @sudachikawaii · 2026-06-22
- 元記事（CloudNative BLOGs）: blog.cloudnative.co.jp