The incident was ordinary, which is the point. Commodity infostealer malware — the kind sold by subscription — sat on user machines and lifted active login sessions from a major AI platform. The attackers replayed those sessions and spent the victims’ paid usage. Detection lagged; public reporting put a large share of stolen-credential activity beyond the reach of existing controls. The operator did the only thing its architecture allowed: it signed everyone out and removed stored payment methods.
Look at the shape of that remedy. It is account-wide because the operator could not tell the owner’s requests from the thief’s. Both presented the same credential, and the credential was the entire identity. Security people call this a bearer instrument: whoever bears it, is it. A bearer credential cannot be defended by policy, because policy operates after the impersonation has already succeeded.
The fault is in the construction
The industry’s public answer to bearer theft is well known: bind the credential to a key that cannot leave the machine’s secure hardware, and require every request to carry a proof made with that key. The standards exist and the platforms support them. Under that construction, the copied string is inert — the thief holds a ticket stub, not a ticket.
But binding alone only stops the impersonation. It does not tell you, afterward, what happened — which sessions were genuine, what a suspicious one spent, who suspended it, on what ground, and who turned it back on. An operator that cannot answer those questions is back to the account-wide logout, because disbelief of everything is the only honest position left.
What the record should show
This is where spend assurance and credential security turn out to be the same discipline. TokenMark™’s filed architecture already treats every allowance as a declared lane and every enforcement step as a chained, countersigned event: observe, enforce, suspend, each on a declared criterion, with break-glass under dual control and refusals on the record. Apply that to sessions, and a hijacked credential stops being an account-wide emergency. It deviates from its lane; it is suspended alone; the owner keeps working; and the whole episode — criterion fired, scope of suspension, lift attempts granted and refused — is recomputable by a party that never saw a single prompt.
Payment custody follows the same rule. Stored instruments do not live where sessions can reach them, so “strip everyone’s payment methods” never has to be the remedy; changing an instrument requires fresh presence with the bound key and is itself a sealed event.
The question to ask any vendor
After the next incident like this one — and there will be a next one — the question for any platform that holds your spend is not did you detect it. It is: can you show me, on a record I can recompute, which credentials were mine, what the stolen one was allowed to spend, and why your smallest available remedy was smaller than my account? If the answer is a description of controls, that is a policy. If the answer is a record, that is evidence.
The portfolio standard behind this position, AW-SEC-001, is provided to pilots and design partners under NDA.