Your AI API key is worth three things to an attacker

Two years ago, an API key for an AI service was a line on an invoice. Today it is an asset that entire criminal groups go after for its own sake. The report devotes a section to it: “Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups.” The sole objective. Not a by-product of an intrusion: its whole purpose.

The last word of that sentence deserves a closer look: devices. It is not only keys that are targeted, but also session tokens and the machines they live on. A good part of what the report describes is therefore not fixed by replacing a string in a vault: it is fixed by dealing with the machine.

Why a key is worth more than its balance #

Anthropic sums up the value of a stolen key in three words. It is the most useful formulation in the report for an IT manager: three benefits obtained in one go.

• Loot: a valid key or account can be resold on established markets. Thieves sell access to brokers, who supply fraudulent resale networks; these networks feed in newly stolen keys as they arrive and rotate through them until the quota runs out. Your key does not need to be interesting: it needs to be valid.
• Compute: the offensive workload runs at someone else's expense. A hacktivist campaign described later in the report ran for an entire month entirely on stolen keys: zero marginal cost.
• Cover: the activity is attributed to the key's legitimate owner. It is your company that shows up in the provider's logs, not the attacker.

The third is the one people underestimate, and the report makes it very concrete. The same hacktivist actor had written their own scanner, in Rust, to crawl public containers and validate the keys found in them. Once validated, a key joined a local proxy layer that rotated usage across the keys. The explicit aim: to blend its traffic into that of the legitimate owners. The key is not just there to pay the bill, it is there to wear someone else's clothes.

Affiliates of the ShinyHunters collective applied the same logic from the other end: once inside a victim, they switched their own attack workloads onto that victim's AI keys, and used them to attack other organisations for three weeks: a French retail chain compromised, a Web3 identity platform probed. In every documented case, the keys came from customer environments; Anthropic's systems were not compromised. The distinction matters: the risk sits with the key's user, not with the model vendor.

1.8 million apps decompiled to find secrets #

The harvesting chain is industrial. A French-speaking operator known under several aliases set up a pipeline spread across ten machines rented from a cloud provider. This pipeline bulk-downloaded 1.8 million distinct Android apps from several app stores, decompiled them, and ran them through a hard-coded secrets detector: an open-source tool, the very one security teams use to audit their own repositories.

Verified finds were sent in real time to a private chat channel organised into more than four hundred and seventy threads: one thread per type of secret detector, for more than a hundred types of source. In parallel, a second feed harvested organisation addresses from a public code platform and fed a pipe of stolen personal access tokens. The report is explicit about the yield: these two pipes supplied the initial access credentials for the majority of this operator's confirmed compromises. Not a new vulnerability. Secrets picked up off the floor.

The deposits the report lists #

The report calls the automated search for exposed tokens “at industrial scale” discovery. Its list of sources doubles as an audit checklist.

• Application binaries: decompiling a mobile app is a routine task, not an exploit.
• Code repositories and their integrations: the repository itself, but also the tokens that CI pipelines leave in it.
• Code executed in the browser: whatever your server sends to the visitor's machine can be read by the visitor.
• Poorly protected credential vaults: a vault with an over-broad access policy is a collection point.
• Container images: a key deleted in one layer is still present in the previous layer.
• Cloud instance metadata endpoints: readable from any application running on the machine, vulnerable ones included.
• Open storage: buckets left publicly readable for a test that has now been running for three years.
• AI agents deployed by the victim itself: the new item, covered in a section further down.

What happens to a key once it is found #

The report details the full life cycle of a stolen credential. Three of its stages concern AI keys directly, and explain why the classic reaction (“we revoked it, job done”) is not enough.

• Validate and qualify. Everything found is tested before use or resale: bulk validation of cloud keys, login oracles written for the occasion, live replay against production systems, scoring of market value, offline cracking of whatever resists. In practice: the time between the leak and the first use does not depend on luck. An exposed key is tried against your systems straight away.
• Mint lasting access. New credentials are created so that the operation survives your rotation: cloud API keys in the victim's accounts, developer keys on platforms, forged sessions and second-factor codes, network backdoors. In practice: revoking the key that leaked is not enough, you have to look for what has been created since.
• Monetise. Resale channels and key pools, direct financial theft, extortion over stolen data, bug bounty income on the side as a double agent, bulk data kept as leverage. In practice: even a key with no usage value has stock value. It will be sold, and replayed later by someone else.

The other stages (reconnaissance, expansion inside the victim, exfiltration channels, storing the loot) describe the intrusion itself. We cover them in detail tomorrow: they answer a different question, no longer “how do they get in” but “how fast”.

The fake reseller: “cheaper Claude” #

The second circuit targets end users directly rather than systems. Actors set up websites presenting themselves as intermediaries between several models, offering cut-price access to frontier models. Visitors were compromised in several ways; the most lasting was to get them to install a client application that imitated a popular development harness, Claude Code included, but was in fact a credential stealer. It collected all the credentials and session tokens on the machine, not just those linked to AI.

Here is the detail to remember. The report states that when the victim's account was eventually identified as compromised and reset, the stealer stayed in place and kept detecting every new session on the device to pass it on in turn. Rotation then does nothing except hand the attacker a fresh key. It is the textbook case of a correct procedure applied in the wrong order, which gives the illusion that the incident has been dealt with.

A Russian- and Ukrainian-speaking group, referenced as GTG-50021, did the same thing in a craftier way: its customers thought they were buying discounted Claude access; their traffic was in fact silently relayed to another model, while the reseller's tooling stole their credentials to sell them on to other fraudulent resellers. Neither cheaper nor Claude, and nothing to give it away: the response quality of a competing model does not set off any alarm.

AI access should be purchased only through authorized channels. A supposed discount that requires routing your traffic and credentials through an unknown intermediary puts your data and systems at considerable risk.

