Expand menu

Anthropic was not breached. That is the first fact, and it belongs before everything else, because the easy headline says the opposite.

This weekend Anthropic began emailing Claude users with an uncomfortable notice: a bad actor is using common infostealer malware to steal Claude login sessions from people's computers, then using those sessions to get into accounts and burn through their usage. Those are the company's own words. The malware families identified so far are Vidar, Lumma, StealC, RedLine and Acreed on Windows, and Atomic Stealer on a small number of Macs. Anthropic's response was to sign affected users out, remove saved payment methods and refund the unauthorized charges. And one warning almost nobody picked up: signing out invalidates what was stolen, but it does not remove the malware from the machine.

None of those programs is new or sophisticated. They are credential stealers sold by subscription, delivered through pirated software, fake installers, a crack for something. They have been doing the same thing for years: sweeping up saved passwords, browsing history and browser cookies, then packaging the lot into a file that gets sold in bulk. The malware is not the new part. What they found inside it is.

What was actually stolen

A session cookie is not a password. It is proof that someone already authenticated. When you sign in to a service and clear the second factor, the server hands you a token that says, in effect, «this person has already proven who they are, let them through». That token lives in the browser and travels with every request. Whoever holds it is you.

Which is why the detail that interests me most in this case is the one that sounds boring: the attacker never touched Anthropic's infrastructure. No exploit, no vulnerability on the provider side, no privilege escalation. Just a laptop with malware on it and a cookie file. The second factor did not fail. It had simply already been satisfied, and the token certifying that was sitting on disk.

This breaks an assumption a lot of teams still have written into their security policy: that turning on MFA closes the access question. MFA protects the moment of authentication. It does not protect the session born from it. If that session lasts weeks, survives a change of device and is not bound to anything verifiable about the client, then the second factor is an armored door standing next to an open window.

Why this lands differently in 2026

Three years ago, stealing someone's session on an AI tool meant stealing a chat. Today it is something else. An account with a model provider usually has API keys hanging off it, connected repositories, mail and calendar integrations, internal project context and a payment method with a spending limit. The damage in this particular incident was financial and contained: somebody else's quota consumed. The possible damage is in another category entirely.

And there is an asymmetry that does not get discussed enough. The provider can react, and Anthropic reacted well: it invalidated sessions, stripped payment methods, refunded the money. But reacting is all it can do. The root cause sat outside its perimeter, on a machine it does not manage, with a user who may have installed something they should not have. No service-level agreement covers that. No provider certification prevents it.

Meanwhile the open ecosystem is moving in the opposite direction. That same weekend, OpenClaw shipped version two point zero with more than sixteen thousand merged pull requests, and the change I found most relevant was not a product change but an architectural one: a single trust boundary per gateway. In other words, dropping the assumption that an agent with access to everything is acceptable because the user authenticated once. It is the same question this incident puts on the table, answered from the other side.

What I would do if I ran technology at a company

Three concrete things, in this order.

First, shorten session lifetimes on anything that can spend money or read code. Not on everything: shortening sessions on trivial tools only creates friction and users who look for shortcuts. On the ones that matter, yes, with forced reauthentication when the context changes.

Second, treat the endpoint as part of the AI perimeter, not as a separate helpdesk topic. If one person's machine is compromised, every session on it is compromised too, no matter how well the provider is configured. That includes an adult conversation about pirated software on work machines, which is the classic delivery route for this family of malware.

Third, inventory what hangs off each AI account. Most companies cannot answer what happens if someone walks in tomorrow holding their senior developer's session. That answer should be short and boring, not an investigation.

My read

The incident itself is minor: quota consumed, charges refunded, sessions closed. What it marks is something else. For two years the conversation about AI and security has been almost entirely about the model: prompt injection, training data leakage, hallucinations with consequences. This case has nothing to do with the model. It is identity, sessions and endpoint management: three old, unglamorous disciplines applied to a new asset.

When we review a client's security posture at Indrox as they adopt AI, the hard part is almost never the model. It is that nobody knows how many active sessions exist, where they live, and what they can reach. This weekend that problem stopped being hypothetical and came with an invoice.