Infostealer logs are full of AI session tokens that replay past MFA.

On 9 September 2026, Jeremy Kirk of Okta Threat Intelligence published an analysis of a free infostealer credential dump. Alongside the usual passwords and cookies, the logs contained AI session tokens and API keys that still worked. A session token does not need a password to be useful. It is pasted into a browser, the account opens, and no MFA prompt is ever shown.

That is the part worth sitting with. Most enterprise AI access is now protected by the same control, MFA, that a replayed token walks straight past.

What Okta found

The dataset was not a breach of any AI provider. It was an ordinary criminal log dump, published free on Telegram on 2 August 2026: 5,871 folders of roughly 7 GB, one folder per infected machine, spread across 162 countries. Okta used regular expressions and the open-source scanner TruffleHog to pull authentication material out of it.

The haul included 44,791 unique JSON Web Tokens. As The Hacker News and Gizmodo both report from the research, 555 of those tokens authenticated to AI services, and a further 2,937 encrypted JWE structures were found alongside them. Twenty-four API keys for Google Gemini, OpenAI, Groq and OpenRouter were still valid.

Gizmodo names Lumma Stealer and Vidar among the malware families behind the logs, and describes a Telegram shop called Poison Claude that resells access to Anthropic models with bulk discounts, round-the-clock support and money-back guarantees. Stolen AI access is not a curiosity in these markets any more. It is a product line.

Why a token beats a password

A password is a claim that has to be checked. A session token is the result of a check that already passed. Kirk puts it plainly in the research:

Session tokens and API keys are sought specifically by threat actors because it is often possible to replay those secrets and bypass credential-based authentication.

The replay itself is unremarkable tooling. An infostealer copies a browser profile, including sessionStorage and localStorage. The buyer loads that data into an anti-detect browser such as Camoufox, or automates it with SeleniumBase, and routes the traffic through a proxy in the victim's region so impossible-travel rules stay quiet. The service sees a returning session on a familiar fingerprint from a plausible location. There is nothing for MFA to challenge, because the login step is not happening.

API keys are simpler still. They carry no session, no device signal and no second factor. A key found in a .env file or a shell profile works from anywhere until someone revokes it.

Anatomy of the path

infected-laptop     # Lumma Stealer or Vidar, log sold or dumped
  → browser-storage   # sessionStorage and localStorage copied
  → session-token     # JWT replayed, proxy hides the location
  → ai-account        # no password prompt, no MFA challenge
  → provider-api-keys # Gemini, OpenAI, Groq, OpenRouter

Two steps in that path deserve attention. The first is that nothing in it touches your perimeter. The compromise happens on a laptop, often an unmanaged or personal one, and the access arrives at your AI provider as a normal, already-authenticated session.

The second is the last step. An AI account is rarely just a chat window. It holds workspace history, connected data sources, and often the console where provider API keys are issued. A replayed browser session can mint a fresh key, and that key outlives the stolen session by default.

Why this is an identity problem

It is tempting to file this under endpoint hygiene. Stop the stealer, stop the problem. That misreads where the standing access lives.

Every one of those 555 tokens and 24 keys is a non-human identity: a credential that authenticates without a person present, usually with a long life, usually outside the joiner-mover-leaver process that governs staff accounts. Nobody offboards an OpenRouter key. Nobody reviews which agent is holding a Gemini key six months later. The same structural gap produced the Salesloft Drift OAuth breach, where tokens issued to one integration opened data in hundreds of organisations.

The AI layer makes the gap worse in one specific way. Agents need keys to act, so keys get created quickly, stored locally and shared between tools. The credential ends up on a developer laptop, in an MCP server config, in a CI variable and in a browser session, and only one of those copies has to leak.

What to check this week

1. Find every AI provider key you own. Check the consoles for Anthropic, OpenAI, Google, Groq, OpenRouter and anything else in use. List each key, its owner, its creation date and where it is stored. Keys nobody claims get revoked.
2. Rotate keys that ever lived on an endpoint. If a key sat in a .env file, a shell profile, an MCP config or a coding agent's settings, treat it as exposed and issue a new one with a narrower scope.
3. Shorten AI session lifetimes. Where your AI tools sit behind SSO, reduce the session duration and require re-authentication on context change. A token that expires in hours is worth far less in a log dump.
4. Hunt for session reuse. Look for the same session or token appearing from a new IP, ASN or device fingerprint. Okta recommends monitoring active sessions after authentication rather than only at login, and binding sessions to the device where the standard allows it.
5. Put an IP allowlist and a spend cap on provider keys. Both are supported by most providers, both are usually switched off, and either would have made the METR-style credit burn visible in hours instead of weeks.
6. Check personal and contractor devices. Infostealers mostly land on machines you do not manage. If people sign in to company AI tools from those devices, decide now whether that stays allowed.

The tokens in that dump were not stolen from an AI provider. They were collected from laptops and replayed. The question that decides the damage is what each of those credentials could still reach. Elmoz maps that reach before an attacker does.