GitHub Copilot CLI 1.0.83、MCPのCIMDログインに対応し、サンドボックスのファイルツールが読み取れるパスも拡大

GitHub Copilot CLI 1.0.83では、MCPのID、企業ポリシー、ローカルサンドボックスという3つの制御領域が同時に調整された。相互運用性の面で最も重要なのがClient ID Metadata Document（CIMD）だ。OAuthクライアントはHTTPSドキュメントのURLをそのまま`client_id`として使用でき、認可サーバーはそこから名称、リダイレクトURI、公開鍵などの情報を取得する。これにより、未知のMCPクライアントがすべてDynamic Client Registrationに依存する必要がなくなる。組織をまたぎ、事前の登録関係がないMCPエコシステムに適しているが、認可サーバーが対応を明示していることが前提となる。

CIMDは認証を不要にする仕組みではない。IETFのドラフトでは、ドキュメント内の`client_id`が取得元URLと完全に一致すること、リダイレクトURIを厳密に照合すること、共有シークレットや秘密鍵をドキュメントに含めないことが求められている。サーバー側ではさらに、SSRFの防止、リダイレクトの自動追従の禁止、特殊用途IPアドレスの除外、ドキュメントサイズの制限が必要だ。これらを怠れば、クライアントメタデータの動的取得そのものが新たな攻撃対象になり得る。

より直接的な移行リスクは、サンドボックスのパス設定にある。1.0.83では、内蔵ファイルツールとサンドボックス内のshellが、開発ツール用パスへのアクセス許可を共有する。公式には、registry tokenを含む可能性のある`~/.npmrc`も対象になり得ると特に指摘されている。この利便性が不要な場合は、`sandbox.allowDevToolAccess`を`false`に設定すべきだ。これにより、エージェントがパッケージマネージャーの設定を読み取る際の挙動は統一される一方、prompt injectionや誤操作によって取得され得る秘密情報の範囲も広がる。サンドボックスから読み取れることを、そのデータをモデルへ送信したりツールの出力に含めたりしても安全であることと同一視してはならない。

新バージョンではこのほか、企業ポリシーでブロックされたMCPサーバーが管理ポリシーの読み込み完了前に起動する可能性があった競合状態を修正した。また、HTTPS proxyでのmTLS、リポジトリアカウントに応じた`gh`認証情報の注入、カスタムエージェント向けのモデル候補リストも追加された。エンジニアリングチームはアップグレード時に、コールドスタート時のポリシーをテストし、開発ツールの認証情報を棚卸ししたうえで、CIMDのサーバー側に完全なURL検証とSSRF対策が実装されていることを確認すべきだ。ログイン処理が成功することだけを確認して済ませてはならない。