小岛AIAI 航行日志

小岛 / 岛刊社 / 文章

Google Workspace MCP 开始拒绝旧 OAuth：要换 Client ID

小岛AI

Workspace MCP 已开始拒绝未标为 AI agent 的 OAuth 客户端。错过窗口的旧 Client ID 不能靠补 scope 修复；这篇把受影响范围、迁移判断和上线前检查拆开。

Skill 与 MCP行业与公司Agent 工程

如果你把 Claude、Codex 或内部 agent 接到了 Google Docs、Drive、Sheets、Gmail 或 Calendar，最近有一类故障很容易被误判：授权页看着没问题，scope 也没少，但 MCP 请求突然被拒绝。

这次不是 OAuth scope 配错了。Google 给 Workspace MCP 加了一道关于 OAuth Client 用途 的门。

从 11 月 11 日起，调用 Workspace MCP 的 user-delegated OAuth 2.0 Client，必须在 Google Auth Platform → Clients 中被标记为「Use this client for an AI-powered agent」。

在 11 月 12 日前没有完成标记的旧 Client，会保持 non-agentic，不能继续调用 Workspace MCP。Google 写得很直白：要恢复 MCP 使用，需要新建一个标为 agentic 的 Client，再把应用切过去。

官方 release notes 已把这项要求同步到了 Chat、Gmail、Calendar、Docs、Drive、Sheets 和 Slides 的 MCP 条目里。

对正在做「让 agent 看资料、改文档、读表格、处理邮件」的人来说，今天最有价值的不是再翻一遍 OAuth scope 列表，而是先回答一个问题：你现在发 token 的那个 Client ID，到底是不是给 agent 准备的？

Google Workspace MCP 的 OAuth Client 分流：普通 REST API Client 与 agentic MCP Client 走不同入口

图：这次变化区分的是 OAuth Client 的用途，不是给同一个 Client 多加一个 scope。

它切断的不是所有 Workspace API

这里最容易把排障带歪。Google 的要求针对的是 Google Workspace MCP servers，而不是所有 Google Workspace REST API。一个普通后台服务继续通过 Drive API 拉文件、用 Gmail API 发信，并不会因为没有 agentic 标记而自动失效。官方也特别说明：只调用普通 REST API、并非 AI agent 的应用不受这项变更影响。

受影响的是另一条链路：你的 AI 客户端把自然语言任务交给 MCP host，MCP host 再代表用户去读写 Workspace 资源。比如「找出这个项目文件夹里本周更新的三份报价单」「把会议记录里的行动项填进表格」「根据邮件线程起一版跟进草稿」。这些请求可能最终仍调到了 Drive、Docs 或 Gmail 的能力，但入口是 MCP，所以 OAuth Client 要被声明为 agentic。

这也解释了为什么「把 scope 补全」通常解决不了这次报错。scope 决定 token 能做什么；agentic 标记回答的是这个 Client 是否用于 AI agent。两层都和权限有关，却不是同一层。前者像钥匙串里有哪几把钥匙，后者更像给钥匙串贴上使用场景的标签。Google 现在要求 Workspace MCP 只接受贴了这张标签的 Client。

还有一个时间上的坑。公告在更早的 release note 中出现，但真正的服务端拒绝从 11 月 11 日开始；11 月 12 日之后仍未标记的旧 Client 会保持 non-agentic。今天看到 MCP 连不上，不要只把它当成短暂的传播延迟或缓存问题。查清 Client 的状态，能少走一轮无效重试。

旧 Client 能不能原地补救，先按这个判断

Google 给出的迁移路径不是「把旧 Client 改个勾选项」这么简单。对错过窗口的 Client，官方说法是新建一个 agentic Client，并更新应用使用它。因此最稳妥的决策不是猜控制台会不会出现补救按钮，而是先把现有流量按用途分开。

