Protecting AI Accounts When Passwords and MFA Are Not Enough

Passwords and multifactor authentication protect the process of signing in. They do not necessarily protect an authenticated browser session after sign-in is complete. That distinction has become important for AI accounts because a live session can carry access to paid model usage, conversations, uploaded material, connected workflows, and other capabilities granted to the account.

Anthropic recently warned some Claude users that common infostealer malware had copied active login sessions from infected computers. According to reporting by BleepingComputer, attackers reused those sessions to enter accounts and consume available usage. Anthropic responded by revoking affected sessions, signing users out, removing saved payment methods, and refunding charges it identified as unauthorized. The company said it had no reason to believe the malware originated from Claude or resulted from using the service.

This was not described as an attacker cracking passwords or defeating an MFA challenge. A browser normally receives a cookie or token after the user has successfully authenticated. The browser presents that artifact during later requests so the user does not have to enter a password and complete MFA on every page. If malware extracts the artifact and a service accepts it from another environment, the attacker can inherit an already authenticated state.

MITRE ATT&CK classifies this behavior as the use of a stolen web session cookie. Its description explains that an adversary may import a stolen cookie into a controlled browser and use the application as the victim while the session remains active. The technique can bypass some MFA protocols because the underlying session has already passed authentication. Microsoft describes the comparable pattern as “pass-the-cookie”: malware extracts browser cookies, and an attacker inserts them into another browser to get past checkpoints that would apply during a new login.

It is therefore more accurate to say that session theft can bypass the need for a fresh password and MFA challenge. It does not prove that the password was recovered, that the second factor was cryptographically broken, or that MFA has no value. MFA still blocks many attacks based only on stolen credentials. The problem is that a reusable session artifact sits downstream from those protections and can temporarily function as a credential of its own.

The first response should be containment from a different, trusted device. Open the AI service’s session-management controls and terminate unfamiliar sessions. If the service offers a global sign-out option, use it when the scope is uncertain. Anthropic’s active-session page allows Claude users to review logged-in devices and browsers and remotely terminate sessions they do not recognize. This action directly targets the stolen authentication state; changing a password alone may not immediately invalidate every existing session on every service.

Next, protect the recovery path. Review the primary email account, its active sessions, recovery addresses, recovery phone numbers, and authentication methods. Email often controls password resets for other services, so an attacker who retains access there can reverse later recovery work. Remove saved payment access where appropriate, examine unexplained purchases or consumption, and report unauthorized activity through the provider’s official support process.

Then investigate the affected computer before creating replacement sessions on it. Anthropic’s warning emphasized that signing a user out stops the stolen session but does not remove the malware. If the infostealer remains active, logging in again can simply give it a new session to copy. Use reputable endpoint security tools and follow the device owner’s or organization’s incident-response process. Where confidence in cleanup is low, rebuilding the device from a trusted source may provide a clearer recovery boundary than repeatedly signing back in and scanning again.

Only after moving account recovery to a trusted environment and addressing the endpoint should users reset exposed credentials and establish new sessions. Passwords stored in the browser or entered while the malware was active deserve review beyond the AI account. General-purpose infostealers are built to collect multiple kinds of locally available information, so a Claude warning should be treated as evidence of a wider device compromise rather than an isolated problem with model usage.

Teams should broaden that review according to what the affected person could access. A developer’s environment may contain repository credentials, cloud access, package registry tokens, API keys, and workplace sessions. The reported Claude incident concerned browser login sessions; it did not establish a compromise of Anthropic API keys, developer consoles, enterprise identity providers, or every other credential on an infected machine. Reviewing those assets is a precaution justified by the nature of general-purpose information-stealing malware, not proof that each asset was taken.

After containment, preserve and inspect the evidence the available systems provide. Useful records include session history, security notifications, consumption changes, purchases, endpoint detections, identity-provider events, and administrative audit logs. Microsoft recommends examining compromised accounts for persistence and suspicious modifications after token theft. The exact checks depend on the application, but the principle is durable: revoking the artifact stops one access path, while investigation determines whether the attacker created another.

