Leadous editorial illustration representing Google Workspace MCP and an agentic OAuth client requirement.
Back to Articles & Insights

Leadous Articles & Insights

Google Workspace MCP Adds an Agentic OAuth Requirement

By LeadousOctober 12, 2026Technology

Google Workspace developers have a date to put on the calendar: November 11, 2026. In a developer notice dated October 12, Google says AI-agent OAuth clients must be marked as agentic to call Google Workspace Model Context Protocol (MCP) servers.

The change is narrow, but the distinction matters: an AI agent that connects to Workspace through MCP is not the same thing as a traditional app that calls a Workspace REST API.

What Google says is changing

Google is introducing an is_agentic setting on Google OAuth clients. The stated purpose is to help Google and Workspace administrators distinguish traffic from AI agents from traffic generated by traditional applications.

For the new Workspace MCP servers, the notice is explicit: only OAuth clients marked as agentic will be able to call them. The email subject gives November 11, 2026 as the deadline for marking AI-agent OAuth clients so they can retain access.

Google’s notice also draws a clear boundary: if an application is not an AI agent and only uses Google Workspace REST APIs, such as the Gmail API or Drive API, this change does not require action.

Which integrations should teams review?

Start with applications that use OAuth to connect an AI agent to Google Workspace through MCP. That can include an internally built agent or a third-party AI application, provided it uses a Google OAuth client to call Workspace MCP servers.

Then separate those connections from ordinary integrations that call Workspace REST APIs. A Gmail or Drive integration is not automatically an AI agent just because the product also has AI features; the relevant question in Google’s notice is whether the OAuth client will call Workspace MCP servers as an agent.

If the answer is unclear, identify the OAuth client, its technical owner, and the API or protocol it uses before making a change. This inventory is a practical review step, not an additional requirement stated by Google.

What to do before November 11

  1. Inventory Workspace OAuth clients. Include internal tools, vendor integrations, and AI applications that handle Workspace data.
  2. Identify the connection path. Confirm which clients use Workspace MCP and which use only standard Workspace REST APIs.
  3. Assign an owner to each agent client. The application team or vendor should confirm the Google OAuth client that needs the agentic classification.
  4. Follow Google’s implementation instructions. The email excerpt reviewed here does not specify the console location, exact steps, or whether an existing client must be changed or replaced. Do not guess those details; use the complete Google notice and current Google documentation.
  5. Test the integration before the deadline. Once the relevant setting is available and configured, verify the agent’s authorized Workspace MCP access using the application’s approved test process.

These are recommended coordination steps for a platform team. They are not presented as Google’s unpublished console procedure.

The setting is not a substitute for access governance

The notice describes is_agentic as a way to identify AI-agent traffic and as a requirement for calling Workspace MCP servers. It does not say that marking a client agentic grants access to a user’s data by itself. Teams should continue to review OAuth consent, requested scopes, user permissions, and their own approval controls.

Google’s public Workspace MCP setup guide describes the current OAuth-based configuration for its product-specific MCP servers. Its developer announcement about Workspace agent tools provides broader context. Those references explain the MCP environment; the new is_agentic deadline and classification requirement above come from the October 12 developer email.

For a plain-language introduction to MCP and its role in marketing operations, see our MCP explainer. The short version: before an agent can do useful work, teams need to know which systems it can reach—and who is responsible for that connection.