Anthropic spent last week signing users out of hijacked Claude accounts. Six infostealer families, a stripped payment card, a refund, and an email telling the victim to go clean their machine. Straightforward incident response, and by most tellings, the story ends there.
It doesn't. Buried in the mechanics of that sign-out is a quieter admission: the thing Anthropic revoked and the thing that actually reaches your data are not the same object, and only one of them has a button.
Anthropic began notifying affected users on 30 August that commodity infostealers, Vidar, LummaC2, StealC, RedLine and Acreed on Windows, Atomic Stealer on a small number of Macs, had lifted browser session cookies off infected machines and replayed them into paid Claude accounts. The company caught it in the usage meter: limits refilling and draining while the account owner was elsewhere. It signed the sessions out, pulled the saved cards, refunded what it could attribute, and told users plainly that the sign-out stops the stolen session but does nothing about the malware still sitting on the endpoint.
None of that is in dispute. BleepingComputer, Help Net Security, Dark Reading and SOCRadar all carry the same notification text and the same stealer list independently of one another. One infected user traced their own compromise to a pirated game. Anthropic has said, and there's no reason yet to doubt it, that the malware has nothing to do with Claude itself; it's general-purpose credential and cookie theft that happened to catch a Claude session along with everything else in the browser.
A session cookie is proof a login already happened. Two-factor authentication guards the login page; once you're through, the server hands your browser a token so you don't have to prove it again on every click. Steal that token and you inherit the session, no password, no MFA challenge, because from the server's side you look exactly like the person who already passed.
That's a known problem and Anthropic's response to it, sign out, strip the card, refund, is the correct one for the session itself.
What it doesn't touch is the connector layer. Anthropic's own documentation treats a Google Workspace connection as a separate, persistent grant: disconnecting it is a distinct action from signing out, done through Customize > Connectors, not through account logout. That's not a design flaw being alleged from outside; it's how Anthropic describes the feature working. A live issue on Anthropic's own Claude Code GitHub repository documents the same decoupling from the other direction: a user locked out of a lost device found that changing their Google password and revoking OAuth access at Google's end did not disconnect their existing Claude session either. The two systems don't just fail to talk to each other in the direction this campaign exploited. They don't talk to each other either way.
For an enterprise account behind SSO, that gap is visible and closeable; an identity team can pull the grant. For a card-billed personal account, the population this campaign actually hit, there is no admin console watching. The employee owns the grant. The Workspace or Entra administrator who could revoke the underlying OAuth authorisation on the Google side usually doesn't know it exists, because it was never issued through anything the enterprise controls.
The institutional claim here isn't spoken, it's structural: MFA and SSO are the control, full stop. That's the governance theatre. The operational reality is that MFA guards a login page a stolen cookie never has to visit, and the actual standing authority into a corporate inbox lives in a grant that was issued once, at the moment an employee clicked "allow" on a personal subscription, and is never looked at again by anyone with the power to pull it.
This is the same shape as the ChatGPT Messages story: a broad, unscoped OS or platform-level authorisation surviving long after the moment anyone was actually paying attention to what it covered. It's also the other half of the shadow-agent billing argument: the actual leak vector is which tier of account holds the grant, not "the cloud" as a category. Enterprise and Team connectors carry contractual controls and an owner who can switch them off. A personal Pro subscription on a managed laptop carries neither, and LayerX's figures for Akamai put 61% of enterprise Claude use running through personal identities exactly like that.
The failure isn't that this control doesn't exist. Google Workspace and Microsoft 365 both let a tenant administrator restrict which third-party OAuth clients can be authorised against company data at all. Most IT shops either leave that setting wide open or only police the app marketplace, which stops nothing here: an employee consenting to a personal Claude connector never touches the marketplace, so the grant it creates never crosses a desk anyone is watching. The gap isn't missing technology. It's a restriction that exists, is inexpensive to turn on, and sits unused.
No outlet reporting this, VentureBeat included, has shown that any of the accounts actually compromised in this campaign had a live Workspace connector attached, or that an attacker read a real inbox rather than simply burning usage. The Gmail exposure is a structurally sound extrapolation from how the architecture works, not a demonstrated exploitation chain in this specific incident. That distinction stays explicit here; readers get to know where the confirmed incident ends and the architectural argument begins.
Anthropic's own governance answer to this already exists. Enterprise-managed authorisation for MCP connectors reached general availability on 24 August, six days before the infostealer notification went out. It lets an organisation provision a connector once through its identity provider, Okta at launch, with employees inheriting scoped access on first login and losing it the moment IT deprovisions them. It runs on the same Cross App Access standard and ID-JAG token exchange Okta folded into its own Agent SSO GA that same week, trading short-lived tokens for the static, indefinitely-lived grant this entire exposure turns on.
Look at the coverage map, though. At GA, enterprise-managed auth applies to Asana, Atlassian, Canva, Datadog, Figma, Granola, Linear, Notion, Slack and Supabase. Google Workspace, the connector holding the actual inbox, isn't on it. Anthropic hasn't said why, and this piece won't guess at a reason its own documentation doesn't give; what's confirmed is plainer and just as damning: the fix shipped for ten connectors and not the one this campaign's exposure runs through.
It gets thinner still. Even inside an organisation that has deployed managed auth on every connector it covers, Anthropic's documentation notes that individuals can still add personal connectors on top of what's centrally provisioned. Managed auth locks down the connectors an organisation chooses to govern; it was never built to stop an employee adding one it hasn't.
Editor's note: Pairs with "Someone Else Only Has to Install It" on the same underlying pattern: a broad, unscoped grant surviving long after anyone was watching what it covered.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
