# Stolen API keys and AI distillation campaigns

URL: https://infro.io/blog/stolen-api-keys-distillation-campaigns
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> Distillation operators value stolen API keys because a key from a real customer comes with a verified identity, a working payment method, the account's rate limits and someone else's name on the traffic. Anthropic's September 2026 report says proxy services behind distillation campaigns often use stolen API credentials of legitimate companies or individuals. For the key's owner the result is an unexpected bill, a possible account suspension and terms-of-service exposure. The controls that work are provider-side: scoped keys, provider spend limits, usage monitoring by key and fast revocation.

Key takeaways:
- Anthropic's September 2026 report says the proxy services behind distillation campaigns often use stolen API credentials belonging to legitimate companies or individuals.
- A stolen key carries a verified identity, a payment method, the account's limits, and cover: the traffic is attributed to the key's owner.
- The owner pays: the provider bills the account, may suspend it for abuse, and the traffic breaches the provider's terms under the owner's name.
- A key stolen from anywhere can be used directly against the provider, so the controls that bound the damage are provider-side: scoping, spend limits, usage by key and revocation.
- Treat every AI key as a production credential with resale value, and keep a written list of every tool that stores one.

**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](https://infro.io/blog/what-is-ai-distillation-attack).

## 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 individuals[1]. 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 exhausted[1].
- **Anthropic, October 2026.** Proxy networks control hundreds of thousands of fraudulent accounts, created with false identities and stolen payment details[2].
- **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 keys[3].
- **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 linked[4], and its email to them said provider keys saved in workspaces may have been exposed[5]. OpenCode has not said how the attack and the keys are connected, and nothing here assumes a mechanism. The [OpenCode incident write-up](https://infro.io/blog/opencode-console-breach-what-happened) 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 them[1]. From the key owner's side, the consequences are the same. The wider pattern has a name, [LLMjacking](https://infro.io/blog/what-is-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 owner[1]. 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 abused[6] | 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 indicator[3] | 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 spot[6]. A stolen key does that by default.

## Where stolen keys come from

Anthropic's September report describes a supply chain rather than a single technique[1]:

- **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](https://infro.io/blog/ai-api-keys-github-secret-scanning), [keys in front-end and mobile apps](https://infro.io/blog/ai-api-keys-frontend-mobile-apps), [secrets exposed to coding agents](https://infro.io/blog/ai-coding-agents-secrets-exposure), and [how third-party AI tools store your keys](https://infro.io/blog/third-party-ai-tools-key-storage).

## 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 extraction[7]. 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 amounts[4]. OpenCode's message to affected users mentioned possible reimbursement[4]. [Getting a bill from AI key theft adjusted](https://infro.io/blog/ai-api-key-theft-bill-refund) covers what to send the provider.

**Charges for blocked requests.** Anthropic says it now charges for requests its classifiers block before Claude responds[2]. 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 starting[2]. Some OpenCode users reported that Google suspended their projects for activity consistent with hijacked resources[4]. If the abused key shares an account or project with production, production stops too. See [what to do when a provider suspends your account](https://infro.io/blog/ai-provider-account-suspended-abuse).

**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 action[8]. 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](https://infro.io/blog/distillation-terms-of-service-model-outputs) goes further.

> **Example: A key with no ceiling, and a key with one**
> Two companies each lose a staging key on the same night. Company A's key sits in its main production project with no spend limit; by morning the provider shows thousands of dollars of reasoning-model traffic from networks it has never used, and an abuse review has paused the whole project, including production. Company B's key lives in a project of its own, inference only, with a small monthly spend limit at the provider. The same traffic stops at that limit within the hour, B's production project is untouched, and the on-call engineer revokes the key from an alert. The theft was identical; the scope and the ceiling decided the outcome.

## 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](https://infro.io/blog/cap-stolen-ai-key-damage) 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](https://infro.io/blog/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](https://infro.io/blog/signs-ai-api-key-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](https://infro.io/blog/ai-credential-inventory), and prefer [short-lived credentials](https://infro.io/blog/short-lived-credentials-ai-apis) 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](https://infro.io/blog/ai-api-proxy-transfer-stations-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.

## Questions

### Are stolen API keys used for AI distillation?

Anthropic says so. Its September 2026 threat report says the proxy services that labs route distillation traffic through create accounts with fake or stolen cards and stolen API keys, and often use stolen API credentials belonging to legitimate companies or individuals. The CISA advisory on distillation does not mention stolen keys; it describes fraudulent accounts, shared subscriptions and proxies.

### Who pays when a stolen key is used?

The provider bills the account the key belongs to. Whether a provider will adjust an invoice for usage you did not authorize is its decision, case by case; contact its support with the key, the dates and evidence that the traffic was not yours. Some OpenCode users reported overnight charges after its breach, and OpenCode's email mentioned possible reimbursement.

### Can a provider suspend my account because of a stolen key?

Yes. Providers act on the account that shows abusive patterns, and that account is yours. After the OpenCode breach, some users reported that Google suspended their projects for activity consistent with hijacked resources. Revoke the key quickly and contact the provider with your evidence.

### Does a gateway protect me if my provider key is stolen?

Not against direct use. A gateway's budgets, allowlists and IP restrictions apply to traffic that goes through it. Whoever holds a stolen provider key can call the provider directly. The limits that still apply are the provider's own: the key's scope, the project or workspace spend limit, and revocation.

## Sources

1. Countering misuse of AI: September 2026 — Anthropic. https://www.anthropic.com/threat-intelligence-report-september-2026 (accessed 2026-10-21)
2. Strengthening our defenses against distillation attacks — Anthropic. https://www.anthropic.com/research/distillation-defenses (accessed 2026-10-21)
3. China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies (AA26-251A) — CISA, NSA and FBI. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-251a (accessed 2026-10-21)
4. OpenCode hack exposes API keys amid AI distillation attacks — BleepingComputer. https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ (accessed 2026-10-21)
5. OpenCode Breach Could Affect OpenAI, Anthropic and Google — Infosecurity Magazine. https://www.infosecurity-magazine.com/news/opencode-breach-openai-anthropic/ (accessed 2026-10-21)
6. Detecting and preventing distillation attacks — Anthropic. https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks (accessed 2026-10-21)
7. LLM10:2025 Unbounded Consumption — OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ (accessed 2026-10-21)
8. GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use — Google Threat Intelligence Group. https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use (accessed 2026-10-21)