In SME terms: this circuit does not come in through the IT department's front door, it comes in through shadow IT. A developer who finds a subscription for fifteen euros instead of a hundred, a contractor who offers “their” shared access. And the compromised machine is precisely the one holding the repository tokens and the production keys.

Your integrations around AI are an attack surface #

This is the point most teams have not yet taken on board. The report mentions several actors who compromised intermediary services exposing model gateways: the component you install to route calls to several providers and centralise billing. The vector: prompt injection, to get the agent to exfiltrate the production API keys present in its container environment. The report ranks this kind of deployment among the common targets of opportunity, on a par with scanning for unpatched devices.

The mental shift to make: the vector is not a code flaw, it is the text the agent agrees to read. An agent that consults a web page, a ticket or a file submitted by a third party also reads the instructions slipped into it, and if it holds a production key, it can be talked into spitting it out.

GTG-50020: from hotel bookings to the AI supply chain #

The most explicit case is that of a financially motivated Russian-speaking actor who had previously operated against hotel booking and financial technology platforms. Its track record gives the calibre: around 26 gigabytes exfiltrated from a single victim, and a ransom demand (or a sale price on forums) of between 1.5 and 2.5 million dollars. This is not an amateur discovering AI, it is a professional changing sector.

It redirected exactly the same know-how towards the AI industry. By injecting malicious instructions into a vendor's automated evaluation sandbox (the plumbing that runs automatic tests on models), it got the sandbox to hand over the credentials it held, including production API keys for several providers. The report then notes the behaviour that sums up the section: as soon as it obtained a target's keys, the actor switched over to them automatically instead of its own, and continued its intrusions against the vendor and against unrelated targets, in parallel.

From the same infrastructure, it then attacked some thirty AI companies in about four days. The method says everything about the new economics: it found one attack path that worked, then repeated it against the thirty targets, adapting it at the margins. The tooling followed: one scope file per target launched a workflow delegated to parallel reconnaissance and exploitation agents, findings were re-tested to check that the access worked, merged into an incremental report, and the loop moved on to the next target. Alongside, a containerised open-source penetration testing platform ran worker agents testing injections, cross-site scripting and authentication bypasses without human supervision, with active exploitation allowed on production systems.

Its stated objective, pursued through more than a dozen different routes: access to an unreleased Claude model. The report is categorical, and it should be said as clearly as the rest: it never succeeded; every route failed. This is, the report writes, the clearest demonstration that the AI supply chain has become a deliberate criminal target, not collateral damage.

The section's conclusion is a sentence to pin above the IT department's coffee machine: treat AI keys and agent integrations as seriously as your production credentials, because attackers already do.

What we do, and what we recommend #

Nothing that follows is exotic. It is secrets hygiene, applied to a category of secret that many organisations have not yet put on their inventory.

1. Take inventory. Who holds an AI key, for what use, since when, with what scope? One key per use and per environment, never a “company” key shared by five projects: a shared key is a key nobody dares revoke any more.
2. Get keys out of the code. Environment variables injected at deployment or a secrets vault; never in the repository, never in an image, never in a mobile binary, never in a file served to the browser. A secret committed once stays in the Git history: removing it from the file is not enough, you have to revoke it.
3. Scan continuously. A secrets detector at pre-commit and in the CI pipeline, plus a periodic pass over published images: the same logic as our CVE monitoring of Docker images, applied to secrets. Attackers use the open-source tool you can plug in today.
4. Restrict the scope. A key limited to one model, one spending cap, one address range or one project loses most of its resale value. The report describes market scoring at validation time: a restricted key drops down the ranking.
5. Cap and monitor. Spending limit per key, alert when it is exceeded, weekly review of consumption. A stolen key first shows up on a usage curve that looks nothing like your line of work: a spike at night, at the weekend, or machine-like regularity.
6. Rotate, in the right order. Scheduled rotation (quarterly at the very least) and immediate rotation at the slightest doubt. But the credential stealer described above makes rotation pointless if the machine is compromised: it captures the next key. Deal with the machine first, then the key.
7. Buy only through official channels. No cut-price reseller, no third-party gateway “to save money”, no unofficial client on a development machine. This rule belongs in your IT policy, because shadow IT is what breaks it.
8. Treat your own agents as exposed components. Minimum scope for the secrets they hold, container isolation, no production key in the environment of an agent that consumes untrusted content, logging of outbound calls.
9. Write the leak procedure before you need it. Isolate the originating machine, revoke, look for what has been created since (extra keys, service accounts, enrolled devices), review ninety days of consumption, notify the provider. A procedure improvised on a Friday evening always forgets the second-to-last step.

And for processing where the question “where does my data go” matters more than raw capability, the alternative remains an open model hosted on your own infrastructure: no key to steal from a third party, no reseller in the loop. We will come back to this on 16 September.

Tomorrow: what happens after a credential is stolen, and why the time between first access and data theft is now counted in hours.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 September 2026): Cyber operations chapter, AI supply chain as target, loot, and attack compute section: loot, compute and cover, fake resellers, prompt injection on gateways.
• Same report, GTG-50014 section: harvesting pipeline (ten rented machines, 1.8 million apps decompiled) and the Discover, Validate/qualify, Mint/persist and Monetize stages of the attack life cycle.
• Same report, sections GTG-50020 (evaluation sandbox, some thirty AI companies in four days, objective never reached), GTG-50021 (fake reseller) and GTG-50029 (container scanner, key rotation behind a proxy).
• Our overview: Eight months of AI misuse, and the state of play that came before it: When agents attack.
• Frandroid, Anthropic publie 161 pages sur les détournements de Claude, et ça pique (Anthropic publishes 161 pages on Claude misuse, and it stings; 11 September 2026).