我第一次意识到 MCP 授权有问题，不是因为某个工具突然报错，而是因为它什么都没报。
服务器名字没变，界面还在原来的位置，调用也能继续。可一旦去看配置，command、参数和工具说明已经不是上次同意的内容。
这类变化不一定恶意，却会让旧授权失去上下文。你当时同意的是一个只读搜索工具，后来它可能多出写文件、发网络请求或执行命令的能力。如果客户端只记住服务器名，用户很容易把“认识它”误当成“仍然信任现在的它”。
这篇文章不做 MCP 入门，也不复述安全攻击清单。只解决一个问题：服务器的配置和能力变了，怎样让自动化先停一下，再由人决定是否继续。
1. 官方机制到底检查什么
GitHub 在 2026 年 7 月 14 日发布的 Visual Studio June Update 中提到，Visual Studio 会在启动时把 MCP 服务器的 configuration fingerprint 和 asset fingerprint 与可信基线比较。Microsoft Learn 对流程给出了更细的两阶段说明。
在 Visual Studio 2026 18.7 及以上版本中，这项功能默认开启。
服务器进程启动前，客户端先比较当前配置和上一次可信配置。公开文档列出的配置示例包括 transport type、URL、command 和 arguments。发现差异时，信任对话框会出现在进程启动之前。
服务器启动并加载资产后，客户端再比较 tools、prompts、resources、resource templates、instructions 等能力与资产的指纹。发现变化后，界面要求用户重新选择 Trust 或 Do not trust。
Trust 会接受本次变化，并更新后续比较使用的可信基线。Do not trust 会停止本次启动，下一次激活还会再次验证。
这个机制有几个容易被标题省略的边界。
首次激活不会先弹一次，而是隐式建立配置和资产基线。内置服务器、组织策略为 RegistryOnly、用户选择 Always Trust，或者主动关闭设置时，也会跳过提示。
官方没有公开具体指纹算法、基线保存位置、跨机器同步方式或防篡改机制。它也不是代码签名、发布者认证、恶意软件扫描或提示词注入检测。变化只说明“和上次不同”，不能替你判断这次更新是否值得信任。
公开资料能确认的是启动和重新激活阶段的比较。Visual Studio 另会处理运行时 notifications/tools/list_changed，重置工具权限并重新拉取工具列表，但文档没有说这个事件一定触发同一套可信基线弹窗。
2. 为什么我要先做一个本地假服务
当前执行环境是 Linux，没有 Visual Studio、Windows、devenv 或 PowerShell。因此我没有制造一段看似完整的“弹窗亲测”。
我先做了一个不会碰生产数据的 MCP fixture，为后续目标机实验准备稳定对照。
它只走 stdio，不监听端口，不发网络请求，不读取 .env。唯一工具 echo_local 只回显输入，不读写用户文件，也不执行 shell。除此之外，它只暴露一条 prompt、一条静态 resource、一条 resource template 和 instructions。
实验设计包含 6 个场景：
- baseline：初始配置与资产
- control-no-change：原样重新运行
- command-change：把启动命令换成指向同一 Node 二进制的别名
- arguments-change：只修改一个实验标签参数
- tool-description-change：只修改工具描述
- resource-change：只修改 resource 描述
工具和 resource 变体都用机器 diff 确认，只改目标字段。这样到了 Windows + Visual Studio 目标机，一旦出现不同结果，才有可能判断差异来自哪一层。
本地协议冒烟 6/6 通过。标准 MCP TypeScript SDK 可以初始化 fixture，并列出 1 个 tool、1 个 prompt、1 个 resource 和 1 个 resource template；工具调用与资源读取均成功。
这只能证明夹具能正常跑，不能证明 Visual Studio 对每个字段都会弹出信任对话框。
3. 单变量实验该怎么跑
在 Windows + Visual Studio 2026 18.7+ 目标机上，我会把每个场景拆成独立 server name 和独立 solution。Trust 与 Do not trust 分支也分开，防止某一次接受更新了基线，污染后面的试次。
第一步先激活 baseline。根据官方文档，首次激活应当不弹信任框，而是直接建立初始基线。这个阶段要保存 Visual Studio 版本、Node 版本、设置页、MCP 配置、完整屏幕截图和 server JSONL 日志。
第二步跑无变化对照。如果所有内容相同却出现提示，说明环境、基线或操作步骤存在额外变量，不能直接进入变更组。
第三步依次跑 command、arguments、tool description 和 resource 四个变更。每次点击按钮前，先截完整弹窗，逐字记录标题、正文、差异字段、按钮和复选框。
Trust 分支要观察接受后工具是否可用，以及同一版本再次激活时是否不再提示。Do not trust 分支要观察服务器是否进入可用状态，以及下次激活是否再次验证。
配置变化理论上发生在进程启动前，所以拒绝后 fixture 日志应该没有 process_started。资产变化不同，为了取得 tools 或 resources，进程可能已经启动。不能因为看到进程日志就误判“拒绝没生效”，真正要看的是拒绝后更新后的服务器是否进入可用态、工具能否被调用。
至于 ActivityLog 是否记录用户的批准和拒绝，目前没有官方承诺。目标机里即使没找到，也只能写“本次未观察到”，不能推断产品完全没有其他审计路径。
4. 三道门为什么要叠加
我在本机另外验证了手工 hash 和配置锁定。
7 份 fixture 文件的 hash 校验全部通过。这个方法透明、跨 IDE、容易接进 CI，但它只理解被选中文件的字节。实验里 command alias 和 node 指向同一个二进制，二进制 hash 相同，配置文本却已经变化。这说明只 hash 可执行文件会漏掉启动语义变化，配置、脚本、manifest 都要进入 allowlist。
配置锁定把防线放在写入阶段。我用 lock 文件核对 baseline manifest 与 server 当前 hash，并把配置探针设为只读。降权用户写入 mode 0444 文件时收到 PermissionError，内容没有变化。
但这个结果只证明无写权限主体被挡住。管理员、root、特权服务或有仓库合并权限的人仍可以改。它也看不到服务器运行时动态返回的 tools、prompts 和 resources。
IDE 内置门禁的优势在于，它既能看启动配置，也能看实际加载出的资产，并把最后决定放到用户面前。它的盲区也很明确：首次激活自动建基线，Always Trust、关闭设置和部分组织策略会跳过提示，而且当前没有可确认的集中式审计承诺。
我的做法是把三层叠起来：
- 仓库和文件权限尽量阻止静默改写。
- hash 与 diff 提供机器可读的变化证据。
- IDE 在运行前做最后一次人机复核。
这不是多装三套安全软件，而是把变化从“悄悄发生”变成“可看见、可解释、可拒绝”。
5. 一份最小变更复核记录
平台有没有自动审计，不影响团队先建立自己的记录。最小字段可以只有这些：
- server 名称与负责人
- 基线版本和当前版本
- command、args、URL、transport 的 diff
- tools、prompts、resources、templates、instructions 的 diff
- 新增权限及业务理由
- 版本说明、提交或工单链接
- 批准或拒绝结论
- 复核人和时间
- 回滚方式
如果变化无法解释，就不要因为服务器名熟悉而点 Trust。拒绝不是给服务器贴“恶意”标签，只是表示当前证据还不够。
对于团队共享服务器，我还会加两条规则。
不要随手选择 Always Trust。真要跳过后续提示，必须明确由谁负责变更审阅。其次，配置必须进入版本控制，不能只存在于个人机器或聊天记录里。
6. 今天就能复刻的版本
不需要先搭完整平台。选一台最常用的 MCP 服务器，保存当前 command、args、配置文件和工具清单。给这些文件生成 hash，并把配置纳入 Git。
下一次更新时，先做 diff，再重启。把新增工具、参数和资源逐项解释清楚，最后才决定是否放行。
如果你使用 Visual Studio 2026 18.7+，可以检查下面的设置是否开启：
Tools > Options > GitHub > Copilot > Copilot Chat > Show trust dialog before running tools from an updated MCP server
如果没有该选项，先核对版本。Microsoft Learn 明确要求 18.7 或以上。
真正需要建立的习惯不是“谨慎一点”，而是把授权从永久通行证改成可复核的版本化决定。
第一次授权回答的是“当时能不能用”。配置和能力变化后，我们需要重新回答一次：“现在运行的，还是我同意的那一个吗？”
资料与实验状态
官方资料：GitHub Changelog（2026-07-14）、Visual Studio Blog、Microsoft Learn MCP server trust dialog、Visual Studio 2026 18.7 release notes。
已实跑：本地无凭据 MCP fixture、6 场景协议冒烟、标准 SDK 兼容、资产单变量 diff、7 文件 hash、配置 allowlist、只读权限探针。
待验证：目标账号和地区可见性、Visual Studio 实际弹窗粒度、Trust / Do not trust 的 UI 行为、ActivityLog 或其他审计留痕。