可以把判断压缩成三句：

  1. 这个 Client 有没有实际调用 Workspace MCP？没有，就不在本次迁移范围内。
  2. 它是否同时服务 MCP 和普通 REST API？是，就不要把两种流量继续绑在同一个 Client 上。
  3. 如果它已经错过 agentic 标记窗口，应用是否能完成新 Client 的 redirect URI、token 存储与部署配置切换？能，就按新 Client 迁；不能，先停在受控的验证环境里，不要把生产 agent 反复重试到限流或日志泛滥。

Workspace MCP 迁移判断图：确认是否使用 MCP，分离 agent 与普通 REST API，随后切换新 Client

图：迁移不是“全量换 OAuth”，而是把 agent 的身份、配置和回滚边界单独拉出来。

如果你的旧 Client 同时承载了 MCP 与非 agent 的 REST API，Google 的建议尤其值得照做：新建一个只给 agent 用的 Client，把它标为 agentic；旧 Client 留给普通应用。这样做的好处不只是绕过这次限制。以后审计「哪一段授权能让 agent 读取组织文件、创建草稿或更新日历」时，身份边界也更清楚。

这一步会牵出一些现实工作：更新 Client ID 与 redirect URI，重新走一次用户授权，替换部署环境里的配置引用，确认 token 缓存不会把旧 Client 的凭据继续拿来用。不同 MCP host 的配置位置不一样，不能照搬一段网上的 JSON。Google 的 Workspace MCP 配置指南 和各产品的 setup 文档才是准绳；例如 Docs MCP 的配置页 明确要求 user-delegated OAuth Client 在控制台标为 AI-powered agent。

用一条最小任务验收，不把整套自动化直接推到生产

迁移完成后，别一上来就让 agent 跑批量归档、群发草稿或改几十个表格。拿一条读操作和一条低风险写操作做验收，已经足够暴露大多数问题。

可以用下面这张清单过一遍：

  1. 新 Client 出现在 Google Auth Platform 的 Clients 列表，且用途标记为 AI-powered agent。
  2. MCP host 的 Client ID、redirect URI 与部署配置已指向新 Client；日志里不再出现旧 Client ID。
  3. 用户重新授权后，读取一个预先指定的 Docs 文档或 Drive 文件可以成功，且只返回该用户本来有权访问的内容。
  4. 选择一个可回滚的低风险写操作，例如给测试文档追加一行或给测试表格写入一个单元格；确认改动和审计记录都落在预期位置。
  5. 临时撤掉新 Client 的配置，确认连接器会干净失败或停止执行，而不是悄悄退回旧 token。

其中这一项有点像故意找麻烦，但很有用。很多迁移在「第一次成功」时看不出问题：本机仍留着旧 token、某个 worker 没重启、或者 staging 和 production 指向了不同项目。验证失败路径，才知道切换有没有真的完成。

这件事真正改变了什么

Google 不是在发明一个新协议，MCP server 也还在 Developer Preview。它做的是把「这个 OAuth Client 是给 agent 用的」从团队约定，变成平台会执行的身份条件。

对个人试用者，这多半是一项配置迁移；对把 Workspace 接进内部 agent 的团队，它更像一次小型资产盘点：哪些 Client 能读写公司资料，哪些只是普通 Web 应用在用，谁负责用户授权，撤销时谁会受影响。把这些东西留在同一份 OAuth 配置里，平时很省事，出问题时却很难判断影响面。

所以，今天最短的行动路径不是「研究 MCP 到底安不安全」，而是打开正在使用的 Google Cloud 项目，列出所有调用 Workspace MCP 的 Client，确认它们的用途与部署位置。还没接 MCP 的团队不需要为了这条公告去重做 REST API；已经接上的团队，则该把 Client 身份分出来了。

你们的 Workspace 连接器是把 MCP 和普通 REST API 放在一个 OAuth Client 里，还是早就拆开了？这个问题往往比「模型能不能调用工具」更早决定生产环境会不会突然断线。

小岛AI｜记录一线实战、踩坑与成长