Google Workspace is applying a separate identification requirement to AI agents that use its MCP servers. The timetable announced by the company provides for rejecting requests from OAuth clients that are not marked for agentic use starting on November 11, 2026. The November 12 deadline identifies existing clients that remain non-agentic and whose MCP integration requires a new, appropriately identified client.
The change was announced on October 12, covering Gmail, Calendar, Drive, Docs, Sheets, Slides and Chat. This week's development is the requirement taking effect, rather than a new launch of the protocol. For applications combining direct user access with AI automation, Google documents separating the agent's identity from the identity used by the application's ordinary features.
Application identity and user permissions remain separate
The setting in Google Auth Platform is called “Use this client for an AI-powered agent”. It declares that the OAuth client is used by agents executing actions or retrieving context on someone's behalf. According to Google, selecting it does not automatically grant additional data access. User consent, requested permissions and application verification requirements continue to apply.
Google requires separate OAuth identities when an application includes both interfaces used directly by people and agentic workflows. The standard client serves interactive features, while the agentic client serves agents and automated tool execution. This separation allows administrators to apply policies to AI access without changing human access to the product's traditional features.
Identity, authorisation and data access
- Agentic client
Identifies the application calling tools - OAuth authorisation
Retains consent and permissions - Data policies
Check access to files and operations
A traditional integration that uses only REST APIs and does not operate as an AI agent is unaffected by this change, Google states. In a mixed application, the company calls for retaining the existing client for non-agent features and creating a separate identity for the agent. The requirement therefore concerns how the MCP caller is identified, rather than a general shutdown of Workspace APIs.
MCP servers provide different operations for each service
MCP, short for Model Context Protocol, connects an AI application to tools and data through a shared protocol. The Drive server is hosted by Google and supports file searches, reading content and metadata, and operations such as creating or copying files. Access inherits the user's permissions and data-governance rules. The documentation explicitly requires a Google Cloud project and membership of the preview programme.
In Gmail, the tool list includes searching conversations, reading a message thread, managing labels and creating drafts. Google's drafting example ends with a message in the drafts folder, which the person can review and send from Gmail. That operation is different from presenting the agent as an autonomous sender of every message.
The Calendar server documents listing calendars, retrieving events and checking availability. Its tool list also includes creating, updating or deleting events, responding to invitations and suggesting a time. Available operations depend on authorisation and the service's conditions; the existence of an MCP server does not turn every integration into an account with administrative access.
A file visible in Drive can still have AI access restrictions
Google Drive separately checks whether files are eligible for use through MCP. The requesting user must have at least read access, and Drive must be enabled for their organisation. Files subject to IRM restrictions that prevent downloading, copying or printing, including restrictions enforced through DLP policies, are ineligible for agent access.
Content protected by client-side encryption is also ineligible. Context-aware access policies are evaluated through the file's download capability. During search or listing operations, the server filters ineligible items out of the results. For an operation targeting one file, it returns an error. This behaviour explains the documented difference between visibility in the Drive interface and visibility to the agent.
Service accounts with domain-wide delegation follow a separate arrangement. They are not managed as the same OAuth clients in Google Auth Platform and are not rejected for lacking the agentic setting. Their access is governed by delegation administered in Workspace. Google states that sensitive calls made through user impersonation retain their requests for human confirmation.
For Apps Script, the script's default OAuth client does not support selecting the required setting. The documentation describes using a separate OAuth client declared as agentic when the script calls Workspace MCP servers. Apps Script projects that do not use those servers are explicitly excluded from the change. Conditions therefore differ according to the type of identity, rather than just the Google product being accessed.
Preview conditions and security controls continue to apply
The servers described are available through the Google Workspace Developer Preview Program. Access requires registration of the Workspace account and Cloud project, followed by confirmation from Google. Programme terms restrict the use of APIs before general availability: access by users outside the domain or company requires the specific permission provided for under the programme. An agentic designation does not replace that registration.
In its security documentation, Google requires screening prompts and responses for malicious content and prompt-injection attacks. The company permits the use of Model Armor or a documented solution developed by the integrator. Identity configuration, data authorisation and content screening represent different controls. The requirement taking effect in November adds explicit agent identification to that existing mechanism.
Google also specifies the behaviour of a particular configuration: when Model Armor is enabled together with logging, the service logs the entire transmitted payload. The service's regional availability also affects MCP request routing. These conditions are documented separately from the OAuth requirement and concern the actual configuration of data protection and processing.
