I watched the Google IO 2026 keynote where Sundar Pichai casually said “you can now talk to your Gmail inbox” and the auditorium did its standard whoa-noise, and the thing I kept thinking about wasn’t the natural language part. It was the architecture diagram nobody showed.

Because talking to your Gmail still means talking to Google’s servers. Which means OAuth scopes, token grants, refresh flows, the entire third-party-app dance just wearing better TTS.

What the demo actually does

A user says “find the contract from Sarah and summarize the deadlines.” Gemini hits the Gmail API on Google’s backend, pulls the message, runs inference somewhere in a GCP region, speaks back. Slick on stage.

But under the hood it’s still treating Gmail as an external resource to authenticate against. Even though Gmail is also a Google product. Even though the user is presumably logged into Gmail in another tab on the same device. The plumbing assumes the agent and the data live in different houses, and a token has to walk between them.

The OAuth tax nobody puts in the keynote

Every Gmail integration starts the same way. Pop-up. Scopes screen. A long paragraph about what “this app will be able to do.” Approve. Redirect to a callback URL. Maybe paste a code somewhere. Maybe not.

Either way, you have just minted a long-lived credential that lives in some service’s database, where it will sit until the company gets breached or sold or quietly trains on your inbox to improve their model. This is the part of the workflow that absolutely nobody enjoys, and it is also the part that has historically been the source of the worst incidents, because granting third-party Gmail access is a default-trust model with effectively no revocation hygiene baked in, and once you’ve approved scopes that span read and send and delete, there is no granular way to walk that back without nuking the integration entirely and re-approving everything from scratch.

The OAuth abuse waves of the last few years did not happen because attackers got cleverer. They happened because the token surface kept growing.

Your tab is already authenticated

Something Sundar didn’t mention. You are already logged into Gmail. Right now. In some tab somewhere, with a session cookie issued by Google, scoped to your browser, that lets you click “Reply” without doing a single extra thing.

A browser agent like Dassi runs inside that authenticated tab, sharing the same session and cookies and rendered DOM that you yourself are using right now to read mail, which means there is no separate context to grant, no separate identity to manage, no second copy of your session sitting in someone else’s database waiting to be exfiltrated.

No OAuth flow. No token in a third-party vault. No “this app will be able to read, send, delete, and manage your mail” terror dialog. If you can see it, the agent can see it. If you can’t, neither can it. That symmetry is the entire product.

I went deeper on this in the post on Gmail AI hacks that skip OAuth, but the short version is: the browser session is already a perfectly valid auth mechanism, and the industry has spent a decade pretending it isn’t.

Drafting a reply, the actual flow

You open the email. You ask the agent to draft a response. It reads the thread, writes the reply, types it into the compose box already open in your tab. You edit. You send.

There is no API call to a third-party draft endpoint. There is no Google-side audit trail of “user X asked agent Y to read message Z.” The model gets the email body because you brought your own key, and that call goes from your machine straight to Anthropic or OpenAI or wherever your provider lives, but Gmail itself is never the API consumer in this picture. Gmail is just the page you happened to be on.

Same model. Different blast radius.

Google’s demo wins on UX. Talking is nicer than typing. But the LLM doing the actual reasoning is no smarter than what you can already run yourself through a browser agent backed by your ChatGPT or Claude subscription.

When the model lives behind Google’s OAuth wall, every interaction is a server-side event with all the logging and policy attached. When the model lives in your sidebar and reads your already-open tab, it is just you and the LLM. The difference does not show up in keynote demos. It shows up in incident reports.

FAQ

Does a browser agent need OAuth for Gmail? No. It uses your existing browser session, the same one you use to read mail manually every day.

Can the agent see my whole inbox? It sees what’s loaded in the tab. Open the inbox, it sees the inbox. Close the tab, it sees nothing.

What about Gmail’s automation policies? A browser agent acts as you, in your session, using your hands. From Gmail’s perspective it is the same as you using the interface yourself, because that is what it is.