MCPは「Enterprise-Managed Authorization」の安定版スペックを公開しましたが、その他のマシン間（machine-to-machine）アイデンティティに関するドラフト（OAuth client-credentialsのドラフトや2つの公開プロポーザルを含む）は、まだ未完成のままです。Model Context Protocolを使用して自律型エージェントを運用しようとしている人にとって、これは、現在のプロトコルが人間のユーザーを検証することはできても、無人のプロセスが自称する通りの存在であることを証明する即時利用可能な手段を提供していないことを意味します。

ロードマップが重要である理由

Model Context Protocol (MCP) のロードマップでは、エージェントのアイデンティティとセキュリティが最優先事項の一つとして挙げられています。リリース予定だった項目は4つありました：人間中心のブラウザフロー、サービス向けのOAuth client-credentialsフロー、DPoPベースのトークンバインディング、そしてワークロード・アイデンティティ・フェデレーション（workload-identity federation）メカニズムです。そのうち、最初の「Enterprise-Managed Authorization」のみが安定版のステータスに達しています。

安定版スペックが実際に提供するもの

Enterprise-Managed Authorizationを使用すると、IT管理者は各従業員がすべての接続を承認するのではなく、単一のコンソールからサーバーへのアクセスを許可できるようになります。このフローはブラウザのリダイレクトとユーザーログインを使用するため、ノートPCを操作している人間が認証を行うことで、サーバーはそのユーザーのセッションを信頼します。

その限界は明白です。このプロセスにはキーボードを操作する人間が必要です。夜間に実行される、データを処理する、あるいはアラートに対応するエージェントには、ログインボタンをクリックしてくれる人がいません。その結果、無人のエージェントに依存するあらゆるデプロイメントは、現在MCPが保証している唯一のスペックを利用することができません。

ドラフトの選択肢とその欠点

2つのドラフト拡張機能が、エージェントに独自のアイデンティティを与えることを目指しています。

  • SEP-1932 (DPoP) – トークンを公開鍵・秘密鍵ペアにバインドし、盗まれたトークンを無効化します。
  • SEP-1933 (Workload Identity Federation) – エージェントがクラウドプラットフォームですでにプロビジョニングされているアイデンティティを継承できるようにします。

両者はオープンなプルリクエストとして存在しており、公式スペックにはまだマージされていません。それまでの間、文書化されているもう一つの選択肢は、事前に登録されたシークレットを必要とするOAuth client-credentialsフローのみです。エージェントが読み取れる場所にそれらのシークレットを保存することは、典型的な攻撃対象領域（attack surface）を生み出します。つまり、シークレットが漏洩した場合、攻撃者は誰でもエージェントになりすますことができてしまいます。

今すぐ本番環境で実施できる実用的なステップ

プロトコルがまだネイティブなエージェント・アイデンティティを提供していないため、チームはアイデンティティ管理をMCPの外に移動させることで、エージェントを保護することができます。

  1. ワークロード層で検証可能なアイデンティティを発行する。 SPIREのようなシステムは、ホストの信頼のルート（trust root）に紐付けられた短寿命の証明書を生成し、静的なシークレットを排除します。
  2. ゲートウェイで認証情報を終端する。 フロントエンドサービスがAPIキーやトークンを保持し、エージェントに代わってリクエストを転送することで、実行環境からシークレットを遠ざけます。
  3. トークンの内容ではなく、検証されたアイデンティティに基づいて認可を行う。 認証（誰が呼び出しているか）と認可（何ができるか）を分離することで、認証方法が変更された場合でもポリシーを適用できるようにします。

次に注目すべき点

2つのオープンなプルリクエスト（DPoPバインディングとワークロード・アイデンティティ・フェデレーション）は、MCP内における真のマシン間アイデンティティ標準への唯一の道です。コミュニティがこれらをマージすれば、エージェントはシークレットを公開することなく、秘密鍵の所有を証明したり、クラウドから発行されたアイデンティティを継承したりできるようになります。それまでは、あらゆる本番環境へのデプロイメントは、外部のアイデンティティ・フレームワークに依存するか、静的な認証情報のリスクを受け入れる必要があります。

結論は明確です。MCPは現在、リクエストの背後にいる人間を認証することはできますが、リクエストを行っているソフトウェアをまだ認証することはできません。安全な自律型エージェントを必要とするチームは、スペックの確定を待つべきではありません。今日からワークロード層でアイデンティティを構築し、保留中のDPoPおよびフェデレーションのプロポーザルを注視する必要があります。