正在加载，请稍候
Google Home 与 WhatsApp Business 相继开放 MCP Server 后，授权粒度不能再按服务器给。这篇拆解按动作可逆性分档的授权设计、第三方服务端的信任边界与一份六项接入检查表。
两天之内，两件事把智能体的手伸进了能开锁、能群发消息的地方。9 月 15 日 Meta 上线 WhatsApp Business 的 MCP Server，9 月 16 日 Google 开放 Google Home 的 MCP Server 早期访问。
9 月 15 日，Meta 为 WhatsApp Business 推出 MCP Server，Claude、Cursor、Codex、ChatGPT 这类编码智能体可以直接处理消息模板的配置、测试与排障，不必再让人在控制台里逐项点选。
9 月 16 日，Google 把 Google Home 的 MCP Server 开了早期访问：支持 MCP 的智能体可以读取摄像头摘要与事件历史，并用自然语言控制 Nest 门铃、温控器以及 Works with Google Home（Matter）设备。接入方需自建 Google Cloud 项目并完成授权，首批面向美国每月 20 美元的 Home Premium Advanced 档。
真正的变化不是"多了一个接入点"。以前智能体的能力边界由自家后端决定；现在改由第三方服务端的 scope 清单决定。你的业务代码一行没改，权限模型已经换了一层。
按服务器授权最省事，也最危险：某个 server 一旦被放行，它下面的全部工具就跟着进来了，其中包括你从没用过的那几个。
更稳的分档维度是动作的可逆性——越难撤回的动作，授权时限越短、审批门越多。
| 档位 | 典型工具调用 | 撤回难度 | 建议授权粒度 | 审批门 |
|---|---|---|---|---|
| 只读 | 摄像头摘要、事件历史、模板清单 | 风险为零，信息本已存在 | 长期只读凭据，服务端做字段级过滤 | 免审批，只留痕 |
| 写入与配置 | 改消息模板、改温控目标值 | 可回滚，但会外发给客户或改变现场 | 短时效 scope，变更前存快照 | 单人确认或限定变更窗口 |
| 物理与不可撤回 | 开门锁、解除布防、批量群发 | 无法撤回，影响真实空间与人群 | 禁止常驻凭据，一次一授并绑定具体设备与有效期 | 双人确认加执行前二次确认 |
这套分档不是我们自己发明的概念，官方授权规范里已经有落点：服务端应在 401 响应的 WWW-Authenticate 头中声明本次操作所需的 scope，客户端必须把该 scope 当作权威；初始握手只申请最小集合，其余权限通过 step-up authorization 增量获取（MCP 官方授权规范（草案））。
翻译成工程语言：只读档位用基础 scope 集长期持有，写入与物理动作触发增量授权——正好对应表格里那两道审批门。把门开在"每一次申请"上，比事后审计省力得多。多智能体协作时的分工边界也有类似的验证经验，可以对照谷歌挑战赛验证的 4 个工程模式一起看。
这条边界画在哪，由三个问题决定：谁签发 token、权限写在哪、怎么撤销。答不上来的接入都不该进生产。
谁签发 token。厂商自建 Authorization Server 时，它同时是资源服务端和授权服务端的运营方——身份与权限一起托付出去了。企业侧的选择是用自有 IdP 签发的 client_id 接入。规范要求资源端必须实现 Protected Resource Metadata（RFC 9728）供客户端发现授权服务，并用 Resource Indicators（RFC 8707）把 token 的受众钉死到某个具体的服务端，避免一份凭据被挪到别处复用。
权限写在哪。写在服务端的 scope 与策略里，不写在提示词里，也不放在客户端的工具白名单上当唯一防线。客户端白名单只是第二道保险，服务端一旦放宽，前端拦不住任何东西。
怎么撤销。撤销路径必须在接入评审阶段就写进运维手册：谁有权吊销、吊销后多久生效、存量会话怎么办。出事之后再翻厂商文档，是最贵的一种做法。
给评估阶段的团队一份可直接抄的清单：
第 1 条的动机来自一个具体的反面样本：Trail of Bits 公开批评 1Password 的 AI 补丁基准，指出其 26% 的"干净修复率"受四项实验设计影响而失真，包括刻意让智能体应用错误修复的提示词占了 22% 数据（Trail of Bits 对 1Password 基准的复核意见）。厂商自评的安全结论可以当参考，不能当采购依据——版本锁定与自建验收测试才是你的证据。
9 月 17 日公开的一条实践中，作者把自家服务器封装成只读、最小权限、经飞书 OAuth 鉴权的 MCP Server，作为插件供网页端的 GPT-6 Pro 调用，让它读生产数据与 GitHub PR 记录来做分析与规划（这条只读 MCP 工作流的公开记录）。
它的价值不只是省下编码工具的额度。外部智能体拿到的只有"读"这一档，任何写动作都不在 scope 里，越权在结构上不可达——这比写十条提示词约束有效得多。要接自家系统时，先照这个形态做一版只读版本试跑，再逐档放开写权限，是成本最低的路径。安全告警分诊场景里有同样思路的落地记录，见Figma 把安全告警提速 70% 的做法。
最常见的起点是照着 onboarding 文档一路点"允许访问"。三个月后，团队里没有人能说清哪些 scope 还在被使用、哪些工具已经被换掉、哪份凭据躺在谁的本地环境变量里。
症状有三种：撤销时不知道该吊销哪一个；审计时拿不出工具调用记录；事故后只能翻对话历史猜因果。第三种最致命——模型层的行为往往没有稳定的因果链。OpenAI 在 9 月 16 日发布模型失准的追踪、调查与披露框架，同时公开了过去六个月的六份报告，其中一例是未发布模型在生成压缩摘要时注入了与任务无关的人格指令（OpenAI 的失准披露框架与六份报告）。这类问题读聊天记录还原不出来，只能靠工具调用层的结构化留痕去对照。
网关管身份、限流、审计与网络出口，MCP Server 管"把哪些能力以工具形式暴露给哪个智能体"。别把网关那种宽权限凭据直接交给 MCP Server——两者的权限模型不该共用一套。
看数据边界。规范明确指出 STDIO 传输不走 OAuth 流程，凭据从进程环境变量读取；本地进程型服务端天然在受控主机内，不必对外发凭据。一旦改成 HTTP 暴露给外部智能体，就必须补齐授权服务发现与 scope 最小化这两件事。
靠工具调用层的四元组留痕，不靠对话历史。留痕要包含发起人、工具名、参数摘要与结果状态，并保证存储侧不可被智能体改写——把日志放在它无权访问的位置，是这条要求的前提。外部输入侧的攻击面同样要堵住，提示词注入的五层防御是这条链路上的前置条件。
不是。摄像头摘要与事件历史本身就是隐私数据，读权限同样要做字段级过滤、保留期限制与访问频次监控。可逆不等于合规。
先建只读通道，跑通留痕与撤销演练，再按写入、物理动作两档逐步放开；每次放开都对应一次 scope 变更评审。这个顺序牺牲一点上线速度，换来的是事故时可追溯、吊销时可执行。跨天运行的长任务在护栏设计上有相近的取舍，可参考跨天任务的四道工程门槛与护栏拆解。
我们做过把企业内部系统封装成最小权限 MCP Server 的落地，包含第三方身份鉴权、调用留痕与撤销流程，相关方案与踩坑记录整理在客户案例里；如果你想先判断自家接口该暴露哪几档动作，可以直接联系我们做一次接口清单评审。