Google Workspace MCP OAuth Deadline: Which AI Agent Apps Are Affected?
Google Workspace remote MCP servers began enforcing a new OAuth requirement on November 11, 2026. An application that uses these servers through a user-delegated OAuth 2.0 client must designate that client for use by an AI-powered agent. Google’s earlier developer release notes say that clients not marked by November 12 will remain non-agentic and must be replaced to continue using Workspace MCP.
This is an authentication change for a defined protocol and client type, not a shutdown of ordinary Gmail, Google Drive or Google Calendar REST API integrations. A tool’s name, or the mere fact that an app uses an AI model, does not establish that the requirement applies.
The timeline comes from Google Workspace’s October 12 release notes; the official remote MCP configuration guide describes the client setting and exceptions.
1. The rule and the dates
Google Auth Platform > Clients includes a checkbox labeled Use this client for an AI-powered agent. Google requires it for relevant user-delegated OAuth clients calling Workspace remote MCP servers.
- October 12, 2026: Google announced the requirement in release notes for services including Gmail, Drive, Docs, Sheets, Slides, Calendar and Chat MCP.
- November 11, 2026: The release notes state that Workspace MCP servers would begin rejecting requests if the calling OAuth client is not marked agentic.
- November 12, 2026: Google says unmarked existing clients remain non-agentic; a developer seeking to use MCP after that date must create an agent-marked OAuth client and update the affected app.
The notice does not give a specific global cutoff hour or time zone. Do not invent a 9:00 a.m. or midnight local deadline from the date alone.
Services have different rollout and Developer Preview eligibility conditions. This article concerns Google’s own remote Workspace MCP servers, not every third-party MCP implementation that happens to access Google data through different APIs.
2. Which integrations need attention?
A. A coding or business agent calls Gmail, Drive, Docs, Sheets, Slides, Calendar or Chat using Google’s remote MCP endpoint and a user-delegated OAuth client.
This is the main affected case. Identify the exact client ID used to obtain the user-delegated token. If the client is unmarked and can no longer be changed, follow Google’s instructions to create a new agent-marked client and update the MCP configuration.
B. An application calls ordinary Workspace REST APIs, without Google’s remote MCP server.
Google says non-agentic REST-only apps are not affected by this change. An existing REST integration does not become noncompliant simply because a different product uses MCP or because the app supports an AI feature elsewhere.
C. A single OAuth client powers both agent/MCP and ordinary app workflows.
Google recommends separate OAuth client IDs: preserve the existing standard client for normal application features, and make a dedicated agentic client for the MCP workflow. This separates monitoring and policy from traditional user interactions.
D. A service account uses domain-wide delegation.
A delegated service account is not managed through Google Auth Platform’s normal user OAuth clients, so it cannot select that checkbox. Google’s remote MCP guide explicitly says those requests are not rejected solely for lacking the agent setting. Access still depends on the Workspace administrator’s domain-wide-delegation configuration, and sensitive actions can require human confirmation.
E. Google Apps Script calls Google’s remote Workspace MCP endpoint.
The Apps Script-managed default OAuth client cannot be marked as agentic. Google describes using a separate agentic OAuth client, the OAuth2 for Apps Script library, and the resulting access token instead of the token from ScriptApp.getOAuthToken. Apps Script code that does not call Workspace MCP is unaffected by the new checkbox requirement.
These differences matter more than a blanket headline about “all Google AI integrations breaking.”
3. Check an affected OAuth client safely
Only authorized project administrators should change OAuth client configuration. A useful inspection and recovery order is:
- Confirm the protocol. Is your app calling Google’s remote MCP endpoint, or a standard REST API? Do not infer the route from a product name.
- Identify the actual OAuth client ID used for the remote MCP call. Several apps may access the same user’s account through different clients.
- In the owning Cloud project, open Google Auth Platform > Clients and inspect Use this client for an AI-powered agent.
- For an existing client that still supports updating the setting and serves only agent workflows, follow the current Google console guidance. For a client that cannot be updated under the deadline policy, create a new agent-marked client.
- If the current client also powers non-agent features, preserve it and migrate just the MCP workflow to a separate agentic client.
- Update the target MCP client’s authorized redirect URI, configuration and OAuth consent flow as appropriate. Never publish the OAuth client secret, refresh token or user access token.
- Perform one harmless, approved tool query and inspect the actual authentication result. A successful interactive sign-in is not proof that a remote MCP server accepted the later tool call.
Google Cloud’s OAuth client management guide emphasizes that the agent designation does not grant additional OAuth scopes, consent or privileges. Those controls still apply. Tagging a client is not permission to use someone else’s account or to bypass Workspace administrator policy.
4. Why might a connector still fail after migration?
Different failures need different remedies.
Wrong client ID or missing agent designation
If the remote MCP request is rejected, first check the actual user-delegated OAuth client, not only the project name. An app may still use cached or older client configuration. The official troubleshooting steps distinguish an existing client that can be updated from one that must be replaced.
A developer who administers several clients should not rotate all of them reflexively. Changing a shared client can disrupt unrelated users and services.
Hourly reauthentication without a refresh token
Google separately documents that a refresh token requires the OAuth authorization parameter access_type=offline; the OpenID Connect scope offline_access alone does not accomplish the same thing for Google’s OAuth flow. When appropriate, an authorized client can use prompt=consent to obtain a new refresh token for an already-authorized user.
This addresses repeated sign-in prompts, not the agentic checkbox. Do not mistake one for the other.
Service account or Apps Script exception
As above, domain-wide-delegated service accounts have their own administration rules, while Apps Script’s managed OAuth client cannot be marked and needs a separate OAuth client for remote MCP access. Neither exception means every request is permitted.
Local MCP server errors
A local Python MCP server using STDIO can fail because of a broken interpreter path, protocol framing or package version. That is a different path from Google’s remote Workspace MCP user OAuth restriction. Our Python MCP SDK server guide explains the local process boundary, not this new Google policy.
Developer Preview and tool authorization
Many Google Workspace MCP endpoints remain subject to product-specific availability, developer preview requirements, user consent, administrative policy and confirmation of sensitive tool actions. A valid agent-marked OAuth client is necessary in the affected flow, but not sufficient for every endpoint or operation.
5. The engineering lesson: identity and permissions are separate layers
The OAuth client ID identifies the application requesting access. User consent, OAuth scopes, project verification and Workspace administration decide the actions the application can perform. Marking a client as agentic adds a separate policy signal for AI-mediated workflows.
For teams maintaining several tools, an inventory should record the app owner, protocol, Cloud project, OAuth client class, endpoint, responsible administrator and agent-designation status. It should not contain raw client secrets or refresh tokens.
A successful MCP tool call also does not mean the overall agent task completed safely. Our MCP test evidence audit explains the limits of treating tool responses or passing tests as proof of the final repository state.
Separate an authentication fix from a safety guarantee. An agent can have valid OAuth credentials while still lacking proper restrictions on what it may do with tools.
6. What we can and cannot conclude
The dates, client flag and exclusions are documented by Google. This publication did not access readers’ Google Cloud projects, create OAuth credentials, reproduce a particular provider rejection or test a named third-party connector. It would be misleading to claim that every ChatGPT connector, every Google Workspace automation or every Apps Script integration failed on November 11.
The change is specific enough for developers to act on immediately: determine whether your integration uses the Google-hosted Workspace remote MCP server with user-delegated OAuth, check the correct client, and migrate only if the documented rule applies.
Primary sources
- Google Workspace developer release notes: October 12, 2026 notice
- Configure Google Workspace remote MCP servers and troubleshooting
- Google Cloud: Manage OAuth Clients and AI-powered agents
- Gmail MCP server configuration and relevant exceptions
- Drive MCP server configuration and domain-wide delegation
Editorial note: Published November 12, 2026, analyzing an October 12 announcement and its November 11–12 enforcement schedule. This is independent, source-backed guidance, not an executed migration of anyone’s OAuth client or an independently measured failure rate. Agentic Pulse received no compensation or editorial direction from Google.