Three months ago we wrote about the OAuth scope problem — connected apps and AI tools that quietly hold far more access to your Google Workspace than anyone realized, with grants nobody could detect or right-size. That was the first half of the story. The second half is worse, and it landed this week: an AI tool can hold a grant into your corporate Gmail that survives everything you'd normally do to shut it down. You sign out. You “log out all sessions.” You change your password. The grant is still live.
That's the failure mode described in a VentureBeat security report published September 2, 2026: infostealer malware replays a stolen AI-assistant session cookie, and because that assistant was already authorized to reach a work inbox, the attacker inherits a read path into corporate email that the identity provider evaluated exactly once — at the moment an employee clicked “Allow.” Signing out of the assistant invalidates the session but does not revoke the underlying Google grant. If it's a personal plan, no tenant admin can sign that account out, and the Workspace admin who could pull the grant usually doesn't know it exists.
This is not a story about one vendor. It's a structural gap in how businesses are wiring consumer AI assistants into email, calendars, CRM, and code repos. Every one of those connections is a standing key. The question no one tested is whether you can actually turn each key off. Below is what's really happening, why “sign out” is the wrong control, and the revocation-readiness audit you can run this week.
Key Takeaways
- A stolen session cookie lets an attacker skip your login entirely — MFA protects the login event, not the authenticated session that follows it.
- Signing out of an AI tool ends the session but leaves the OAuth grant into Gmail, Drive, or Microsoft 365 intact and usable.
- Authentication is evaluated once at consent; authorization then persists as a standing grant with no automatic expiry and, often, no visible owner.
- On personal AI plans, the employee owns the grant — your Claude/ChatGPT tenant admin can't touch it, and your Workspace admin frequently can't even see it.
- The fix is a revocation-readiness audit: enumerate every AI/third-party grant, prove you can kill each one admin-side, harden against cookie theft, and broker AI access through a gateway.
What Actually Happens When a Session Cookie Is Stolen?
Start with the mechanics, because the whole problem hinges on the difference between a login and a session. When you sign in to a web app and clear MFA, the server hands your browser a session cookie — a bearer token that says “this browser already proved who it is.” Every subsequent request just presents that cookie. As Adaptive Security explains, “MFA protects the login event, while the cookie represents the session created afterward.” Steal the cookie, replay it, and to the server you are the person who passed the check — no password, no second factor.
Infostealers are the delivery mechanism. Once one runs on a device, it “search[es] browser profiles for stored credentials, autofill data, history and cookies,” with CISA naming families like Raccoon Stealer and VIDAR that harvest browser cookies and credentials wholesale. The stolen cookie is then replayed into the account. This is why passkeys, as strong as they are, don't fully close the gap: they harden the login, but “after successful passkey authentication, the browser still receives a session credential,” and malware that can read that credential can still attempt replay.
What makes the AI-assistant version of this dangerous is where the replayed session leads. It's not just the assistant's own data at risk — it's every downstream service the assistant was authorized to touch. When an infostealer replays a stolen AI session cookie into a paid account, the attacker lands inside a tool that already holds a live connector into corporate Gmail. The theft of one browser cookie becomes a read path into an inbox. For regulated firms, the same defensive muscles that stop MFA and token-theft defense for regulated firms apply here — but only if you know the AI connector is part of your attack surface.
Why Signing Out Doesn't Close the Door: Authentication vs. Authorization
Here's the conceptual error baked into most incident playbooks. When an account is compromised, the reflex is “log everyone out and reset credentials.” That handles authentication. It does nothing for authorization that was already granted.
An OAuth grant is authorization. When an employee connects an AI assistant to Gmail, they consent to a set of scopes, and Google issues the app a durable grant. Access tokens themselves are short-lived — Composio notes that “OAuth access tokens from Google expire after one hour” — but the grant behind them refreshes silently. Killing a session, or even the short-lived token, doesn't touch the standing authorization that mints new tokens on demand. This is the same AI-agent identity gap we've flagged before: non-human identities accumulate authorization that outlives the human events security teams actually monitor.
The revocation gap isn't hypothetical. In a public GitHub issue against Anthropic's Claude Code, a reporter documented that OAuth tokens “remain valid and functional even after explicitly revoking all sessions and all Claude Code instances through the claude.ai web interface” — confirmed across a 3–4 day window on a machine that had been offline, ruling out client-side caching and pointing to a server-side validation gap. The reporter's framing is the whole point: revoking sessions gives users a false sense that they're protected “when they are not.” Whether or not any single product fixes its own revocation path, the architectural lesson holds — sign-out is not revocation, and a control you never tested is a control you don't have.
Who Can Actually Revoke the Grant — and Why Can't They See It?
So who can turn the key off? Technically, revocation paths exist. A user can go to myaccount.google.com, open Security, find “Your connections to third-party apps & services,” and remove the app's access. An administrator can pull grants from the Google Admin console's API and third-party-app controls. Composio is careful to note a limit even then: “Revoking access in Google stops the app from reading new data, but it doesn't delete data the app already retrieved.”
The real failure is visibility and ownership, not the absence of a button. On a personal AI plan, the employee owns the grant. Your organization's AI-tenant admin has no authority over a personal account and cannot sign it out. The Workspace administrator who could revoke the underlying grant rarely knows it exists, because a staffer connected a personal Claude or ChatGPT account to their work Google login without any enterprise consent flow. The grant sits in an admin blind spot — real, live, and unmonitored.
That blind spot is well documented. Torii's guide to OAuth risk in Google Workspace points to Proofpoint data that “half of enterprises encountered a malicious OAuth app last year,” and flags high-sensitivity scopes admins should watch — gmail.modify, drive.readonly, and admin.directory.user.readonly among them. Shadow installs slip in through paths that “never trigger a consent screen,” and delegated approvals get completed “in three clicks.” The grants are revocable in principle. They're invisible in practice — which is exactly the shape of shared AI chats leaking through Google Workspace we've warned about, now with a persistence problem attached.
The Scope Gap Was Only Half the Story: From Over-Permission to No Kill Switch
This is where today's story becomes a genuine sequel rather than a rerun. Back in May we covered the OAuth scope blind spot: AI tools requesting broad scopes and inheriting far more access than their function required. That was about how much a grant could reach. This is about whether you can stop it once it's live.
The two problems compound, and the blast radius is larger than most people assume. As Push Security's analysis of the Vercel breach explains, a scope like .../auth/drive grants “full read/write access to everything the user can see in Drive — not just their personal files,” including shared drives and collaborative resources. Their blunt summary: “A normal employee in a poorly governed org can expose as much or more data than a developer in a well-governed one.” In that breach, an employee had connected an AI SaaS app to their Workspace tenant; when the app was compromised via infostealer, attackers used the stored OAuth tokens to reach downstream accounts, and the incident carried a reported $2 million ransom demand.
The scale is the part that should stop you. Push Security reports that “on average we see 17 unique AI app integrations per organization in Microsoft and Google alone,” while most organizations have formally approved only one or two. Layer the session-cookie-theft vector on top of 17 standing grants nobody vetted, and “sign out and reset passwords” stops being a credible response. Push also found that 46% of systems with compromised corporate credentials were non-managed devices — the personal laptops where shadow AI grants are born.
| Failure mode | The scope gap (May) | The revocation gap (today) |
|---|---|---|
| Core question | How much can the grant reach? | Can you actually turn it off? |
| Primary risk | Over-permissioned access | Standing grant survives sign-out |
| Who's exposed | Broadly-scoped connected apps | Personal-plan AI connectors to work accounts |
| Why it's missed | Scopes not right-sized | Grant invisible to the admin who could revoke it |
| The fix | Least-privilege scoping | Enumerate + prove-you-can-kill-it revocation |
The Revocation-Readiness Audit: Prove You Can Kill Every Grant
Here's the do-this-Monday work. The goal is not to ban AI — it's to make every AI connection something you can see, govern, and switch off on demand. In our experience, four moves close most of the gap.
1. Enumerate every AI and third-party OAuth grant. Torii's remediation path is a good template: map grants via the Admin console under Reporting → Security → OAuth activity, inventory them with the API (oauthToken.list), cross-reference tokens to users through the Directory API, and score each by scope sensitivity, publisher reputation, and user privilege. On Microsoft 365, do the equivalent through enterprise application consents. You're building a list of standing keys.
2. Prove you can revoke each one — admin-side, not “sign out.” For every grant on the list, actually test the kill: revoke it from the admin console and confirm access stops. Torii recommends implementing conditional access and 90-day re-consent timers so grants can't live forever unchallenged. A grant you can't revoke from a central console is a finding, not a footnote.
3. Harden against the session-cookie theft that starts the chain. Adaptive Security's controls are the right baseline: short session lifetimes for high-impact apps, non-persistent cookies where workflows allow, and — the durable fix — device-bound sessions and proof-of-possession tokens that “require the requesting device to demonstrate control of a cryptographic key” rather than presenting only a copied cookie. Add continuous access evaluation so sessions die when a device becomes non-compliant. This is credential isolation for AI agents applied to human sessions.
4. Broker AI access through a gateway instead of user-held grants. The structural fix for “personal grant nobody can see” is to stop issuing personal grants at all. Route AI access to email, CRM, and repos through a secure AI gateway so connections are broker-mediated and centrally revocable — one place to enumerate, one place to kill. Both Google and Microsoft let admins move to a default-deny posture on third-party consent; pair that with a gateway and the standing-key problem largely disappears.
Why Northeast Indiana's Regulated Firms Are Most Exposed
If you run a community bank, a credit union, a law firm, or a healthcare practice in Fort Wayne, Auburn, or anywhere across Allen and DeKalb County, this is your problem in a specific way. Your staff are exactly the people quietly connecting a personal Claude or ChatGPT account to a work Google inbox to get through the day faster — and your obligations under HIPAA and GLBA don't care that the grant was created without IT's knowledge. A standing, unmonitored read path into patient or customer email is a reportable exposure waiting to happen, and most small firms here don't have a security team watching OAuth activity in the Admin console.
The good news is that the first pass doesn't require a security team. Run this five-line check: (1) In your Google Admin console, open Reporting → Security → OAuth activity and list every third-party app with access. (2) Flag anything requesting Gmail or Drive scopes that you didn't formally approve. (3) For each one, confirm whether it was granted by a personal account you can't administer. (4) Revoke one test grant and verify access actually stops. (5) Turn on admin consent controls so the next one can't be added silently. That's an afternoon for an office manager, and it's the difference between “we think we're fine” and “we proved we can turn it off.”
Close the Revocation Gap Before It Closes on You
Cloud Radix builds AI Employees for Northeast Indiana businesses — and we build them so that every connection into your email, calendar, CRM, and repos is broker-mediated, least-privilege, and revocable from one console. If your team is already using consumer AI tools (they are), the safest path forward isn't a ban; it's a governed one. We'll run a revocation-readiness audit of your Google Workspace or Microsoft 365 tenant, surface every standing AI grant, and route future AI access through a secure AI gateway with a real kill switch. Book a Fort Wayne AI security consult before an infostealer finds the grant first.
Frequently Asked Questions
Q1.Does signing out of an AI tool revoke its access to my Gmail?
No. Signing out ends your session, but the OAuth grant you approved when you connected the tool remains active and continues to mint new access tokens. To actually cut access, you must revoke the grant itself — either as a user at myaccount.google.com under “Your connections to third-party apps & services,” or as an administrator through the Google Admin console. Note that revocation stops future access but doesn't delete data already retrieved.
Q2.How does a stolen session cookie bypass multi-factor authentication?
MFA protects the login event. Once you've authenticated, the server issues a session cookie that proves authentication already happened, and every later request just presents that cookie. If infostealer malware copies the cookie and an attacker replays it, the server treats them as the already-verified user — no password or second factor required. That's why device-bound sessions and short session lifetimes matter more than login-only controls here.
Q3.Why can't our IT admin just revoke the grant?
Usually they can — but only if they can see it. When an employee connects a personal AI account to their work Google login, the grant lives on an account your AI-tool admin has no authority over, and your Workspace admin often doesn't know it exists because it never passed through an enterprise consent flow. The revocation button exists; the visibility and ownership don't. That blind spot is the real vulnerability.
Q4.How many unauthorized AI grants might we have?
More than you think. Push Security reports an average of 17 unique AI app integrations per organization across Microsoft and Google, while most companies have formally approved only one or two. The gap between those numbers is shadow AI — grants created by staff without review. The only way to know your real number is to enumerate OAuth activity in your admin console.
Q5.What is a revocation-readiness audit?
It's a practical test of whether you can actually turn off every AI and third-party grant into your environment. You enumerate all OAuth grants, identify their owners and scopes, and then prove you can revoke each one from a central admin console — not just sign the user out. It pairs with hardening against session-cookie theft and, ideally, routing AI access through a broker so grants are centrally revocable by design.
Q6.How does a secure AI gateway prevent this problem?
A secure AI gateway sits between your AI tools and your business systems, so AI access to email, CRM, and repos is brokered through one governed layer instead of dozens of user-held personal grants. That gives you a single place to enumerate every connection, enforce least-privilege scopes, and revoke access instantly. Instead of standing keys scattered across personal accounts, you get one kill switch you control.
Q7.Do Fort Wayne firms under HIPAA or GLBA need to worry about AI OAuth grants?
Yes. When a staffer at a Northeast Indiana bank, credit union, law firm, or healthcare practice connects a personal Claude or ChatGPT account to a work Google inbox, that standing grant becomes an unmonitored read path into regulated data — and your HIPAA or GLBA obligations still apply even though IT never approved it. A revocation-readiness audit of your Google Workspace or Microsoft 365 tenant is the fastest way to find and close those grants before they turn into a reportable exposure.
Sources & Further Reading
- VentureBeat: venturebeat.com/security/stolen-claude-session-cookies — Stolen Claude session cookies can reach corporate Gmail through grants no IT admin can revoke.
- Composio: composio.dev/content/is-it-safe-to-connect-claude-to-gmail — Is it safe to connect Claude to Gmail? Token lifetimes and revocation limits.
- Adaptive Security: adaptivesecurity.com/blog/session-cookie-theft — Session Cookie Theft: Detect Token Replay, MFA Bypass, and Email Account Takeover.
- Torii: toriihq.com/articles/oauth-google-workspace-risk — How to Detect OAuth Risks in Google Workspace and Who's Behind Them in 2026.
- Push Security: pushsecurity.com/blog/unpacking-the-vercel-breach — Unpacking the Vercel breach: Shadow AI and OAuth sprawl.
- GitHub / anthropics-claude-code: github.com/anthropics/claude-code/issues/43801 — “Log out all sessions” + Claude Code instance revocation does not invalidate OAuth tokens (Issue #43801).
Prove You Can Turn Off Every AI Grant
We'll run a revocation-readiness audit of your Google Workspace or Microsoft 365 tenant, surface every standing AI grant, and route future AI access through a secure gateway with a real kill switch — before an infostealer finds the grant first.
