GitHub Copilotを統合したVisual Studio 2026に、MCP serverのtrust validationが追加された。server起動前にconfiguration、起動後にtools、prompts、resources、instructionsなどのasset fingerprintを過去のtrusted baselineと比較し、差分がある場合は再承認を求める。MCPの更新や侵害による予期しないtool実行を検知する防御層である。

何が変わったか

configurationが変わった場合はserver processを開始する前にtrust dialogが表示される。process開始後に読み込んだasset fingerprintが変わった場合も、前回との差分を示して承認を求める。利用者は一度承認してbaselineを更新する、常に信頼する、拒否して起動を中止する、のいずれかを選べる。

変更前後の差

従来は一度登録したMCP serverの設定や提供toolが更新されても、利用者が差分を明示的に確認しないまま利用する可能性があった。変更後はVisual Studioがbaseline比較を行う。ただし初回接続は暗黙的に信頼され、built-in server、GitHubのRegistryOnly policyで承認済みのserver、Always trustを選んだserver、機能を無効化した場合は検証が省略される。

誰に影響するか

Visual Studio 2026でCopilot ChatとMCP serverを使う全プランの利用者が対象である。社内DB、ticket、cloud、package、deployment toolをMCP経由で接続する組織では、開発者個人の承認が実行権限に直結するため、端末設定と組織policyを組み合わせる必要がある。

期限

強制移行期限はない。機能は既定で有効であり、Visual Studio更新後に利用可能になる。端末更新の展開時に、既存MCP serverで表示されるdialogとbaselineの挙動を確認する。

必要な対応

Visual Studioの設定でtrust dialogを有効のまま維持する。GitHub側のMCP allowlistを使える組織はRegistryOnlyなどのpolicyと連携させる。初回接続は別の審査手順で補い、server配布元、package hash、configuration、権限、接続先を確認する。Always trustはbuilt-inまたは厳格に管理されたserverへ限定する。

実装・移行手順

  1. 組織で利用中のMCP serverと権限を棚卸しする
  2. Visual Studio 2026の対象versionを試験端末へ展開する
  3. trust dialog設定が有効であることを確認する
  4. configuration変更とasset変更を意図的に発生させる
  5. 差分表示、承認、拒否、再起動時の挙動を確認する
  6. GitHubのMCP allowlist policyを設定する
  7. 初回接続の審査とAlways trustの条件を文書化する
  8. 拒否時のsecurity問い合わせと復旧手順を整備する

失敗しやすい点

初回接続もdialogで保護されると思う、Always trustを安易に選ぶ、configurationだけを確認してasset差分を無視する、dialogを開発阻害として一括無効化する、といった問題が起きやすい。baselineが変わった理由を確認せず承認すると、検知機能の意味がなくなる。

リスク

悪意あるtool追加、prompt・instructionの差し替え、接続先変更、package supply-chain侵害、過大なMCP権限がある。trust validationは変更を検知するだけで、安全性を判定するものではない。正規updateでも危険な権限追加が含まれる場合があるため、差分の意味を人が評価する必要がある。

評価方法

  • 管理対象MCP serverの棚卸し率
  • allowlist適用率
  • trust dialogの表示件数
  • 承認、拒否、Always trustの割合
  • 未審査の初回接続件数
  • configuration・asset差分の確認時間
  • 誤承認または不正serverの検出件数
  • MCP関連security incident数
  • 開発者問い合わせと作業停止時間

ロールバック

誤検知や業務停止が起きた場合でも機能全体を無効化せず、問題のserverだけを停止し、既知の安全なversionとconfigurationへ戻す。baselineを更新する前に差分を保存し、server package、registry、署名、配布経路を確認する。緊急時はMCPなしの通常Copilot機能へ切り替える。

編集部分析

今回の機能はMCP supply chainに対する有用な変更検知だが、初回接続の暗黙信頼とAlways trustという明確な穴が残る。組織policyで入口を絞り、端末側baselineで更新を検知する二層構成が適切である。利用者へ「dialogが出たら承認」ではなく、「変更理由を確認できなければ拒否」と教える必要がある。

実務チェックリスト

  • [ ] MCP serverと権限を棚卸しした
  • [ ] trust dialogを有効のまま維持した
  • [ ] 初回接続の審査を別途設けた
  • [ ] GitHub allowlistを設定した
  • [ ] Always trustの対象を限定した
  • [ ] configurationとasset変更を試験した
  • [ ] 拒否時の問い合わせ経路を作った
  • [ ] MCPなしの代替手順を用意した

一次情報