Your Claude API Key Is Now Three Things to an Attacker: Loot, Compute, and Cover
What Anthropic's September 2026 threat report says about stolen model credentials, and the key settings that actually shrink the damage
Somewhere in Anthropic's September 2026 threat intelligence report, past the state espionage case studies, there is a three-item list that reads like a product spec. Operators who obtain AI credentials, the report says, get three things at once. Loot, because stolen keys and accounts have resale value in established markets. Compute, because their attack workloads run at someone else's expense. And cover, because the activity is attributed to the credential's legitimate owner.
Read that third item twice. It is the one that changes what kind of problem a leaked key is.
If a model API key leaks, the reflex is to think about the bill: a usage spike, a surprise invoice, an awkward conversation with finance. That framing is comfortable because it makes the incident bounded and financial. What Anthropic describes is different. The key is a name your organization owns, and an attacker holding it is operating under your name. The traffic looks like yours. The logs say it was you. When someone downstream reconstructs what happened, the reconstruction points at you.
Anthropic reports that access to AI, in the form of compromised API keys, session tokens, and devices, "has increasingly become the sole objective of multiple criminal groups." Not a bonus found during an intrusion. The objective.
The specific plays, not the general warning
Generic security advice is easy to nod at and ignore. What makes this report useful is that it names the mechanics.
One group stood up websites posing as intermediary services offering discounted access to frontier models, then shipped client applications that spoofed popular agent harnesses, Claude Code among them. Those applications were credential harvesters. The important detail is what happened next: because a victim's compromised key would eventually be flagged and reset, the harvester kept running, watching for any new session on the device and sending each one back. The theft was not an event, it was a subscription.
GTG-50021, a Russian and Ukrainian speaking group with one operator using the handle "kl1zy," ran a reseller business selling cheap Claude access that was, per the report, "neither cheap nor actually Claude." Buyers' traffic was silently proxied to a different model while the reseller's tooling stole their Anthropic credentials and sold those onward to other proxy resellers.
Then the one that should worry anyone who has stood up an LLM gateway. Multiple actors compromised AI wrapper services by attacking their LiteLLM deployments, using prompt injection to exfiltrate the production API keys held in the services' cloud-hosted container environments. The attack surface was not the model. It was the thing sitting in front of the model, holding every key.
And the economics land where you would expect. A hacktivist campaign described elsewhere in the report ran for a month entirely on stolen API keys. ShinyHunters affiliates, on finding a victim's AI keys during an intrusion, moved their own attack workloads onto them. Another group, after compromising an AI vendor's evaluation sandbox, took its production keys first.
The report's own summary of where this leaves you is unusually direct for a vendor document: "AI API keys and session tokens are targets; the integrations customers build around AI such as sandboxes, proxies, and resellers are part of the attack surface."
The gateway you installed to control model spend is now the highest-value single object in your stack. It was sold to you as a cost control. It is a credential concentrator.
Why rotation is the wrong primary answer
The instinct is rotation: rotate more often, and a stolen key expires faster.
Rotation helps, and it keeps you on the same treadmill, because the thing being stolen still exists. Every rotation produces a new long-lived secret that has to reach every workload that needs it, which means an environment variable, a CI secret, a container image, or a .env file somebody eventually commits. Anthropic names this as the most common source feeding fraudulent resellers: legitimate customers who exposed keys in "products, applications and public code such as GitHub, mobile application install files, Docker containers, websites, and chatbots."
The control that actually changes the shape of the problem is the one that deletes the object. Anthropic's own authentication documentation describes Workload Identity Federation in a sentence worth quoting because of how plainly it states the point: "There is no sk-ant-api... string to mint, distribute, or rotate."
Under federation, a workload authenticates with a short-lived identity token from an identity provider you already trust, exchanges it at POST /v1/oauth/token for a short-lived Claude API access token, and the SDK refreshes that token before it expires. Supported issuers include AWS IAM, Google Cloud, and any standards-compliant OIDC issuer, which covers GitHub Actions, Kubernetes service accounts, SPIFFE, Microsoft Entra ID, and Okta. Nothing static sits in the environment for a harvester to find.
Anthropic then does something I want to give credit for, because most vendors do not. The same page limits its own claim: federation "does not, on its own, guarantee end-to-end security: the trust chain is only as strong as your identity provider's configuration, and a long-lived secret one hop upstream (for example, a static cloud credential that can mint IdP tokens) can still undermine it." That is the correct caveat, and it means moving to federation is a relocation of trust rather than an elimination of it. You should still want the relocation, because your identity provider probably already has IP allowlists, MFA, and audit logging that your .env file does not.
Put this into practice
Here is the lowest-friction path, in the order that gets you the most reduction per minute spent.
Start by finding the keys that belong to nobody. Anthropic's docs describe three key types. A personal key acts as you, with your roles, and is archived when you are removed from the organization. A service account key acts as a service account your org manages. A workspace key, now labeled legacy, acts as "No one: it belongs to the workspace it was created in," and it keeps working "regardless of whether its creator leaves the organization." That last category is the one with no identity to revoke and no person who notices when it goes missing. Migrating those is the single highest-value hour in this whole list.
Then look at the asymmetry nobody warns you about. An API key scoped to one workspace only works in that workspace and can omit the workspace header. Fine. But the docs also state that the Admin API "accepts a personal key or service account key only if the key isn't scoped to a specific workspace." So the credential powerful enough to enumerate and disable your other credentials is, by design, the one that is not workspace-scoped. That is your crown jewel, and it should not live anywhere a workload can read it.
Set expirations at creation, because you cannot set them later. The Console offers presets of 3 hours, 1 day, 7 days, or 30 days, a custom duration, or Never. The constraint to internalize: "expiration is set at creation time and cannot be changed afterward." A key you created with Never is a key that will be Never forever. Also worth knowing before you pick a short lifetime: Anthropic emails the creator 7 days ahead for keys with a lifetime of at least 14 days and 1 day ahead for at least 7 days, and "keys with shorter lifetimes expire without a warning email." A 3-hour key will die silently in production at 2 a.m.
Learn the difference between Disable and Delete before the incident, not during it. On the API keys page, Disable is reversible and the Admin API reports the key's status as inactive, with Re-enable returning it to active. Delete is permanent, archiving the key so it still appears in List API Keys with status: "archived". During an incident you want Disable first, because a reversible action lets you contain now and diagnose after.
Run one audit query, on a schedule. The Admin API's List API Keys endpoint returns each key's expires_at, its principal (a user_actor, a service_account_actor, or null for a workspace key), and a scope object that is either {"type": "workspace", ...} or {"type": "organization"}. A principal of null is a legacy workspace key. An expires_at of null is a key with no expiration. Those two fields, crossed, give you your entire problem list in one response. Note one trap in the same docs: keys without a workspace scope "aren't returned under any workspace_id filter," so an audit that iterates workspace by workspace will miss precisely the organization-scoped keys you care most about.
Move production workloads to federation, starting with CI. CI is the best first target because it already has a platform-issued identity, it is where static secrets accumulate fastest, and nobody is going to be inconvenienced by the change. GitHub Actions and Kubernetes service accounts are both supported issuers. Setup is three resources in the Console: a service account, a federation issuer, and a federation rule.
Treat every intermediary as a decision. The report's guidance here needs no translation: AI access "should be purchased only through authorized channels," and "an alleged discount that requires routing traffic and credentials through an unknown intermediary introduces tremendous risk." If someone is selling you frontier access below list price and the mechanism is a proxy you do not control, you have found the business model in case study GTG-50021.
Honest limitations
This is one vendor's report about misuse of its own product, and its incentives are visible. Anthropic benefits from a narrative where the danger sits in stolen keys and unauthorized resellers rather than in what its models can be asked to do directly, and the report's advice conveniently routes you back to buying through official channels. That does not make the case studies false, but it should shape how you read the emphasis.
The report also gives no base rates. We learn that multiple groups target credentials and that one campaign ran a month on stolen keys, but not what fraction of accounts are affected, how a compromise is typically detected, or how long the median compromise lasts before it is caught. Without denominators you cannot size your own risk, only recognize its shape.
I could not read the whole report this session. The cyber operations and influence operations sections were retrievable; the surveillance, biological misuse, and illicit distillation sections were not reached, so nothing here characterizes them.
The practical advice is Anthropic-specific in its details. The key types, the expires_at and principal fields, and the federation endpoint are all Claude Platform mechanics. The pattern generalizes to any model provider, but the field names do not, and I have not verified equivalent controls on OpenAI, Google, or Bedrock. Check yours rather than assuming symmetry.
Finally, federation has a real cost I glossed. It requires an identity provider configured correctly, and it moves your failure mode from "key leaked" to "issuer misconfigured," which is harder to detect and much harder to explain to an auditor. If your organization does not already run an OIDC issuer it trusts, short expirations plus a secrets manager plus that one audit query is a defensible stopping point.
What to do with this
The useful shift is smaller than a project. It is deciding to stop thinking of a model API key as a payment instrument and start thinking of it as an identity, because that is how it is being used by people who have yours.
Run the audit query. Look at how many of your keys have a principal of null and an expires_at of null. That number is the honest measure of how much of your organization's name is currently sitting in a credential nobody owns. Whatever you decide to do about it, you will at least know the number, which is more than most teams reading this report today can say.
Sources: Anthropic, Detecting and countering misuse of AI: September 2026; Claude Platform, Authentication; Claude Platform, Admin API.
Medium metadata
- Title: Your Claude API Key Is Now Three Things to an Attacker: Loot, Compute, and Cover
- Subtitle: What Anthropic's September 2026 threat report says about stolen model credentials, and the key settings that actually shrink the damage
- Tags: AI Security, API Keys, Anthropic, AI Agents, DevOps
- Suggested kicker image: a single physical key resting on a server rack rail, shot close and hard-lit, no logos
- Canonical: import from the fervorai.dev URL