An identity services provider analysed a 7GB infostealer dump posted to a Telegram channel on 2 August 2026. It came from 5,871 infected machines across 162 countries.

Inside were 44,791 unique JSON web tokens. 555 of them were authentication tokens for AI services — Anthropic, Character.ai, Cursor, Poe, Pika AI among them, alongside the expected Google, Microsoft, Amazon and Notion.

The tokens were unexpired. That is the whole finding.

Why a token beats a password and a second factor at the same time

Authentication and authorisation are different steps, and almost all consumer security advice is about the first one.

When you log in, you prove who you are — password, then a second factor. Having satisfied the service, you are issued a session token. From then on, every request carries the token, and the service checks the token rather than re-running the login. That is not a shortcut or a weakness; it is how every web service works, because re-authenticating on every request is unusable.

The consequence is that the token is a bearer credential. It does not identify you. It proves that somebody completed a login at some point. Replay it from another machine and the service does what it is designed to do: it serves the session.

So the password does not help — it is not being used. The second factor does not help — it was consumed before the token existed. Multi-factor authentication is not bypassed in any meaningful sense. It ran, it succeeded, and it produced the artefact that was later stolen off the machine.

This is the McKesson shape again: every control performed correctly, and the attacker simply held something they should not have held.

Read the 555 carefully

Five hundred and fifty-five is worth stating precisely, because it will get inflated.

It is the count of tokens in one dump that appeared to relate to AI services — about 1.2 percent of the JWTs in that dataset. It is not a count of compromised accounts, not a count of organisations, and not a measure of how many were successfully replayed. Nobody has published that.

What it does establish is direction. AI service tokens are now a category present in ordinary commodity stealer output, mixed in with the email and cloud tokens that have been there for years. The malware was not built to target AI accounts. It swept a machine, and this is what was on the machine.

The market has noticed faster than defenders have. Black market listings now sell bundles of stolen tokens alongside anti-detect browsers — tooling whose entire purpose is to make a replayed session look like it is coming from the original device. Access to Claude, Cursor, ChatGPT and Gemini accounts is offered at a discount to the legitimate subscription price.

Why AI accounts are worth stealing

Two reasons, and the second is the one organisations underestimate.

The obvious one is compute. A hijacked account is metered inference somebody else pays for, which is directly resellable — hence the discount listings.

The less obvious one is history. An AI account is a searchable record of what its owner has been working on: pasted source code, internal documents, draft strategy, customer data, debugging sessions containing production credentials. For anybody doing reconnaissance against an organisation, a senior engineer's conversation history is a richer target than their inbox, and far less likely to be monitored.

What to do

  • Shorten session lifetimes and bind tokens to a device or client where the platform supports it. This is the only control that acts on the actual attack.
  • Make sign-out actually revoke server-side. A token invalidated only in the browser is still valid in a stealer log.
  • Treat any infostealer detection as a session compromise, not a password compromise. Forcing a password reset while leaving live sessions intact fixes nothing.
  • Add AI platforms to the account inventory you monitor. Most organisations have session monitoring for email and cloud and none for the tools their engineers now paste code into.
  • Assume conversation history is exposed if an account is compromised, and treat what was in it as disclosed.

What is not established

  • How many of the 555 were actually replayed. No figure published.
  • Which organisations were affected. The dump is machine-level, not employer-level.
  • Whether any provider has revoked them. No provider statement at time of writing.
  • How representative one 7GB dump is of stealer output generally.
  • Attribution. A Telegram dump has no author for these purposes.