The warning came from Anthropic, not from your antivirus

On 30 August it emerged that Anthropic was emailing some Claude users. One sentence of theirs sums it up: "we have recently become aware of a bad actor that is using common infostealer malware to steal Claude login sessions from people's computers, then using those login sessions to access Claude accounts and consume their usage". Coverage treated it as an artificial intelligence story. It is not. If somebody at your company got that email, what you are holding is an infection report for a machine in your estate, signed by a supplier that is not even yours.

We sell automation and AI and cybersecurity, so the vested interest is on the table from line one. Which is why we will start with the part that takes the easy argument away from us, and that Anthropic wrote down without any hedging: "we have no reason to believe that this malware is related to Claude, installed through Claude, or related to anything you did with Claude". It is generic malware, the kind that arrives with an unofficial installer or a malicious app. There is no hole in the product. And even so, for a fair number of companies, this will be the most useful security notice of the month.

What happened, and how they found out

The families Anthropic names are the usual ones: Vidar, LummaC2, StealC, RedLine and Acreed on Windows, and Atomic Stealer (AMOS) on macOS, the latter in a small number of cases. What they copy is not new either: saved passwords, browser cookies and locally stored credentials. Anthropic signed affected users out, revoked the compromised sessions, removed saved payment methods from accounts, refunded charges it identified as unauthorised, and kept existing plans running through the current billing period.

The sentence we find most interesting in the whole notice is this other one, and it is not about security: "if your usage limits looked like they refilled and then drained while you weren't using Claude, this was likely the cause". There is the sensor. The signal that set all of this off was not an antivirus, nor a detection rule, nor an analyst looking at endpoint telemetry. It was consumption: accounts spending at hours when their owner was not around. A billing pattern.

Claude is not the incident. It is the canary.

There is another sentence in the notice worth reading twice, because it is the one that reclassifies the whole thing: "signing you out of Claude stops the stolen sessions, but it doesn't remove the malware". An infostealer does not go after one account. It goes after the entire browser profile and whatever is sitting on disk. If one of your employees' machines handed over the Claude cookie, it handed over at the same time everything else living in that profile: the Microsoft 365 session, the VPN portal, the router panel, the GitLab, the webmail, the password manager if it was unlocked.

Claude is simply the place where the theft shows, and it shows for a silly reason: the thief spends. Of all the sessions living in an office browser profile, the AI tool's is one of the few with a counter that empties. If somebody steals your corporate mail session, nobody is going to watch a usage limit drain at three in the morning. That is why this warning arrived and the others did not. It is the same origin we saw in August, when somebody was selling whole Entra directories with more records than employees: there was no platform breach, the credentials traced back to infostealer infections on user machines. And on macOS we already covered how that malware gets in without exploiting anything: the user pastes it into Terminal themselves. What this case adds to what we already said when writing about passkeys is not the diagnosis — the weak link moved to the machine, that much was already said — but the arithmetic of what happens next, which is what comes now.

MFA did not fail: it never got to play

Nearly all the coverage sums this up as "the theft bypasses two-factor". True, but badly told, and the nuance changes what you should do. MFA did not fail. MFA never got to play. A session cookie is not a credential: it is the receipt of an authentication that already happened and already went well. The attacker does not sign in, so there is no moment at which anyone could ask them for a second factor. They replay a session that was already open. It is the same family of problem we covered with the tokens of apps connected to Microsoft 365, with one important difference: there you granted the token yourself by signing a consent, and here they lift it off the disk without asking you anything.

The five events that cut a session, and the one that is missing

If your corporate identity lives in Microsoft Entra, the mechanism built for this is called continuous access evaluation (CAE). Instead of waiting for the token to expire, services subscribe to a list of critical events and react in near real time. The documentation lists exactly five:

• The user account is deleted or disabled.
• The user's password is changed or reset.
• MFA is enabled for the user.
• An administrator explicitly revokes all refresh tokens for the user.
• Microsoft Entra ID Protection detects high user risk.

Now read the list again looking for "the user's machine is infected". It is not there. There is no critical event meaning "this machine is handing over cookies". The only door that fact can come through is the fifth one, high user risk, and that door has to be opened: either ID Protection works it out on its own, or somebody flags it. Put differently, and this is our reading rather than a quote: the state that actually matters here is not a state the token issuer knows by itself. Somebody has to tell it. If nobody does, the token stays valid because, from where Entra is looking, nothing has happened.

The arithmetic of revocation, unvarnished

