When your AI agent starts working overtime — without you
On August 4, 2026, Grant De Swardt, an independent AI consultant based in East Sussex, U.K., noticed his Claude Max 20x account burning through tokens on a day he hadn’t touched it. The next day he shut down every integration connected to his account and still watched usage climb — in one tightly controlled window, consumption jumped from 45% to 55% while every scheduled task was paused, cloud execution was disabled, and no local Claude Code session was running.
De Swardt runs a one-person business helping small and mid-size companies set up AI agents — from pulling purchase-order data out of emails to running website and coding tasks. His entire operation leans on AI. So when Anthropic couldn’t give him an itemized breakdown of what was consuming his tokens, suspended his account, invalidated his sessions, and issued a partial refund of just £44.49 against his $200-a-month subscription, it wasn’t a minor inconvenience — it stalled his business for roughly two weeks.
Anthropic later told him the likely cause: a compromised Claude session key had been used to mint unauthorized Claude Code OAuth tokens. In the company’s words, relayed by De Swardt, the account “appeared to have been used by an unauthorized-looking third-party service to handle activity for other people,” though Anthropic said it could not determine exactly how access was obtained.
He wasn’t the only one
De Swardt posted his experience to Reddit, and the thread quickly grew to more than 80 comments from other subscribers describing near-identical symptoms: accounts auto-upgrading without consent, credit cards getting charged, and usage spiking from 0% to 100% in as little as 30 minutes with no corresponding work being done. One user reported going from 0% to 49% usage in 12 minutes after nothing more than a couple of prompts and a web search. Another said their account maxed out its token allowance on three separate days without any use at all, and filed a report on Anthropic’s GitHub — which drew its own wave of similar complaints.
Crucially, two affected users shared emails Anthropic had proactively sent them, warning that their accounts showed signs of compromise. Anthropic’s message described a “bad actor” using common infostealer malware to lift Claude login sessions directly off victims’ computers, then using those hijacked sessions to log in and burn through their usage. The company was clear that the malware itself had nothing to do with using Claude — it arrives through the usual channels, like infected downloads or malicious ads, and simply happens to scoop up Claude credentials along with everything else saved in the browser.
Where Anthropic detected the pattern, it acted: signing users out, invalidating existing authorizations, issuing some refunds, and flagging the likely malware infection. De Swardt, notably, never received that warning email, and maintains he found no evidence his own machine was infected — leaving him without a clear answer for how his account was accessed. The experience, combined with what he describes as a lack of any tool to see exactly what is consuming tokens, led him to cancel his Claude subscription for Cursor, which lets him route work through multiple, cheaper models instead.
Why this matters beyond one freelancer’s bad month
This isn’t really a story about one vendor’s malware problem — it’s a preview of a security gap opening up across the whole AI-agent economy. As coding assistants, browser agents, and autonomous workflows get wired directly into email, cloud infrastructure, and payment systems, the login session for an AI account has become just as valuable to attackers as a banking credential, and in some ways more dangerous, because it often carries standing permission to act.
Security researchers tracking this trend note that a stolen session token is effectively post-authentication material: it lets an attacker skip the login and MFA challenge entirely, because that challenge was already completed by the legitimate user. Industry threat-intel groups have reported that AI-oriented infostealers — families like Lumma, Vidar, RedLine, and Stealc — can now harvest browser-stored credentials and session cookies in under a minute and exfiltrate them before endpoint security even registers the file. Some 2026 estimates put the time between initial infection and stolen credentials showing up for sale on darknet markets at as little as an hour.
For an enterprise, the risk compounds. A single compromised developer laptop can leak not just a personal Claude login, but API keys, MCP-connected service credentials, and access to whatever internal systems that AI agent was authorized to touch — purchase orders, source code, customer data, cloud consoles. And because usage-based billing means attackers can quietly drain an account’s allowance without triggering the kind of alarm a fraudulent purchase would, theft can run for weeks before anyone notices the pattern, exactly as it did for De Swardt.
Steps enterprises should take now
1. Treat AI session tokens like privileged credentials, not app logins. Any account with API keys, MCP connections, or agentic execution rights should be inventoried and governed the same way you’d treat a cloud admin account or a CI/CD secret — not left to individual employees to manage informally.
2. Move privileged AI accounts to phishing-resistant authentication. FIDO2 passkeys or hardware security keys prevent the underlying credential from ever being extractable by browser-based malware, since the private key never leaves the authenticator. This doesn’t recover an already-stolen session, but it closes the door on new theft.
3. Deploy continuous or device-bound session validation where available. Frameworks like Google’s Cross-Account Protection or Microsoft’s Continuous Access Evaluation tie a session to a specific device fingerprint, so a token replayed from an unfamiliar device or network fails automatically. Ask your identity provider whether equivalent controls extend to your AI tooling.
4. Set usage-anomaly alerts, not just spend caps. Sudden, unexplained token consumption — especially during hours when no scheduled task or human session is active — should trigger the same kind of alert as an unusual login location. Waiting for a monthly invoice to notice theft, as happened here, is far too slow.
5. Maintain endpoint hygiene as your first line of defense. Because infostealers are typically delivered through infected downloads, cracked software, or malicious ads rather than any flaw in the AI product itself, standard endpoint protection, restricted software installation policies, and employee training on suspicious downloads remain the most effective way to stop token theft before it starts.
6. Build an incident-response runbook specific to AI accounts. When compromise is suspected, remediation must happen on a clean machine: rotating API keys, revoking all active sessions, auditing MCP and third-party connections, and checking whether any agent-linked data or code was exposed — all before re-establishing new credentials, since re-authenticating on an infected host simply hands the attacker a fresh token to steal.
7. Push vendors for itemized, real-time usage visibility. De Swardt’s core complaint — that Anthropic could confirm something was wrong but not show him exactly what was consuming his tokens — is a gap enterprises should treat as a procurement requirement. Before signing an enterprise AI contract, ask what granular usage logging, anomaly detection, and session-revocation tools are available, and how quickly support responds to a suspected compromise.
In nutshell
The Claude token-theft cases making the rounds this week aren’t evidence that Anthropic’s product is uniquely vulnerable — infostealer-driven session hijacking is hitting Microsoft 365, Salesforce, Google Workspace, and virtually every major SaaS platform in 2026. What they do make clear is that as AI agents get deeper write-access into business operations, the account securing that access deserves the same scrutiny, monitoring, and incident-response planning organizations already apply to their most sensitive systems — not the lighter touch still common for “just another app login.”

No responses yet