Google Workspace MCP: Mark OAuth Clients Agentic by Nov 11

Google Workspace MCP servers will begin rejecting OAuth 2.0 clients not flagged with the `is_agentic` classification on November 11, cutting off AI agents that access Gmail, Drive, Docs, or Calendar over MCP. Google introduced the flag in October 2026 as a single checkbox in Google Cloud Console under Google Auth Platform > Clients; it grants no additional scopes and exists so Workspace administrators can separate agent traffic from standard app traffic in audit logs and policy controls. After November 12 the flag locks permanently on an existing client, so applications serving both humans and agents from one Client ID must split into two separate IDs or create a new Client ID and redeploy.

On November 11 — six days from now — Google Workspace MCP servers start rejecting OAuth clients not flagged as “agentic.” If your AI agents interact with Gmail, Drive, Docs, or Calendar via MCP, they go dark on that date. Miss November 11, and the problem gets worse: on November 12, the flag locks permanently on your existing OAuth client. After that, your only path forward is creating a brand-new Client ID and redeploying everything that depends on it. This is not a deprecation warning with a long tail. It is a hard cutoff. What Google Changed and Why In October 2026, Google introduced the is agentic classification on OAuth 2.0 clients. It is a single checkbox — “Use this client for an AI-powered agent” — in Google Cloud Console under Google Auth Platform Clients. The flag does not grant additional scopes or permissions. It is a labeling mechanism that lets Google Workspace administrators differentiate AI agent traffic from standard app traffic in audit logs and policy controls. The motivation is straightforward. Workspace MCP servers are more capable than REST APIs. An agent operating over MCP can compose and send emails, create and edit documents, schedule calendar events, and query across all of a user's Workspace data — not just read it. Enterprise admins managing thousands of users need visibility into which applications have this level of access and whether those applications are automated agents or human-interactive apps. The is agentic flag is how Google gives them that visibility. Who Is Affected If you use any of the following, check your OAuth clients now: - Google Agent Development Kit ADK workflows connected to Workspace MCP - Gemini Enterprise connectors to Workspace apps - n8n automations using Workspace MCP server integrations - LangChain or LangGraph agents calling Workspace MCP endpoints - Open-source MCP servers like taylorwilsdon/google workspace mcp https://github.com/taylorwilsdon/google workspace mcp - Any custom agent using Claude Code, Codex, or similar tools with Workspace MCP If your application calls the Workspace REST APIs directly — not MCP — you are not affected. Service Account authentication is also unaffected. The enforcement targets OAuth 2.0 clients specifically used to authorize MCP server access. The Fix Takes Two Minutes The good news is that the fix is fast. Navigate to Google Auth Platform Clients https://support.google.com/cloud/answer/15549257 in your Google Cloud Console. Find the OAuth 2.0 Client ID your Workspace MCP integration uses. Click edit, check “Use this client for an AI-powered agent,” and save. No code changes. No re-deployment. Done — provided you act before November 11. The less good news: if you use the same OAuth client for both a human-facing login flow and an agent workflow, Google's documented best practice is to split them into two separate Client IDs https://dev.to/aiautomationplaybook/googles-nov-11-oauth-deadline-for-ai-agents-what-the-official-docs-actually-say-1p0 . The is agentic flag is permanent after November 12 — you cannot unset it on a flagged client, and a flagged client should be used exclusively for agent traffic. If your app today serves both humans and agents from one client, now is the time to separate them. What This Actually Means for the Industry The deadline is tactical. The bigger story is strategic. This is the first formal OAuth-level separation of human and agent identity in a major enterprise productivity platform. Until now, an AI agent and a human user looked identical at the OAuth layer — both were just “an application” that a user had consented to. The is agentic classification changes that. Agents become a distinct identity category with their own audit footprint, their own admin controls, and eventually their own permission model. JumpCloud called this direction “Agentic IAM” in 2026. Microsoft is building the same infrastructure into Entra ID. Atlassian, Salesforce, and every other enterprise platform with an MCP integration will follow. The November 11 deadline https://pulse.appsscript.info/p/2026/10/mark-ai-agent-oauth-clients-as-agentic-for-google-workspace-mcp-by-november-11-2026/ is not bureaucratic overhead — it is Google establishing the identity foundation that enterprise AI governance will be built on top of. If you are building AI agents that touch business data, start treating agent identity as a first-class design concern. The teams already updating their OAuth clients https://dev.to/cortexflow tech/google-workspace-will-block-ai-agents-without-this-oauth-flag-on-nov-11-the-n8n-builders-checklist-2c32 are ahead of this curve. The teams ignoring it will find out on November 11.