Google just open-sourced a Workspace CLI with built-in MCP support, giving AI agents direct, tool-callable access to Gmail, Calendar, and Drive. People have been waiting for this. (Experimental project within the Google Workspace GitHub org, not an official product yet.)
Introducing the Google Workspace CLI: https://t.co/8yWtbxiVPp - built for humans and agents.
— Addy Osmani (@addyosmani) March 5, 2026
Google Drive, Gmail, Calendar, and every Workspace API. 40+ agent skills included.
The promise is compelling: a world-class intelligence taking care of your administrative burdens. Your agent can now read your inbox, check your calendar, and pull files from Drive through a clean, structured interface.
It’s a single Rust binary that exposes every Workspace API as a command. Ships with MCP support, 40+ agent skill files, and structured JSON output. The API surface is generated dynamically from Google’s Discovery Documents, so it stays current without manual updates.
But what did you just grant it access to?
To do any of this, the agent needs access to your Google account. That access is granted through OAuth, the same consent flow you’ve used a hundred times: an app asks for permissions, you click “Allow.” That model works well when a human initiates every action and stays in the loop. It starts to stretch when an agent is the one forming intent and deciding what to do next.
Know what you’re granting
The Workspace CLI runs as a local process. So does its MCP server. There’s no network boundary to enforce policy at. The agent simply inherits whatever credentials the host process has.
Solo.io’s Field CTO Christian Posta has written extensively about this: local tools have no natural enforcement point, and even switching to remote transport doesn’t fully solve it because OAuth itself wasn’t designed for this context.
OAuth is possession-based. If you hold a valid token, you can act. There’s no mechanism to verify why you’re acting, what task you’re acting on behalf of, or whether the action still aligns with what was originally consented to. The token is a key, not a contract.
The scope ceiling
Google’s OAuth scopes are coarse by design. gmail.readonly grants access to every email in the mailbox. Every sender, every thread, every attachment, going back to account creation.
There’s no scope for “emails from this sender, in the last five days, headers only.” The granularity doesn’t exist. When an agent requests gmail.readonly, the consent screen says “View your email messages and settings” and the user clicks Allow because the alternative is the agent doesn’t work at all.
This is consent theater. The user’s mental model is “help me find that one email from last week.” The token’s actual scope is “read everything, for as long as the session lasts.”
The gap between what was intended and what was granted is where risk lives. And that gap widens with every additional scope the agent requests.
What you granted vs. what you intended
Consider a few concrete scenarios:
| You ask the agent to… | What you intended | What you granted |
|---|---|---|
| “Check my support inbox from last 3 days” | Emails from support customers, last 3 days | ⚠️ Every email, every sender, since account creation |
| “Reply to that customer thread” | One reply, to one thread | ⚠️ Send as you, to anyone, about anything |
| “Find the Q4 report in Drive” | One specific file | ⚠️ Read every file in your Drive |
| “Block out focus time on my work calendar” | One event, one calendar | ⚠️ Create and modify events across all your calendars |
This isn’t just theoretical. The OWASP Top 10 for Agentic Applications catalogues exactly these risks. An agent can misread your intent and send the wrong email (ASI09, Human-Agent Trust Exploitation). It can stumble into sensitive threads while searching for support messages (ASI02, Tool Misuse). And if a prompt injection is buried in an incoming email, it can act on instructions that aren’t yours (ASI01, Agent Goal Hijack). The scope doesn’t distinguish between any of these scenarios.
The consent screen can’t express the left column. You can verify this yourself in the Gmail, Drive, and Calendar scope documentation. OAuth has no vocabulary for “only emails matching these criteria” or “only files in this folder.” The authorization model is binary: full scope access or nothing.
Human-in-the-loop is architecture, not a fallback
The instinctive response is human-in-the-loop (HITL): require approval before the agent sends each email. But here’s the tension: once the OAuth scope is granted, there’s nothing in the authorization layer that supports per-action approval. HITL has to be enforced by the agent framework, not by the auth model itself.
Some frameworks do this well. Claude Code asks before each MCP tool call unless you’ve explicitly auto-approved it. But that’s Anthropic’s design choice, not an OAuth requirement. A different framework, or a user who clicks “always allow,” skips that step entirely. The guardrail is voluntary.
AgentGateway gets closer
AgentGateway, by Solo.io, deserves credit for addressing what most agent frameworks ignore. It adds observability into what agents are actually doing, and maps Cedar policies onto OAuth scopes so you can control which tools an agent can invoke and under what conditions.
This is real progress. Instead of “the agent has a token, therefore it can do anything the token allows,” you get a policy layer that can restrict and audit tool access.
But it still operates at the tool level. It can say “this agent may call the Gmail API” or “this agent may not call the Calendar API.” What it can’t yet express is: “this agent may read emails from support@customer.com but not from hr@company.com” or “this agent may send replies but only using approved templates.” The policies map onto the same coarse OAuth scopes underneath.
The deeper problem: from possession to proof
The fundamental issue isn’t with any specific product or spec. It’s with the authorization paradigm itself.
OAuth was designed for a world where possession of a credential was sufficient proof of authorization. You have a token? You’re authorized. The token doesn’t carry context about why it was issued, what task it supports, or what constraints should apply to its use.
For agents, we need something closer to verifiable action credentials: tokens that encode not just “who” and “what scope” but “for what purpose,” “under what constraints,” and “with what oversight.”
The PIC protocol replaces Proof of Possession with Proof of Continuity, where delegated authority can only diminish, never expand. That’s exactly the property you want when an agent acts on your behalf. Nicola Gallo’s work on Zero Trust AuthZ for AI Agents frames the broader shift well: authorization as a continuous dialogue between agent and policy engine, not a one-time gate at the start of a session.
The agent presents its intent. The policy engine evaluates whether that intent is permitted given the current context. The authorization decision is per-action, not per-session. And critically, the decision is auditable. You can reconstruct why an action was permitted, not just that it was.
What’s keeping agents out of production
Google’s Workspace CLI is genuinely good work. The capability layer is moving fast and it deserves the excitement.
But capability is no longer the bottleneck. The business value of putting agents on real workflows is obvious. What’s missing is an authorization model that can keep up. Not another policy layer on top of the same coarse scopes. A fundamental rethink of how agents prove what they’re doing and why.
And if your team starts hooking this up without guardrails? That’s shadow AI with API access to their mailbox, their files, their calendar. More depending on their roles.
Until that happens, the friction isn’t technical. It’s trust.