Google is about to draw a hard line between humans and agents inside Workspace. If your n8n AI agent touches Gmail, Drive, or Calendar through a Google OAuth client, you have until November 11, 2026 to flip one checkbox in the Google Cloud console. Miss it, and on November 12 the setting locks permanently on your existing client — leaving you to rebuild the whole OAuth credential from scratch.
This is not a rumor. Google is introducing a new “agentic” classification flag for OAuth clients — a checkbox labeled “Use this client for an AI-powered agent” inside Google Auth Platform > Clients. Starting November 11, 2026, Google’s Workspace MCP servers will actively reject any OAuth client that isn’t marked as agentic, returning an error that says the client is not marked as an AI agent. The timing matters: Google is rolling out Workspace MCP servers that expose Gmail, Drive, Calendar, and other productivity tools as live Model Context Protocol servers, and only agentic-tagged credentials will be allowed to connect to them.
By the end of this post, you will know exactly which of your OAuth clients need the flag, the two dates that matter, and a four-step checklist to get compliant before the lock-in.
Why Google is doing this
An OAuth client is the credential bundle (client ID + secret) that identifies your app to Google’s sign-in system. Until now, a credential used by a cron-jobbed n8n workflow looked identical to one used by a human clicking through a web app. That made it impossible for Workspace admins to write security policies that apply only to agent traffic — rate limits, data-loss controls, access reviews — without also hitting human users.
The agentic flag splits the traffic at the identity layer. Marking a client as agentic doesn’t grant extra scopes or bypass user consent; it labels the traffic so admins can apply dedicated agent controls to it. The rollout comes with a new best practice from Google: if your solution has both human-interactive features (standard Google REST APIs) and AI agent workflows, maintain separate OAuth Client IDs for each.
The dates that matter
| Date | What happens |
|---|---|
| Oct 12, 2026 | The “Use this client for an AI-powered agent” checkbox became available in the Google Cloud console (Google Auth Platform > Clients) for new and existing clients. |
| Nov 11, 2026 | Workspace MCP servers start rejecting requests from OAuth clients that lack the agentic tag. |
| Nov 12, 2026 | The is_agentic setting becomes permanent on existing clients. If you didn’t flip it in time, you cannot toggle it on that client — you must create a brand-new OAuth Client ID and update every configuration that references the old one. |
That last date is the trap. This isn’t a setting you can enable lazily the first time something breaks on November 12. After the cutoff, a missed flag means a new client ID, new consent screens, and re-wiring every n8n credential and MCP config that used the old one.
The 4-step n8n builder’s checklist
Step 1 — Inventory your Google OAuth clients. Open Google Cloud console and list every OAuth Client ID under Auth Platform > Clients. Flag each one: is this credential used by an AI agent (an n8n AI Agent node, a workflow that acts on your behalf, an MCP client config) or by human-driven workflows? Builders commonly run both through a single client — that is exactly the pattern Google now wants split.
Step 2 — Enable the agentic flag on agent clients. For each client that powers agent traffic, open it and tick “Use this client for an AI-powered agent”. This is available today; do it now rather than in the November scramble. You should see the checkbox persist on the client detail page after saving.
Step 3 — Split human and agent traffic into separate clients. Google’s updated guidance is explicit: one OAuth Client ID for human-interactive features, one for agent workflows. In n8n this means creating a second Google OAuth2 credential and assigning it only to the nodes/agents that act autonomously. If you’re unsure which workflows qualify, treat anything that reads or writes Workspace data without a human clicking “run” each time as agent traffic.
Step 4 — Watch your MCP configs. If you connect n8n to Workspace MCP servers (see our guide to connecting an MCP server to n8n), the OAuth credentials behind those connections are the ones the November 11 enforcement targets. Re-auth flows and client JSON files (like mcp_config.json entries in coding-agent setups) must reference an agentic-tagged client.
What this does and doesn’t affect
To be precise about scope: the enforcement applies to Google Workspace MCP servers — the new protocol surface, not the decades-old REST APIs behind n8n’s standard Google nodes. If your workflows only use n8n’s built-in Google Drive/Gmail nodes with plain REST calls, this deadline doesn’t touch them. But the industry is moving: Google, Microsoft, and everyone else are converging on MCP as the agent protocol, and this is Google declaring that MCP access will be gated at the identity layer. If you plan to give agents live Workspace access via MCP — which is where agent builders are headed — this flag is your ticket.
Two honest caveats. First, the granular rollout details come from secondary coverage (ASTIG’s Oct 2026 report and Apps Script Pulse’s Oct 14 analysis, which references Google’s updated Manage OAuth Clients documentation). I have not read Google’s own announcement page directly, so verify the checkbox wording in your own console before you act. Second, if you authenticate Google entirely through n8n’s hosted OAuth service rather than your own Cloud project client, this may not apply to you at all — the flag lives on your OAuth client IDs.
Key Takeaways
- Google Workspace MCP servers reject non-agentic OAuth clients starting November 11, 2026.
- The
is_agenticflag locks permanently on November 12 — miss it and you’re creating a new client ID from scratch. - Keep separate OAuth Client IDs for human vs. agent traffic; the flag grants no extra permissions, it just labels traffic for admin controls.
- Audit your n8n Google OAuth2 credentials and MCP configs now, not in November.
Next step: Open your Google Cloud console’s Auth Platform > Clients page today, find the client behind your most important n8n agent workflow, and tick “Use this client for an AI-powered agent”. While you’re there, read our MCP + n8n troubleshooting guide for the OAuth re-auth patterns that pair with this change.
Images: Pexels