Google Workspace MCP OAuth Deadline: What to Fix Before November 11

Google Workspace MCP integrations using user-delegated OAuth need an agent-designated client before November 11, 2026. Check the client ID your deployed agent actually uses, then enable the agent setting or migrate to a separate client. Ordinary integrations that only call Workspace REST APIs are unaffected by this change.

This is an upcoming enforcement deadline announced in October, not a new product launch. It matters because an agent can have valid credentials and still fail the new client requirement. Rotating its secret or repeatedly asking users to sign in would not address the underlying configuration.

Understand the two dates

Google's Workspace release notes say requests from non-agentic OAuth clients will be rejected starting November 11. They also say clients left non-agentic by November 12 cannot subsequently be used for Workspace MCP without creating a new agentic client and updating the application.

Treat November 11 as the operational cutoff. Waiting for the later date creates an avoidable window in which the integration may already be failing. The announcement covers Workspace MCP services including Gmail, Drive, Docs, Calendar and Chat, rather than every application that uses Google sign-in.

Before changing anything, identify whether you operate the OAuth client yourself. If a connector vendor owns it, ask that vendor to confirm its migration. Creating an unrelated client in your own Cloud project will not change which credentials the vendor's deployed connector sends.

Find the client used in production

Start with the deployed integration's configuration and locate its client ID without copying the secret into a ticket, chat or screenshot. Match that ID to the correct project in Google Auth Platform, rather than selecting a similarly named development client.

Then inventory what shares it. Consider a product with a normal document browser and an AI research assistant. If both use one client today, changing the configuration without tracing those two paths can leave the team unsure which flow is affected when a user reports a failure.

Google's OAuth client guidance calls for separate clients for ordinary interactive or direct API features and agent workflows. The agent declaration does not add scopes or privileges; consent and verification requirements still apply. A client designation identifies the workflow, not permission to read more data.

For a mixed product, keep the standard client attached to the document browser and configure a separate agent client for the assistant. Record which deployed component uses each one so the distinction survives the next configuration change.

Update the agent path and test it separately

For an eligible existing agent-only client, open Google Auth Platform, select Clients, and enable “Use this client for an AI-powered agent.” If the setting cannot be changed, create an agent-designated client and update the integration to use it. Avoid deleting the old client as a first troubleshooting step.

The Gmail MCP configuration guide documents these alternatives and the separate-client requirement for mixed integrations. It also distinguishes a few cases that need different treatment:

• Service accounts using domain-wide delegation are governed by administrator delegation settings, rather than rejected for lacking this client checkbox.
• Apps Script's automatically managed client cannot be marked this way. Google documents using a separate OAuth client and the OAuth2 library instead.
• Repeated hourly sign-in prompts can indicate a refresh-token problem. That is a separate issue from the agent declaration.

Do not move an application to domain-wide delegation merely to avoid a client migration. That changes the access model and deserves its own security review.

Use a test account with non-sensitive data for validation. First verify the deployed agent is using the intended client, then run a narrow read-only request against a known test item. If the product has a standard REST path as well, test that separately. A successful sign-in screen alone does not prove either data path works.

Keep the security review in the migration

An authentication fix can make a broken tool available again while leaving its behavior poorly controlled. For a document assistant, that means checking what happens when a retrieved document includes instructions to disclose unrelated files or change the task.

Google's Workspace MCP security guidance requires screening prompts and responses for malicious content or prompt injection, using Model Armor or a documented alternative. It also warns that Model Armor payload logging can expose sensitive information, and that regional routing requires attention to data-residency requirements.

Use those constraints when deciding what to capture during rollout. Record the failing operation, client identity and diagnostic status without automatically logging mailbox contents or document bodies. Keep human review around consequential actions, even when the connection itself is working.

The useful outcome is a clearly separated agent integration that the team can diagnose and control. If the migration ends with nobody knowing which client serves which workflow, the checkbox has been fixed but the operational problem remains.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn API changes and integration decisions into clear guides that developers can actually use.

Book a 30-minute call.