还有一周多的时间，所有把 Google Workspace 接给外部 AI Agent 的开发者都要做一个选择：给自己的 OAuth 客户端打上 is_agentic 标记。不打，11 月 11 日起 Workspace MCP 服务器直接拒绝请求；11 月 12 日之后，这个设置在存量客户端上永久锁死，想改只能新建客户端 ID、重新配置所有依赖。

这件事表面是一次例行的 API 变更，实际上是目前为止最明确的一个信号：Agent 流量作为一类独立的「身份」，正在进入企业级治理的第一线。

发生了什么

Google 正在推广 Workspace MCP 服务器，让外部 AI Agent 通过开放 MCP 协议操作 Gmail、Drive、Calendar 等 Workspace 应用。在正式铺开之前，Google 在 OAuth 2.0 客户端上引入了一个 is_agentic 设置：只有被标记为 agentic 的 OAuth 客户端，才有资格调用 Workspace MCP 服务器。

时间线很紧：10 月 12 日起，开发者可以在 Google Cloud 控制台勾选「Use this client for an AI-powered agent」；11 月 11 日起，未标记的客户端调 Workspace MCP 会被拒绝；11 月 12 日起，存量客户端的 is_agentic 设置变为永久，错过窗口就只能新建 Client ID 并更新全部配置。Google 已经在给受影响的 Cloud 项目发主题为「[Action Required]」的邮件。

配套的还有一条最佳实践：如果你的产品同时服务人类交互（走标准 REST API）和 AI Agent 工作流，必须维护两套独立的 OAuth Client ID。给客户端打 agentic 标记不会授予额外的 scope，也不绕过用户授权——它的作用是让两类流量在身份层分道扬镳。

为什么这个设计值得琢磨

MCP 生态过去一年的主叙事是「连接」：协议把工具暴露给模型，生态爆炸式增长。但企业管理员面对的现实问题一直悬而未决——安全审计工具里，一个代表用户自主行动的 Agent，和一个普通的第三方 Web 应用，看起来一模一样。

Google 的解法朴素但关键：把「这是不是 Agent」这个问题，前置到 OAuth 身份层解决。打上标记之后，Workspace 管理员才能在 Admin 控制台和安全调查工具里，对 Agent 流量单独施加访问控制和安全策略，而不干扰人类用户的正常使用。

这个思路其实划定了一条分界线：Agent 治理的第一步不是限制 Agent 能做什么（那是 scope 和 consent 的事），而是先承认 Agent 是一种不同性质的流量主体。身份分类先行，权限管控随后——这和零信任体系里「先识别设备身份、再谈访问策略」是同一个逻辑。

有意思的是，这几乎是必然的演进路径。MCP 协议本身 2024 年 11 月由 Anthropic 推出，两年后的今天，协议层的能力已经跑在了治理层前面。上个月 FastMCP 沙箱逃逸漏洞、企业 MCP 服务器审计混乱这些问题被反复讨论，本质都是同一件事：Agent 基础设施进入了生产环境，但运维和安全的「接线板」还没跟上。Google 这次是第一个用硬截止日期把治理要求落地的头部平台。

对开发者的实际影响

三件事需要在 11 月 11 日前做完：

1. 盘点 OAuth 客户端。检查收件箱里有没有 Google 的 [Action Required] 邮件，它会列出受影响的 Cloud 项目。哪怕你的 Agent 目前只调标准 REST API，Google 也建议提前标记。
2. 拆分人类/Agent 流量的客户端。如果同一个 Client ID 既给人类 Web 应用用、又给 Agent 用，现在必须拆成两个。这是硬性要求，不是建议。
3. 注意个别死胡同。Apps Script 的默认 Client ID 在 GCP 控制台里不可编辑，没法打标记，目前的绕行方案是自建标准 GCP 项目、用自己的 Client ID 加 OAuth2 库。依赖 Apps Script 做自动化的团队要提前规划。

还有一个容易被忽略的细节：11 月 12 日的「永久锁死」只针对存量客户端。新建客户端随时可以打标记，所以错过窗口的代价是配置迁移的成本，不是功能永失——但对生产环境来说，重新换 Client ID 意味着要更新所有部署实例里的凭据配置，这个迁移工作量并不小。

更大的图景：Agent 身份体系正在成形

把视角拉远一点，过去几个月出现的一系列动作可以连成一条线：企业侧的 MCP 服务器审计工具、协议侧对授权规范的持续修订、平台侧（也就是这次的 Google）在身份层强制区分 Agent 流量。三个层面在做同一件事——给自主行动的软件主体建立可识别、可审计、可管控的身份。

这在软件工程史上不新鲜：服务账号、API Key、OAuth 时代都走过一遍。但 Agent 的特殊性在于它是「代表某个人行动的主体」，权限模型介于用户和服务账号之间。is_agentic 这种粗粒度标记只是第一版答案，接下来必然出现更细的模型：Agent 专属的 scope 粒度、按 Agent 审计的操作留痕、甚至 Agent 之间互认的身份协议。

对企业来说，判断标准很简单：只要你的 Agent 会替用户动数据，迟早要在身份层被单独对待。Google 只是把这一天定在了 11 月 11 日。

参考来源

• AppsScriptPulse：Mark AI Agent OAuth Clients as Agentic for Google Workspace MCP by November 11, 2026 — https://pulse.appsscript.info/p/2026/10/mark-ai-agent-oauth-clients-as-agentic-for-google-workspace-mcp-by-november-11-2026
• Google Cloud 文档：Manage OAuth Clients: Configure OAuth Clients for AI Agents — https://developers.google.com/workspace/guides/configure-oauth-clients-for-ai-agents
• VIAVI 官方公告（2026-11-02）：MCP 服务器框架集成 NITRO AI — https://www.mscbsc.com/info/Nw530id/202611-wangluoan
• Linux Foundation：MCP Dev Summit Nairobi（2026-11-19/20） — https://events.linuxfoundation.org/mcp-dev-summit-nairobi/