Four Groups Named the Attack This Year. Nobody Has Named the Defense. Here Is the Credit Map, and Two Measurable Properties That Decide Whether You Can See It Happening to You.
- Patrick Duggan
- 1 hour ago
- 8 min read
Yesterday we published a post calling the theft of metered AI inference capacity a distinct category, using a name we had been trying out. Then we went looking to see who else was on it, which is a thing we should have done first.
The answer is: several people, earlier, with better distribution and better names. Good. Smart people should get credit they earned, and the map below hands it over in detail.
But the naming race is the least interesting thing on this table, and it is also the only part anyone is competing for. Four groups have named the attack. Nobody has named the defense. Every write-up we found, ours included, ends at the same three bullets — cap your keys, rotate credentials, watch your spend — and not one asks the question that decides whether any of that works: can you see it at all?
So this post does two things. It gives the credit away, and then it stakes a claim somewhere nobody is standing: the measurement side. Two propositions — one about what makes this attack detectable at all, and one we had to withdraw and rebuild this morning after discovering our own instrument had contaminated it. Both are offered to be falsified rather than agreed with. The second one is the more useful of the two precisely because it broke.
The map, with dates where we could establish them
Stripe, May 7 2026 — the earliest clear framing we found. Stripe's Head of Data and AI told Fortune that token theft is "the most under-discussed topic in AI," and described attackers who "burn inference costs, can rack up massive usage bills that they never intend to pay, and they can do that very, very quickly because they are consuming tokens at machine speed." That is the whole thesis, four months before we wrote ours, from a company that watches payment fraud for a living.
Palo Alto Unit 42 — "Token Jacking." Their framing, and the best name of the four: it borrows the shape of cryptojacking, which is exactly right, because the economics are the same. Someone else's metered resource, consumed on your bill, with no data taken. We could not establish a firm publication date and are not going to guess one.
WorkOS — "LLM token theft." Framed around the startup bottom line: attackers creating accounts in bulk to extract free inference and trial credits with no intention of paying. Their number is the one worth remembering — a single prompt to an agent on a frontier model can cost around two dollars, making inference roughly a million times more expensive per request than an HTTP hit. That ratio is why this is worth an attacker's time at all. Date not established.
Us, September 1 2026 — last to the name, writing it up off the METR disclosure. Our contribution is in the last section and it is not the noun.
Add the two disclosures that gave the category its receipts: Anthropic on August 30, describing infostealers replaying stolen session cookies to drain user quota; and METR, disclosed around September 1, describing an incident from March 2026 in which an attacker prompted a running agent to reveal its provider API key, added SSH persistence, and consumed roughly $600,000 of inference over three weeks.
Convergence like that is a signal. When four groups who are not talking to each other reach for the same idea inside one year, the idea is usually load-bearing.
The naming collision is a real problem, not a quibble
Here is the part that should get solved by someone, and it will not be us.
"Token theft" already means something else. In mainstream security it means OAuth and session token theft — adversary-in-the-middle attacks, stolen bearer tokens, cookie replay. Microsoft has playbooks under that name. Vercel has a post titled "Protecting against token theft" that is about exactly that older meaning.
So the phrase now points at two different attacks, and they are not even distant cousins:
Steal a token to become you — classic auth token theft, where the token is a credential and the prize is your access.
Steal a token to spend you — where "token" means an inference unit, and the prize is your quota.
Worse, the Anthropic case is genuinely both: a stolen session cookie, which is an auth token in the old sense, used to consume inference tokens in the new sense. One incident, one word, two meanings, and you cannot tell from the sentence which one anybody means.
Unit 42's "Token Jacking" sidesteps this cleanly by borrowing from cryptojacking, and if the field settles on that we would call it settled well. We are dropping our own label. The category does not need a fourth name from us; it needs one everyone uses.
The defensive space, which is empty
Nobody owns this yet, so we are going to plant a flag on the measurement problem rather than on a noun.
Property one — baseline variance decides detectability
Compare the two disclosures.
Anthropic caught theirs quickly. The tell was usage limits refilling and then draining while account owners were inactive. That is a clean anomaly — activity where there should be none. It works because a consumer account has a flat, quiet baseline, so an intrusion has a shape that stands out against it.
METR ran for three weeks. Not through negligence, through the structure of what they do. METR runs large-scale model evaluations. Enormous token consumption is their normal. No quiet period, no flat line, no contrast. The signal and the noise were made of the same material.
Proposition 1. Exposure to inference theft is not primarily a function of your controls. It is a function of the shape of your usage baseline — detectability falls as baseline variance rises.
The corollary is unpleasant and it is the reason this matters. The organizations with the most quota worth stealing are AI-native ones: labs, eval shops, agent platforms, anyone running large batch inference. Those are exactly the organizations whose consumption is spikiest and least legible. The better your AI story, the worse your detection surface for this specific attack.
Which inverts the standard advice for the people most at risk. Alerting on absolute volume is useless when your legitimate volume is bursty. What survives is rate of change against your own recent baseline, per key, plus hard caps that make the ceiling a decision rather than a discovery.
Property two — a hypothesis we had to withdraw before we could test it
This section was going to propose that the derivative of an organization's AI legibility score is a leading indicator of deteriorating operational discipline. We had a case: Boston Scientific read 65 on April 1, 48 on April 12, 53 on June 23, and 35 after the August 25 breach. A number falling by roughly a quarter in front of an incident.
We killed it this morning, and the way we killed it is the more useful contribution.
Two dimensions in our own scoring were repaired between the June and August readings. accuracy used to return a fabricated neutral 50 for any domain with no ground truth to check model claims against; it now returns 0, meaning we could not verify. awareness used to run on a length ladder capped at 85, so a large share of domains scored exactly 85 regardless of what models actually knew. Both repairs were correct. Both lower scores.
So we ran the test that should have come first: if the decline were about Boston Scientific, its peers should not have moved with it. Stryker went 52 to 34 in the same window. Medtronic went 54 to 29. Neither had an incident to explain it. And Cloudflare — measured after the change — held accuracy at 61, because Cloudflare is a domain where model claims can be checked, so the repair did not apply to it.
Three peers stepping down together, and the one case the change does not touch staying put. That is not a signal. That is a ruler being replaced mid-measurement.
The full correction is published separately. What belongs in this post is the transferable part:
Proposition 2 (revised). Any longitudinal security or posture metric is uninterpretable across an unmarked change in how it is computed — and the change is usually an improvement, which is exactly why nobody flags it.
Nobody labels a bug fix as a discontinuity. It goes in as "accuracy scoring corrected," ships, and every series crossing that date now contains a step that looks precisely like a real trend. We caught ours only because we tried to build something on top of it. Most people never build the second thing, so the artifact stays in the chart.
If you run any longitudinal measurement — posture scores, risk ratings, vendor scorecards, your own internal metrics — the question worth asking today is not what your trend shows. It is when you last changed how you measure, and whether the series says so.
What we are doing about it, since a hypothesis you cannot test is worth less than a method you can: every reading now carries a scoring-method version, no derivative is computed across a version boundary, and a fixed cohort — healthcare and medical device companies where outcomes are known, plus a control arm of security and infrastructure vendors — is re-scored weekly starting now. We currently hold no usable series at all. The only way to have one is to start, on a stamped method, and wait.
The derivative hypothesis may still be right. We simply have no honest way to find out yet, and saying that is faster than pretending otherwise.
Open questions, genuinely open
We do not have answers to these and would rather ask them in public than pretend.
Is it one category or three? Credential theft from an agent, session-cookie replay, and bulk free-tier account farming share an objective but have completely different economics, victims and controls. Lumping them may be the same mistake as lumping all malware together because it all runs code.
Where does the stolen capacity go? There are reports of resale — one stolen key monetized by selling compute onward to buyers who never touch the victim. If a functioning resale market exists, that changes this from opportunistic to industrialized, and the market is the thing to study rather than the individual thefts.
Does anyone have a measured baseline-variance figure? Proposition 1 says detectability tracks usage variance. We have two data points and an argument. Somebody with fleet-scale billing telemetry — a model provider, a payments company, a large platform — could test it properly and either establish it or kill it. We would rather it were tested than agreed with.
How many published security trend lines contain an unmarked method change? We found one in our own data by accident. Scoring methodologies get improved constantly and improvements are never labeled as discontinuities. If you publish a longitudinal metric, we would genuinely like to know whether your series carries a version stamp — and if it does not, whether you can rule this out.
Does on-premises inference actually help, and how much? The obvious answer is that owning the hardware removes the meter, so the billable failure mode cannot occur. The honest answer is that it converts an invisible operating-expense attack into a visible capacity attack — someone still runs their jobs on your GPUs, you pay in throughput. We have a commercial interest in on-premises infrastructure and are declaring it rather than pretending this is disinterested. We think the argument holds anyway; we would like someone without our incentives to check it.
What we would ask of anyone working on this
Use Unit 42's name or pick one and say so, because four names is worse than any one of them. Stop competing on the noun and start competing on the measurement, because the attack is named five times over and the defense is not named once.
If you have billing telemetry at scale, test proposition 1. And if you publish an incident, publish the detection latency and what the baseline looked like — METR's three weeks is far more instructive than the $600,000, and it is the number that usually gets left out of a disclosure.
Credit where it belongs: the framing to Stripe, the best name to Unit 42, the startup economics to WorkOS, and the two disclosures that made it concrete to Anthropic and to METR — the latter of which described its own missing spend caps and its own agent handing over a key, which is a more useful disclosure than most companies manage.
We cap confidence at 95 percent. The least certain thing here is the variance proposition, which is an argument built on two incidents, and we have written it as a hypothesis on purpose.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=four-groups-named-the-attack-this-year-nobody-has-named-the-defense-here-is-the-credit-map-and-tw




Comments