We will soon roll out Google Workspace Model Context Protocol (MCP) servers that expose new functionality to external AI agents across Gmail, Drive, Calendar, and other Workspace apps using the open MCP. Ahead of this launch, we are introducing an “agentic” setting (is_agentic) on Google OAuth clients, so that Google and Workspace administrators can differentiate AI agent traffic from traditional app traffic. Only OAuth clients marked as agentic will be able to call Workspace MCP servers. [emphasis mine]
In our recent review of the Q3 2026 Google Workspace Developer Release Notes, we looked at the expansion of remote Google Workspace MCP servers across Gmail, Drive, Docs, Sheets, Slides, Calendar, and Chat. At the time, I noted that while MCP is great for connecting local developer tools like Google Antigravity, giving external agents broad access across user documents raises real enterprise governance questions.
Google has now started sending developer notifications announcing a foundational change to address this, a mandatory agentic classification (is_agentic) for OAuth 2.0 clients. If you have configured OAuth clients in the Google Cloud console for AI agents or MCP servers, there is a tight one-month window to update your existing credentials.
A couple of key details and technical requirements from the announcement and the updated Manage OAuth Clients documentation are worth highlighting:
Hard Enforcement and Permanent Lock-In (November 11–12, 2026): Starting October 12, 2026, developers can edit existing OAuth clients in the Google Cloud console (Google Auth Platform > Clients) and select the Use this client for an AI-powered agent checkbox. On November 11, 2026, Workspace MCP servers will begin rejecting requests from any OAuth client not marked as agentic. Crucially, on November 12, 2026, the is_agentic setting becomes permanent on existing clients, if you miss the November 11 window, you cannot toggle the setting on an existing client and will have to create a new OAuth Client ID and update your client configurations (such as ~/.gemini/config/mcp_config.json in Google Antigravity).
Separate OAuth Clients for Human vs. Agent Traffic: According to Google’s updated best practices for agent client isolation, if your solution provides both human-interactive features (calling standard Google REST APIs) and AI agent workflows, you must maintain separate OAuth 2.0 Client IDs for each workflow. Tagging an OAuth client as agentic does not grant extra scopes or bypass user consent, but it isolates agent traffic so Workspace administrators can apply dedicated agent access controls and security policies without disrupting human users on your standard app.
Traditional Apps Script and REST Integrations Are Unaffected: If your application or Apps Script project is not an AI agent and only calls standard Google Workspace REST APIs, no action is required. However, Google recommends marking any OAuth client used by an AI agent, even if that agent currently only calls Workspace REST APIs, so it is properly classified ahead of the November 12 lock-in. Romain Vialard has however highlighted that the client ID for Apps Script is not editable in GCP so it’s not possible to mark it as agentic. The only workaround at this point is using a standard GCP, creating your own client ID and using the OAuth2 Apps Script library.
Seeing this land makes a lot of sense. Before enterprise admins can confidently allow MCP integrations or external AI agents in production domains, they need a reliable way in the Admin console and Security Investigation Tool to distinguish an autonomous agent acting on behalf of a user from a conventional web app. Separating those identities at the OAuth client level is the logical first step toward granular agent governance.
If you have existing Google Cloud projects using Workspace MCP servers, Agent Development Kit (ADK) workflows, or Gemini Enterprise connectors, head over to the Google Auth Platform Clients page before 11 November 2026 to review and update your OAuth client settings.
Email Notifications for Impacted Projects: To help, developers should check their inbox for service communications from Google with the subject ‘[Action Required] Mark AI agent OAuth clients as agentic for Google Workspace MCP by Nov 11, 2026‘, as these list the affected Google Cloud projects.
If, like me, you’ve often struggled with the pain of coding user interfaces with the CardService in Google Workspace, things are about to change. Using the new, open Agent2UI (A2UI) specification, agents can autonomously decide how to structure and render their own native interfaces in real time.
In a recent Pulse post, The Evolution of Google Chat: Exploring the New Wave of Developer Quickstarts, we highlighted a new Google tutorial that implements Agent2UI (A2UI) inside Google Chat. This guide shows you how to build a hybrid solution using Apps Script as a secure, lightweight gateway to Python-based agents running on the Vertex AI Agent Engine.
The Architecture: Apps Script as the Orchestrator
A common challenge when working with modern AI toolkits like the Agent Development Kit (ADK) is that they are not designed to run natively inside Apps Script. The quickstart bridges this divide by turning Apps Script into a lightweight, secure orchestration layer.
Instead of running heavy processing directly inside the script, Apps Script handles the Google Chat event, manages secure server-to-server authentication, and sends the payload out to an agent running on the Vertex AI Agent Engine.
Under the Hood
A look at the script provided in the quickstart shows how the Python backend passes UI layout instructions back to the Workspace front-end. When a user asks a question, the Python script processes the request, calls any backend tools and returns a single text stream structured like this:
When this response is returned to Google Apps Script, it triggers the extractA2UIParts() function which splits this raw payload on the ---a2ui_JSON--- separator. The text before the delimiter (e.g., “Hello! I found the profile…”) is taken and posted straight to the user and the raw JSON array after the delimiter is to make the card.
Something to keep in mind is that this framework is not yet a wholesale replacement for the entire CardService library, as you will see in the script it uses a basic render to convert the A2UI JSON into CardService elements:
switch (Object.keys(component)[0]) {
case 'Text':
const textParagraph = CardService.newTextParagraph();
textParagraph.setText(extractTextValue(component["Text"].text, dataModel));
widgetWithIds.push({ id: c.id, widget: textParagraph });
break;
case 'Image':
const image = CardService.newImage();
image.setImageUrl(extractTextValue(component["Image"].url, dataModel));
widgetWithIds.push({ id: c.id, widget: image});
break;
case 'Button':
// Maps inline labels or child text components to TextButtons
// and packages them into a trailing ButtonSet...
break;
default:
console.warn(`Could not render component: ${JSON.stringify(c)}`);
}
This means that for the time being, the script example is only able to handle basic UI elements rather than handling heavy, structured data-entry flows.
Future Directions
While the quickstart provides a foundational v0.8 entry point for developers, community members are already looking at how A2UI responses can be used in Google Workspace interfaces.
An excellent example of this is Curtis Krygier’s open-source a2ui-catalogue project. Curtis has started a component library designed to build agent-driven interfaces for Google Workspace starting with Google Meet and Google Chat.
Instead of trying to bundle complex, pre-composed UI elements on the backend, Curtis advocates for a substrate model:
Atomic Philosophy: Developers define a fixed visual vocabulary of atomic “primitives” once on the client side (such as TypeScript Lit web components).
Token Efficiency: The AI agent reasons entirely within this stable vocabulary. It passes raw state updates rather than inventing presentation layouts on every conversational turn. This reduces token overhead and eliminates slow backend container redeployment loops.
Interchangeability: By completely decoupling primitives from the transport layer, the exact same v0.9 component tree can reflow dynamically across completely different containers. A layout originally designed for a fullscreen stage in a Google Meet iframe can seamlessly stack and reflow to fit inside a compact Google Chat card or side panel.
Summary
For Google Workspace developers, the base A2UI Agent quickstart serves as an excellent hands-on starting point to experiment with agent integrations in Google Workspace. The underlying frameworks are evolving rapidly, as are the solution wrappers like a2ui-catalogue. Given a speed of change don’t expect a completely frictionless, single-click deployment out of the box, and you’ll likely need to lean into a little “Gemini-powered” fault finding should sort things out.
“Clicking through the Google [Workspace] Admin Console to verify hundreds of settings is manual labour. How to create an agent with Gemini 3 (Flash) that will check the settings continuously?”
In a recent post, Ivan Kutil explores how to move beyond manual checks for the Google Workspace Admin console by building a specialised “Auditing Agent” using the Agent Development Kit (ADK) and the Policy API.
“Clicking through the Google [Workspace] Admin Console to verify hundreds of settings is manual labour. How to create an agent with Gemini 3 (Flash) that will check the settings continuously?”
The Architecture: Policy API meets ADK
At the heart of Ivan’s solution is a very repeatable pattern, bridging the gap between Google Workspace APIs, in this case the Policy API, and a natural language interface. By using the ADK, developers can create tools that allow an LLM to “handshake” with Workspace data without writing a custom function for every single API endpoint:
ADK simplifies interacting with external REST APIs by automatically generating callable tools directly from an OpenAPI Specification (v3.x). This eliminates the need to manually define individual function tools for each API endpoint [ref].
In Ivan’s example, he uses AI Studio to generate the OpenAPI 3 YAML file required by the OpenAPIToolset in ADK. Google currently defines many of its APIs through the Google Discovery service in JSON syntax, and Ivan highlights the need for transformation. Gemini is very good at this, but there are a number of community tools and repositories to transform the Discovery Document into an OpenAPI file, such as the StackQL Provider Google project and its associated YAML repository (the Policy API is found in the Cloud Identity service).
Note: While the Policy API provides a powerful programmatic window into your Workspace domain, it is worth noting that it does not yet provide 100% coverage of all settings available in the Admin Console. Developers should verify the specific policy types supported when designing their auditing logic.
Agentic Auditing in Action
The resulting agent allows an administrator to simply ask questions about their Workspace environment, the agent then fetches live data, help identify risks (such as missing MFA or risky API access), and provides a structured summary with actionable steps.
This project serves as a powerful blueprint for developers looking to build “agentic” workflows enhances capabilities by grounding them with data from Workspace APIs with intelligent, conversational automation.