The numbers are all published and it is worth having them together, because almost nobody puts them in the same sentence. Without CAE, an access token's default lifetime is one hour. With CAE, that token becomes long-lived, up to twenty-eight hours, precisely because revocation stops depending on the clock and starts depending on events. The response to a critical event is described as "near real time", with a declared latency of up to fifteen minutes due to propagation (IP location policy enforcement, by contrast, is instant). And the initial implementation, the documentation itself says, focuses on Exchange, Teams and SharePoint Online.

Here is the detail that knocks over a lot of people's plan. The first thing almost everybody does when they suspect an account is pull that person out of a group or drop a new Conditional Access policy on them. Well: the documentation says changes to Conditional Access policies and to group membership can take up to one day to take effect, due to replication between Entra and resource providers like Exchange Online and SharePoint Online, with an optimisation that brings policy updates down to two hours and that, in the documentation's own words, does not cover every scenario yet. The only thing that cuts today is revoking the session deliberately: the "Revoke session" button on the user profile page or the Revoke-MgUserSignInSession command. And three more warnings from the small print: CAE does not support guest accounts — that is, the externals: the consultant, the agency, your own IT supplier; if the sum of IP ranges across your named locations goes past 5,000, CAE stops enforcing the location-change flow in real time and goes back to issuing a one-hour token (though it keeps enforcing all other events and policies); and SharePoint Online, per that same page, does not support user risk events — which was precisely the fifth door on the list above.

The purpose-built defence exists. Look where it is.

Against exactly this attack — replaying a stolen token from another machine — Microsoft has a control called Token Protection. The idea is good and it is the right one: when a user registers a supported device, a Primary Refresh Token is issued and cryptographically bound to that device, so that even if an attacker steals the token they cannot use it from another machine. With Token Protection enforced, Entra only accepts those device-bound sign-in session tokens.

Now the honest part, from that same documentation page, updated in August 2026. Token Protection is generally available for native applications on Windows, iOS/iPadOS and macOS, and the resources where it can be enforced are Exchange Online, SharePoint Online and Teams (on Windows, also Azure Virtual Desktop and Windows 365). For browser-based applications it is in preview on Windows and macOS, and limited to selected web apps that access Azure Resource Manager, with additional operating system, browser and extension requirements. On iOS/iPadOS the browser is simply not supported. And one nuance the page itself lets slip: the supported-devices section heads the Apple block as "Preview" and requires macOS 14 or later, or iOS 16 or later, with Microsoft's Enterprise SSO plug-in and only on MDM-managed devices.

Put those two sentences next to what happened. The theft was in the browser. The defence designed for exactly this attack is generally available where the theft did not happen, and in preview, with an application list, where it did. This is not a dig at Microsoft, who also recommend deploying it in report-only mode before enforcing it: it is the real picture as of August 2026, and it is worth having in front of you before promising anyone — or a committee — that this is solved with a checkbox. And that picture only covers the applications in your directory; the Claude theft, if the subscription is a personal one, falls outside the frame entirely.

How many AI accounts are there in your company that you cannot close?

This is the question we think the case leaves behind, and it is not about Claude or any particular vendor. It is about inventory. Ask yourself these four, on paper:

• Are those subscriptions in the company's name and inside your directory, or did somebody pay for them with their own card and personal email?
• If you have to cut that person's access tomorrow, do you have the button, or do you have to ask them nicely?
• If their session gets stolen, who finds out, and through what? In this case the supplier found out, and found out through consumption. You found out because somebody forwarded you an email.
• What is pasted into that conversation history? A configuration snippet, a log with server names, a price list, a draft contract. None of that is a state secret, and all of it gets pasted by ordinary people trying to get help with their job.

None of this is an attack on AI in the workplace. We use it and we build it: part of our own internal automation runs on self-hosted n8n. Which is exactly why we already wrote about the AI pilot nobody switched off, the one that ends up in production with no owner because nobody ever decided it was. This is precisely the same thing, but about the account instead of the server: what comes in through the back door does not get inventoried, and what does not get inventoried cannot be switched off.

Who this asks almost nothing of

We will say it even though it does not suit us. If your AI tools are contracted in the company's name, sign in through SSO and their accounts live in your directory, this is half an hour of work and not a project: revoke sessions for anybody who might have been infected, change the password and run a scan on the machine. That is it. You do not need to buy anything or call anyone. And if the Anthropic email was forwarded to IT within minutes, your real problem today is a different one and this article is not about you.

