The Cookie Outlived the Login: Stolen AI Sessions and the Shadow Identity Problem

In the last week of August 2026, a number of Claude users got an email they were not expecting. Their sessions had been terminated. Their saved payment cards had been deleted. Some of them were getting refunds for charges they never made.

Anthropic named six malware families in that notification: Vidar, Lumma, StealC, RedLine and Acreed on Windows, plus Atomic Stealer on a smaller set of Macs. BleepingComputer first reported the campaign on 30 August, and Malwarebytes, Dark Reading and eSecurity Planet all covered the notification in the days that followed. Anthropic has not published a total count of affected accounts.

Here is the detail that matters, and that most of the coverage put in paragraph six: there was no breach at Anthropic. Nothing was compromised on their side. The stealers took the cookies off the victims' own laptops, from the browser profile, exactly the way those stealers have been taking Okta cookies and Microsoft 365 cookies and Slack cookies for years. Claude was not the target. Claude was just the newest thing worth money that happened to be sitting in the cookie jar.

I have spent most of this year looking at identity attacks against SaaS, and this one bothers me more than the ones with bigger numbers attached. Not because of the mechanism. The mechanism is boring. Because of what those particular accounts are now wired into.

The theft is old. The blast radius is new.

Session cookie replay is not a clever attack. The browser holds a token that proves you already logged in, so the site does not ask you again on every page load. Steal the token, paste it into your own browser, and you are the user. You never touch the login page, which means you never touch the password prompt, and you never touch the second factor. There is no failed authentication to alert on because there is no authentication at all. That is the whole trick, and we wrote about the industrial scale of it back when the infostealer epidemic pushed 642 million credentials into criminal markets.

What is different in 2026 is where a hijacked AI account can reach.

A personal Claude Pro subscription can authorize connectors into Google Workspace and Microsoft 365. VentureBeat's reporting on this campaign pulled out the consequence that nobody had written down clearly: read operations through those connectors run without a per-action approval, write actions are approval-gated by default, and the OAuth grants persist after a session sign-out. Signing the session out kills the cookie. It does not kill the grant.

Read that again, because it is the actual finding. An attacker who lands in a hijacked personal Claude account, in the window before the victim notices, is one prompt away from a read-only tunnel into a corporate mailbox. And the corporate admin cannot revoke it. The grant does not live in their tenant's app governance page. It was issued by an identity their IdP has never heard of.

"It's a consumer problem" is the expensive assumption

The instinct in most security teams is to file this under personal accounts, personal risk, personal problem. Send a phishing awareness reminder and move on.

Akamai's Enterprise AI Usage Risk Report, published in August 2026 and built on browser telemetry from LayerX, makes that position hard to hold. Across the enterprise traffic they measured, 47.11% of AI conversations ran through personal accounts rather than corporate-managed identities. Broken out by platform, Claude runs 61.09% personal, ChatGPT 61.36%, Copilot 63.92%. The purpose-built enterprise SKUs flip it completely: Gemini Enterprise at 98.15% corporate, Copilot for Microsoft 365 at 90.55% corporate.

That gap is the whole story. When a company deploys the enterprise version, the identity lands in the IdP and behaves. When employees adopt the tool themselves, which is what happened almost everywhere in 2025 and 2026, roughly six in ten sessions run on an identity you cannot deprovision at termination, cannot audit, and cannot force-rotate.

So: about half of what your staff do with AI at work happens on accounts you do not control, on a platform class that six commodity stealers are now harvesting by default. That is not a consumer problem. That is an unmanaged identity population sitting next to your data, and it grew there without a single procurement decision.

Three defences that do not fire here

MFA. Already covered, but worth being precise about why. MFA is an authentication control. Cookie replay is a post-authentication control failure. The factor was satisfied correctly, by the real user, on the real device, at the real time. The attacker simply arrives afterwards holding the receipt. Every conditional access policy you own evaluates at sign-in, and this attack has no sign-in.

Your IdP logs. There is no SAML assertion, no OIDC flow, no Entra sign-in record, because the account was never federated. Your identity team can run every query they know against their logs and find a clean, quiet, uneventful week.

EDR. This is the one people argue with me about. Yes, a good EDR stack has a reasonable chance of catching Lumma or RedLine on a managed endpoint. But look at the shape of the population again. Personal AI accounts skew towards personal or lightly-managed devices, contractor laptops, the home machine someone used on a Sunday. And even on a fully managed endpoint, the stealer's job is over in seconds. Read the cookie database, exfiltrate, exit. By the time the alert queue is triaged, the cookie is on sale.

