Apps Script data regions and a new agentic OAuth client setting look like separate platform updates. Read together, they show Google putting governance controls in place before external AI agents begin interacting with Workspace at scale.
Two Google Workspace updates arrived within two months of each other. Read separately they look like housekeeping. Read together they describe a direction.
What landed
Apps Script data regions
Apps Script now adheres to the data location policies configured in the Google Admin console. Script project files, code definitions, manifests, trigger metadata and key-value storage — including Property Service and Cache Service — can remain within the designated region. Script executions, container-bound automations and associated runtime operations can also be processed in-region.
Coverage depends on edition: Enterprise Plus and Frontline Plus get in-region storage and processing; Education Standard and Education Plus get in-region storage only. Scripts using the legacy Rhino runtime are not supported under strict data-region policies and need to move to V8.
Google Workspace developer release notes →Agentic OAuth clients for Workspace MCP
Google introduced Use this client for an AI-powered agent for user-delegated OAuth 2.0 clients that call Google Workspace MCP servers. The requirement was announced on 12 October.
Applications that only use standard Workspace REST APIs are not affected by this MCP-specific requirement. Google also recommends separate OAuth clients when one application supports both ordinary user features and agent workflows.
Google Workspace MCP announcement →Why now
The sequencing is the interesting part. The agentic-client requirement arrives before Workspace MCP traffic becomes routine in enterprise tenants.
Google is laying track ahead of traffic it knows is coming: external AI agents calling into Gmail, Drive, Calendar and other Workspace applications through an open protocol.
That makes the two changes easier to read together. One governs where execution happens. The other classifies what kind of OAuth client is allowed to call agent-facing endpoints. Both are pieces of the same administrative problem: how do you put boundaries around automated software that can act inside business systems?
What the agentic flag does — and where it stops
The new setting gives Google a registration-level distinction for user-delegated OAuth clients intended to act as AI agents. Workspace MCP endpoints can enforce that distinction: the client must be marked for AI-agent use, and mixed agent/non-agent applications are expected to use separate OAuth clients.
The limit is worth understanding before anyone builds an audit narrative on top of it.
The setting describes the OAuth client at registration. It does not continuously inspect or freeze the behaviour of the software behind that credential. An application can evolve. An agent can be repurposed. A credential can be misused.
So the setting narrows the question from what touched this? to what category of client credential was permitted to call the agent endpoint? That is a meaningful control. It is not the same as knowing what the agent decided, what triggered the action, or why a particular downstream change happened.
The Apps Script data-regions change is different in kind. It is enforced by the platform rather than asserted by a developer: the administrator sets a location policy and Google applies it to supported storage and processing. That distinction matters because the two controls will often be discussed as though they solve the same problem.
What to do this week
Separate ordinary sign-in and REST API usage from anything that will call Google Workspace MCP endpoints.
If one application handles both ordinary traffic and agent traffic, create a separate Client ID for the agent portion. This is Google’s own guidance and keeps the two access patterns distinct.
Rhino projects need to move to V8 before strict Apps Script data-region policies can apply.
Registration and endpoint controls tell you about the client and the access path. They do not, by themselves, explain the agent’s reasoning, business trigger, approval context or the intent behind a downstream action.
What this says about the future
The model Google is following (just as most of the market player today) is identity-level governance: classify the client identity, apply controls to it and use that identity as part of the access decision.
That is the model we inherited from how organisations govern employees, and it carries an assumption worth noticing. When a company grants someone access to a system, it grants two things: permission to reach the data, and discretion over what to do once inside. The second part is unstated but essential.
Identity-based access control was built around that bargain. Grant a scope, trust the holder to act sensibly within it, review periodically, revoke on exit.
Applied to agents, the bargain gets strange. Enforcement assumes an owner who can be contacted, consequences that escalate, and someone who eventually complies because the restriction has become inconvenient. None of that maps neatly onto an autonomous service. Revoking access is often the only hard lever — and revoking the access may remove the reason the agent existed.
For a great deal of enterprise automation, it does not. An AI step in a workflow does not need standing access to a database if it only needs the result of one query against one table, filtered to the rows relevant to that run. It does not need a mailbox if what it needs is the body of the message that triggered the workflow. It does not need a drive if a previous step already identified the file.
Scope defined at the step level cannot be widened by the model because the model never held that access. The query is the query. The AI reasons about what comes back — classifies, summarises, flags, recommends — and the actions that follow are executed by workflow steps whose scope was set by whoever built the workflow.
This is the architecture Zenphi has been built on. AI steps receive scoped data for a single execution rather than credentials to a system, and the workflow designer defines what each step can reach. For known processes running repeatedly across known systems — which is most of what enterprise automation actually consists of — it is usually enough.
Both models have a place. Open-ended agents handling novel requests, where the relevant data cannot be known in advance, fit the identity model, and that is where monitoring and classification tooling earns its keep. The agentic-client setting is a sensible first layer for exactly that case.
The point is that it is a choice, and at the moment it is often being made by default. The question worth asking of every automated identity already running in production is whether it holds standing access because that was deliberately designed, or because nobody asked.