If your people use personal accounts, you do not have half an hour of work: you have a conversation pending. And the conversation is not fixed by buying anything either, because the problem is not technical. People do not take out a subscription on their own to route around IT; they take it out because they need it to do their job and because asking through the official channel takes three weeks. Ban it without offering an alternative and the only thing you achieve is that next time they will not tell you.

What we would do on Monday

• Ask who received that email, and ask without any intent to catch anyone out. Half the value of this exercise lies in people saying so without fear. If whoever owns up gets a telling-off, you stop hearing about it from the second one onwards.
• Treat the machine as the incident, not the account. Full scan before signing back in, which is exactly the order Anthropic recommends and is no accident: if you sign back in on a machine that is still infected, you are handing over the new session.
• Revoke the corporate session deliberately, without trusting it to expire: "Revoke session" on the user profile page or Revoke-MgUserSignInSession. Changing the password works too, because it is one of the five critical events. Pulling the person out of a group does not: that can take a day.
• Look at what else lived in that browser profile, and not just Microsoft 365. The VPN portal, the router panel, the hosting, the bank, the invoicing tool. It is a boring list to write and it is the one that actually measures the blast radius.
• Write the list of AI tools your people use, with who pays for each one. This one is not urgent and it is the only one that changes anything next month.

Who gave the warning

What caught our attention in this case is not the malware. There is one every week and most of the families on the list have been around for years. What caught our attention is the chain of who finds out what. A machine at a company gets infected. An AI supplier spots an odd spending pattern. And the warning lands in an employee's personal inbox, where they decide whether to forward it. Nowhere in that chain does the company's IT department appear, nor any tool of theirs.

We would like to be able to say that is unusual. It is not. It is what happens when part of the toolkit your people use gets bought without passing through you: the sensor stops being yours and becomes somebody else's invoice. Anthropic did its part well — warned, revoked, pulled the cards and refunded the money — but Anthropic could only see its slice, and its slice was consumption of its own product. The infected machine is still where it was.

Sources (consulted on 31 August 2026): the text of Anthropic's notice, the sentences quoted here, the malware families (Vidar, LummaC2, StealC, RedLine and Acreed on Windows; Atomic Stealer on macOS, in a small number of cases), and the company's actions — signing users out, revoking compromised sessions, removing saved payment methods, refunding unauthorised charges and keeping plans running through the current billing period — come from BleepingComputer's coverage of 30 August 2026 and Security Affairs' of 31 August, both reproducing the same email. We did not receive that email ourselves: what we quote is what those two publications reproduce, and we say so because it matters. The five critical events, the one-hour default access token lifetime, the long-lived tokens of up to twenty-eight hours in CAE sessions, the up-to-fifteen-minutes propagation latency versus instant enforcement of IP policies, the initial focus on Exchange, Teams and SharePoint Online, the up-to-one-day delay on policy and group membership changes (with a two-hour optimisation that does not cover every scenario), the two ways to revoke a session immediately, the lack of support for guest accounts, the 5,000 IP range threshold on named locations (with the caveat that CAE keeps enforcing all other events and policies) and the fact that SharePoint Online does not support user risk events all come from "Continuous access evaluation in Microsoft Entra" (Microsoft Learn). How Token Protection works, the cryptographic binding of the Primary Refresh Token to the device, general availability for native applications on Windows, iOS/iPadOS and macOS, the resources where it can be enforced, the preview status for browser-based applications on Windows and macOS limited to selected web apps accessing Azure Resource Manager, the "Not supported" entry for the browser on iOS/iPadOS, the "Apple (Preview)" heading in the supported-devices section with its macOS 14 or iOS 16, Enterprise SSO plug-in and MDM-managed requirements, and the recommendation to deploy in report-only mode first come from "How Token Protection Enhances Conditional Access Policies" (Microsoft Learn), a page updated in August 2026. These are ours, and we flag them as judgement rather than published fact: the reclassification of the notice as an infection report for a machine; the reading that the sensor in this case was consumption and not security; the idea that Claude is the canary because the thief spends and therefore shows, while other stolen sessions have no counter that empties; the observation that "the user's machine is infected" is absent from the five critical events and that this state has to be told to the token issuer by somebody; the contrast between where Token Protection is generally available and where the theft happened; the whole AI account inventory section and its four questions; the Monday checklist; the observation that most of those malware families have been in circulation for years; and the closing reading about the chain of who finds out what. Anthropic explicitly states that the malware is unrelated to Claude and we do not imply otherwise at any point in this article.