The public Claude report supports a limited set of conclusions. Some users’ computers were infected with common infostealers; active Claude sessions were collected and abused; and Anthropic applied account and payment remediation. The report identified several Windows malware families and a smaller number of Mac cases. It also described unexpected usage depletion as a symptom that some affected users could observe.

The report does not disclose the total number of affected users, the complete abuse window, the total unauthorized usage, or the investigation’s detection method. It does not establish that Anthropic’s central systems, models, or account database were breached. Nor does it prove that attackers read conversation histories, opened uploaded files, used connectors, or changed account settings. A valid session may offer capabilities available to its user, but possible access and demonstrated attacker activity are not the same claim.

That restraint matters for security decisions. Understating the event as mere password reuse would produce the wrong recovery order. Overstating it as a platform breach would misidentify the reported entry point. The defensible interpretation is that endpoint malware corrupted the trust represented by authenticated browser state, and the resulting abuse became visible inside the AI service.

For buyers and administrators, session visibility is the first product control to evaluate. Can users see active devices and browsers, approximate locations, and recent activity? Can they terminate one session without disrupting every device? Is there also a reliable global sign-out option for uncertain incidents? Can administrators revoke sessions centrally, and is the effect immediate across web, desktop, mobile, and connected experiences?

Revocation semantics deserve particular scrutiny. Microsoft notes that revoking a refresh token does not necessarily invalidate an already issued access token immediately; access can persist until that token expires unless the platform supports faster enforcement. AI vendors need not use Microsoft’s architecture to face the same evaluation question: after a user or administrator presses “sign out,” which authentication artifacts stop working, on which surfaces, and how quickly?

Session lifetime is another tradeoff to examine. Shorter-lived artifacts reduce the period in which a copied token is useful, but they also force more reauthentication and can interrupt long-running work. Risk-based reauthentication can provide a more selective boundary by challenging sensitive actions, unusual environments, or elevated operations. Customers should ask which events trigger a fresh authentication check and whether saved payment changes or other consequential actions receive additional protection.

Detection and notification determine how soon reactive controls can operate. Useful capabilities include alerts for unfamiliar sessions, unusual locations, abnormal consumption, and security-setting changes. None is conclusive by itself: legitimate users travel, change networks, switch browsers, and vary their AI usage. Products should combine signals, retain useful audit history, and give users enough context to distinguish ordinary activity from a session they should revoke.

Managed-device policies can reduce exposure for organizational accounts. Microsoft recommends visibility into where users authenticate, device compliance controls for important applications, and compensating session controls for unmanaged devices. Teams evaluating AI services should determine whether enterprise plans can restrict access to known devices, integrate with existing identity controls, separate privileged administration from routine use, and support rapid containment without waiting for each employee to respond.

Device-bound sessions offer a more direct defense against exported-cookie replay. Google’s Device Bound Session Credentials design uses a hardware-backed, non-exportable private key and short-lived cookies. The browser must repeatedly prove possession of the corresponding key before the server issues fresh session cookies. A cookie copied to another machine should therefore expire quickly without the device-held key. Google announced public availability for Windows users in Chrome 146 and said macOS support would follow in a later release.

This protection is neither automatic nor absolute. A service must implement the required registration and refresh endpoints, and browser support alone does not show that a particular AI product uses DBSC. Device binding is designed to frustrate remote replay of exported cookies; it does not make an infected computer trustworthy. Malware operating on the device may still steal other information or act through the compromised environment. Recovery, multiple-device use, unsupported hardware, and federated identity also create deployment questions that buyers should ask vendors to explain.

The strongest product posture combines layers: endpoint protection to reduce theft, visible and revocable sessions to contain it, shorter or risk-sensitive authentication windows to limit usefulness, detection to identify abuse, and device binding to make exported artifacts harder to replay. Clear support procedures and billing remediation reduce harm after controls fail, but they should complement preventive design rather than substitute for it.

For AI users, the practical rule is simple: an unexpected usage spike or session warning may be an endpoint incident even when the password and MFA method appear unchanged. Revoke access from a clean device, secure recovery accounts, investigate the endpoint, rotate exposed credentials, and only then create new trusted sessions. For teams, the durable lesson is broader: evaluate authenticated session state with the same seriousness as passwords, API keys, and other credentials, because attackers already do.

Browse the directory →