Google has actually shipped a real fix for the underlying problem. Device Bound Session Credentials landed in Chrome 146 in April 2026 and was turned on by default for Workspace accounts in May. It cryptographically ties a session to the machine it was issued on, so a stolen cookie is worthless somewhere else. It works. It is also, right now, bound to the Google accounts it protects. It does not retroactively protect every third-party AI service your staff signed into with a personal email, which is precisely the population that got hit here.

Speed is the reason detection has to move upstream

The economics of a hijacked AI account changed the tempo. CrowdStrike's 2026 Threat Hunting Report documents an LLMjacking campaign that pushed nearly 200,000 API requests through a compromised account in two minutes. Two minutes.

Anything that detects on spend, on usage anomalies, on billing alerts, is a post-mortem tool. You will find out. You will find out after the bill lands, and the attacker will be gone with whatever the connectors let them read on the way through.

The same report has the other two numbers that frame this year for me: vishing intrusions doubled in the first half of 2026, and device code phishing attempts rose fifteenfold over six months. We covered that second one when device code phishing hit 340+ Microsoft 365 organisations. Put the three together and the pattern is consistent. Attackers have almost entirely stopped fighting authentication. They obtain something valid instead: a cookie, a token, a grant, a helpful human on a phone call. The credential theft market and the OAuth grant market are converging, and the Anodot integration token theft was the same story wearing a different hat.

If the attack is theft of something valid, then your detection has to fire on the theft, not on the misuse. That is a different design problem, and it is the one deception was built for.

What a decoy actually catches here

A honeytoken works because it inverts the assumption. Instead of trying to distinguish a good session from a bad one, you plant something that has no legitimate reason to be touched, and you wait. There is no baseline to learn, no model to tune, and no false positive, because a valid user has zero reason to use a credential that was never issued to them.

Applied to this campaign, the practical placements are unglamorous and effective:

Seed decoy cookies and decoy credentials into the browser profiles and credential stores on endpoints. A stealer does not read selectively. It hoovers the whole profile. The moment a decoy AI session token gets replayed from an IP that is not your user's, you know an infostealer ran on that machine, and you know it in the window that matters rather than at the billing cycle.

Plant decoy API keys that look exactly like the real thing. LLMjacking crews are looking for provider keys with quota attached. Give them one that reports home instead. This is the same placement logic behind the Zerofot scanner story, where automated tooling burned 2,975 harvested keys in 48 days, and the response is identical: make the harvest itself the alert.

Watch the fake download vector. The July 2026 FakeAgent campaign distributed a trojanised Claude installer laced with SectopRAT and collected roughly 7,100 downloads before it came down. Users searching for AI tools are running unsigned installers from search results at a rate that would have gotten someone fired in 2019. That is the same trust-the-interface failure we picked apart in the RecruitTrap browser-in-the-browser campaign, and decoy endpoints on those machines are one of the few things that fire on the outcome regardless of how the malware arrived.

My own opinion, and it is not the popular one: stop trying to inventory shadow AI accounts. I have watched three organisations attempt it this year through browser extensions and network telemetry, and all three ended up with a list that was stale in a fortnight, because people sign up for new tools faster than anyone can enumerate them. The account list is the wrong object to chase. The endpoint is the constant. Put the tripwire where the theft physically happens, in the browser profile on the machine, and you cover tools that do not exist yet.

The edge case worth knowing: decoy cookies need a plausible expiry and a plausible domain, or the stealer's own parsing logic drops them before exfiltration. Most commodity stealers filter expired entries to keep their logs saleable. A decoy that looks stale never leaves the machine, and never fires. Details like that are the difference between a deception layer that works and one that quietly does nothing for eight months.

Anthropic did the right things after the fact. Kill the sessions, strip the payment methods, refund the fraud. But every one of those actions was a response to a theft that had already completed and, in the case of the persistent connector grants, one that a sign-out does not fully undo. The lesson is not about one vendor. It is that a whole class of identity walked into your organisation over the last eighteen months without touching your identity stack, and the criminal ecosystem found it before your inventory did. If you want to see what a decoy session token looks like when it fires, book a walkthrough with our team and we will show you the alert on a live endpoint.