Why do distillation operators want stolen API keys? Because a key taken from a real customer arrives with everything a fraudulent account has to fake: a verified identity, a working payment method, the account's rate limits, and someone else's name on every request. Anthropic's September 2026 threat report says the proxy services that labs use for distillation often rely on "stolen API credentials belonging to legitimate companies or individuals"1. For the owner of the key, the outcome is someone else's extraction traffic on their bill, and possibly their account suspended for it.
This guide explains what providers have said about stolen keys in these campaigns, why a stolen key is worth more than a fake account, what it costs the victim, and which controls bound the damage. For the technique itself, see what a distillation attack is.
What the providers have said about stolen keys
The public record is specific about some things and silent about others.
- Anthropic, September 2026. Labs generally reach Claude through proxy services known as transfer stations, which create thousands of accounts using false identities, fake or stolen cards and stolen API keys, and often use stolen credentials of legitimate companies or individuals1. Elsewhere in the same report, Anthropic describes criminal groups whose sole aim is AI access in the form of compromised keys and session tokens, sold through brokers into fraudulent AI reseller networks that rotate in new stolen keys until each one's usage is exhausted1.
- Anthropic, October 2026. Proxy networks control hundreds of thousands of fraudulent accounts, created with false identities and stolen payment details2.
- CISA, NSA and FBI, September 2026. Advisory AA26-251A describes fraudulent accounts, bulk-bought subscriptions shared across teams, aggregators and gray-market proxies. It does not mention stolen API keys3.
- OpenCode, October 2026. OpenCode said it had a security breach "related to a large-scale distillation attack" affecting 1.4% of its Console users, those with external providers linked4, and its email to them said provider keys saved in workspaces may have been exposed5. OpenCode has not said how the attack and the keys are connected, and nothing here assumes a mechanism. The OpenCode incident write-up keeps to what is confirmed.
Not every stolen key ends up in a distillation pipeline. Anthropic's report also describes stolen keys used to run attack workloads: a hacktivist campaign that ran for a month entirely on stolen API keys, and intruders who switched their own work onto a victim's keys once they found them1. From the key owner's side, the consequences are the same. The wider pattern has a name, LLMjacking.
Why a stolen key beats a fraudulent account
Anthropic sums up what an operator gains from AI credentials in three words: loot, because keys and accounts have resale value; compute, because the workload runs at someone else's expense; and cover, because the activity is attributed to the credential's legitimate owner1. Set against a fraudulent account, the difference looks like this.
| What an operator needs | Fraudulent account | Stolen key from a real customer |
|---|---|---|
| Identity that passes checks | Must be faked; Anthropic says it has tightened verification for the account types most often abused6 | Already verified: it is the victim's account |
| Payment | A fake or stolen card, which can fail or be charged back | The victim's card or invoice, which keeps paying |
| Rate limits | Those of a new account | Whatever limits the victim's account has |
| Attribution | Leads to a throwaway identity, eventually to the operator | Leads to the victim |
| Blending in | Stands out as new and busy from day one, a pattern the advisory lists as an indicator3 | Mixes with the victim's normal traffic |
| Regional access | Must evade restrictions | Inherits the victim's region; our inference from the advisory's emphasis on restriction evasion |
Anthropic's February post adds that proxy networks already mix distillation traffic with unrelated customer requests to make it harder to spot6. A stolen key does that by default.
Where stolen keys come from
Anthropic's September report describes a supply chain rather than a single technique1:
- Secrets left in code and builds. One operator mass-downloaded 1.8 million Android app packages and scanned them for hardcoded secrets; another built a scanner for exposed keys in public containers and rotated the valid ones through a proxy layer to blend in with the legitimate owner's traffic.
- Vendors that hold your keys. In one case a target's AI keys were taken from its enterprise software vendors; in another, an attacker made an AI vendor's evaluation sandbox hand over the credentials it held, production keys first.
- Fake AI services. Sites posing as intermediaries for many AI models distributed malicious clients, some spoofing coding harnesses such as Claude Code, that harvested every credential and session token on the victim's machine and kept collecting new ones after the victim rotated.
Each route has its own prevention guide: keys in GitHub and secret scanning, keys in front-end and mobile apps, secrets exposed to coding agents, and how third-party AI tools store your keys.
What a hijacked key costs its owner
The bill. The provider bills the account the key belongs to. Distillation is high-volume, around-the-clock work, and OWASP lists denial of wallet, cost-driven abuse of pay-per-use inference, under the same LLM10:2025 entry as model extraction7. After the OpenCode breach, BleepingComputer reported users describing unauthorized charges from several hundred US dollars to more than $1,700 overnight; those are user reports, not verified amounts4. OpenCode's message to affected users mentioned possible reimbursement4. Getting a bill from AI key theft adjusted covers what to send the provider.
Charges for blocked requests. Anthropic says it now charges for requests its classifiers block before Claude responds2. Our inference: if distillation requests on a stolen key are blocked, the key's owner can still be charged for them.
Suspension. Providers act on the account that shows the pattern. Anthropic reports banning tens of thousands of accounts, often within two hours of a campaign starting2. Some OpenCode users reported that Google suspended their projects for activity consistent with hijacked resources4. If the abused key shares an account or project with production, production stops too. See what to do when a provider suspends your account.
Terms-of-service exposure. Using a model's outputs to build a competing model breaches provider terms; Google's threat report says distillation from Gemini without permission violates its terms and may lead to takedowns and legal action8. The traffic on a stolen key is in your name. You will want evidence that it was not yours: request logs for the period, the networks you use, and the date the key left your control. Distillation and terms of service goes further.
Controls that bound the damage
A stolen provider key can be used directly against the provider, from anywhere, so the controls that matter most sit at the provider. Capping the damage from a stolen AI key goes deeper.
- One key per workload, one project or workspace per key. Scope keys to inference, and keep staging, tools and production in separate projects so one theft cannot suspend everything.
- Provider spend limits on every project or workspace. They are the only ceiling that applies to direct use of a stolen key. Provider spend limits compared lists what each provider offers.
- Usage by key, read daily. Compare the provider's usage per key with what your systems sent; traffic you did not send is the signal. Signs an AI API key is being abused lists the patterns.
- Minimize where provider keys live. Every tool, vendor and laptop that stores a key is a place it can be stolen from. Keep an inventory of AI credentials, and prefer short-lived credentials where the provider supports them.
- Rehearse revocation. Know who can revoke each key at the provider, and how long replacing it takes.
- Buy access only from providers or authorized channels. Proxy services that sell access at a fraction of the provider's price are, in Anthropic's account, where stolen keys are spent. See AI API proxy risks.
How INFRO handles stolen-key risk
INFRO stores the provider keys customers connect, which makes it one of the places a key can be stolen from, and it should be judged with the same questions as any other tool. Provider keys are encrypted with AES-256-GCM under a key held as a secret outside the database, bound to the organization and connection, and never shown again after saving; the console shows the last four characters. Applications call INFRO with their own gateway keys, stored only as a SHA-256 digest, which can be limited to chosen providers, one environment and chosen IP ranges, refused with 403 ip_not_allowed before any provider call, set to expire and rotated with an overlap window. Budgets per organization, project, member and key refuse with 402 before the provider is called, and spend alerts flag a day that departs from a scope's usual day.
On the Business plan, reconciliation compares INFRO's estimates with OpenAI's and Anthropic's own cost reports each day; with usage access on, it reads token counts by provider key and shows traffic on your account that did not go through INFRO. Without usage access it reports "not checked".
The limit matters more here than anywhere. INFRO's controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from INFRO, can be used directly against the provider, and no INFRO budget, allowlist or IP restriction applies to that traffic. The backstops are the provider's: a narrowly scoped key, a provider spend limit, revocation at the provider and the provider's usage reports. Set them up whether or not you use a gateway.
Summary
Distillation campaigns need access at scale, and a stolen key from a real company is the most convenient access there is: verified, paid for, attributed to someone else. Anthropic has said plainly that such keys are part of the supply. The owner pays in bills, suspensions and explanations. Scope each key to one workload, cap it at the provider, read usage by key, and keep the list of places your keys live short.