Session inventory cannot explain token theft

Grant De Swardt watched his Claude Max allowance move from 45% used to 55% used while he said scheduled work was paused or complete, cloud execution was disabled and no local Claude Code task was active. TechCrunch reported that Anthropic later told him a compromised Claude session key had been used to mint unauthorized server-side Claude Code OAuth tokens.

That is one account-specific finding relayed through a TechCrunch interview, not a public Anthropic incident advisory or something I independently verified. It still exposes a precise control gap: a session inventory can show where an account is logged in, but it cannot show which authorization produced a metered request. Token-theft response needs the two joined by one opaque grant identifier.

The list stops at access

Anthropic's active-session page shows the device and browser, approximate IP-derived location, last update and current-session marker. A user can terminate an unfamiliar session remotely. That is useful inventory and a real containment lever.

The adjacent controls reveal the boundary. Anthropic says a Claude web session can persist for 28 days when inactive and refresh with activity. Its global logout instructions cover browsers, mobile devices and desktop applications, then direct users to a separate Settings > Claude Code screen to remove Claude Code authorization tokens.

Those surfaces answer what access remains. They do not answer what consumed the allowance before it was revoked. An active session is current state; an incident explanation is historical attribution.

The meter loses the authorization

The consumer subscription makes the gap harder to reason about because activity shares one allowance. Anthropic's Pro and Max guide says Claude and Claude Code count against the same usage limits, including supported IDEs. A rising percentage can therefore be legitimate chat, local coding, an IDE, a forgotten workload or unauthorized use. The aggregate does not distinguish them.

Anthropic already exposes a narrower version of the missing shape elsewhere. The Claude Console usage report can break API activity down by model, time and API key, with minute-level drill-down and CSV export. It cannot attribute cost to individual users, and API keys are not consumer OAuth grants. The point is not product equivalence. It is that key-level usage attribution is possible without displaying the secret itself.

This extends the archive's earlier revocation-before-reach rule. Inventory and a kill switch are necessary. When quota is already gone, they are not enough.

Join the grant to the spend

Give every consumer authorization a stable, opaque identifier and carry it into the metering event. The incident view then needs five things:

1. The grant ID, the login or session that created it, and the client or integration it represented.
2. Issued, first-used, last-used and revoked timestamps, plus coarse device and location changes.
3. Usage by grant, time window, model and product surface—not merely the account total.
4. Flags for a new client, new location or consumption during a user-marked idle interval.
5. Revocation acknowledgement and confirmation that no later metered event arrived from that grant.

Do not expose a reusable token in the interface or export. A fingerprint is enough to join the records. The useful question is not “show me the credential”; it is “show me which credential lineage spent this block of allowance”.

Two screens are not an incident control until they share an identifier.

Keep the symptom separate from the cause

A July 30 GitHub issue reported limits being consumed after three days without use. It included no logs or reproduction steps, carried a needs-info label and was closed as not planned. That is a first-person symptom report, not proof of token theft or a platform-wide defect.

The same visible symptom could come from a reporting error, delayed metering, a cloud task the user forgot or a stolen authorization. A per-grant ledger matters because it separates those explanations instead of assuming the most alarming one.

For this historical repair, I compared the reported incident with Anthropic's session, authorization and usage documentation. I did not access an affected account, inspect local telemetry, reproduce the compromise, validate the reported warning emails or test token revocation. TechCrunch's account describes a real support response for one subscriber; it does not establish prevalence or a common entry path.

Global logout is containment. Session inventory is scope. Neither is attribution.

Inventory tells you what can authenticate. Only a meter joined to the authorization can explain what spent the quota.