Your stolen API key is someone else's compute budget

Security·10 September 2026

A financially motivated actor with a background in hotel-booking fraud found an AI vendor's automated evaluation sandbox and injected instructions into it. The sandbox did what it was told and handed over the credentials in its environment — including production API keys for several model providers, belonging to that vendor's customers. Within about four days those keys were being used against more than thirty other AI companies.

That's one of seven case studies in Anthropic's September 2026 threat intelligence report, covering activity from December 2025 through August 2026. The report is worth reading in full. But if you only take one thing from it, take the section where Anthropic explains what a stolen AI credential is actually for now — because it isn't what it used to be.

Loot, compute, and cover

A stolen API key used to be one thing: unauthorized access to your account. The report lays out three simultaneous uses:

Loot. It has resale value in established markets. One group in the report ran a fake "discounted Claude access" reseller that silently proxied traffic to a different model while a harvester collected the credentials customers typed in — then sold those on to other proxy resellers.

Compute. The attacker's own workloads run at your expense. These campaigns are AI-driven end to end — parallel subagents doing reconnaissance, a loop that rewrites malware when a detection fires, thirteen standing collection agents on scheduled jobs — and all of that costs inference dollars. Your key is the budget line.

Cover. The activity is attributed to the credential's legitimate owner. That is you, in someone else's incident report.

Anthropic's phrasing is blunt: "Access to the uplift granted by AI is highly sought after by malicious actors and the broader criminal economy." The AI supply chain has become simultaneously a target, a source of loot, and the machinery attacks run on.

Five groups, one precondition

What's striking across the case studies isn't the intrusion techniques, which vary enormously. It's how uniform the credential step is.

• One group downloaded 1.8 million Android APKs, decompiled them, and ran TruffleHog across the lot looking for hardcoded secrets.
• Another wrote a Rust scanner that crawls public containers for exposed API keys, validates each one, then rotates usage through a local proxy layer.
• A third did batch cloud-key validation at scale and replayed live against production.
• A fourth escalated a single developer token to full administrative control of a cloud environment in about three hours, and pulled 2,100+ Azure AD token sets across 40-plus corporate tenants in roughly thirty-four.
• The report also describes malicious client applications spoofing Claude Code purely to harvest the credentials of anyone who installs them.

Different actors, different skill levels, different motives. Every one of them depends on the same precondition: a long-lived, reusable credential in plaintext, somewhere a process could read it. An APK. A container layer. A CI environment. An evaluation sandbox.

The awkward question for a secrets manager

Here is where we should be honest about our own category, because a vault is a deliberate concentration of exactly the loot these groups are collecting at industrial scale.

If you put every credential your company owns into one service, you've made two bets, and they're separable:

1. That the service can't be made to give them up — including by its own operators, its own staff, a subpoena, or an attacker who gets inside it.
2. That the plaintext never lands in the place the attacker actually broke into — the sandbox, the CI runner, the agent's process.

Most secrets managers ask you to take the first on trust. Encryption at rest, an HSM, a compliance report: the vendor holds the keys that open your data, and your protection is that they promise not to. That promise is exactly what the threat report keeps showing being bypassed — not through cryptanalysis, but by compromising something that legitimately held the plaintext.

What "we can't read them" actually buys you

seekrit's answer to the first bet is structural rather than procedural. Secrets are encrypted in your browser or your CLI, under a key we never receive. Every environment has its own data encryption key; that DEK is wrapped separately to each principal's public key, and the matching private key is either inside your service token or encrypted with a passphrase we never see. The full design is in the encryption model.

The practical consequence: there is no server-side switch that produces plaintext. Access is cryptographic, not a permission flag. An attacker who gets everything we store gets sc1. ciphertext and wrapped DEKs. So does a rogue employee, and so do we. That property is also what makes the fake-reseller attack uninteresting against us — a phishing page can harvest a seekrit credential, but the credential's value is bounded by the grants attached to it, and we are not sitting on a pile of readable secrets to be tricked into releasing.

One carve-out, because a post about vendor trust shouldn't bury it: pushing a value into a platform we can't inject into — Vercel, say — requires plaintext at a moment when no client of yours is running. Third-party sync is opt-in per environment, requires a key grant you create client-side, and shows you a decryption disclosure you have to acknowledge. If you never enable it, it never applies. It's the one place the boundary moves, and we'd rather say so on the marketing blog than in a footnote.

The second half: don't put plaintext where the intrusion is

The first bet is about us. The second one is about you, and it's the one the sandbox story turns on.

That evaluation sandbox was compromised by prompt injection — which nobody has solved, and which we are not claiming to solve. The question a design gets to answer is what the sandbox had to give up when it complied. It had production API keys in its environment, so it gave up production API keys.

The alternative is that the compromised process holds a placeholder — a string that names a credential without being one — and the substitution happens at the network boundary, outside anything the process can read:

  agent / sandbox ──▶  Authorization: Bearer {{seekrit:OPENAI_KEY}}
                              │   (everything it can read: this string)
                           proxy   ── substitutes, checks the allowlist, audits
                              ▼
                        api.openai.com   Authorization: Bearer sk-…

Run this way, the same attack yields a name. And the allowlist bounds the second half of the story too: those stolen keys were valuable because they worked against thirty other companies. A placeholder resolves toward the hosts, methods, and paths its policy names and nothing else, so it is worth nothing pointed anywhere new. The policy itself is signed in your browser and verified by the proxy against signers pinned in its own config — we serve those bytes but cannot forge them, which means we can't quietly widen where your credentials are allowed to go either.

Two smaller things the report makes an argument for. Audit by name, never by value, because "cover" means the first signal you get may be someone else's traffic wearing your identity, and you'll want to know which credential went where. And since three of these groups validate harvested keys in bulk before using them, that validation step is a detection surface — honey tokens are decoy credentials that unlock nothing and page you the moment anyone tries one.

What this doesn't fix

It doesn't stop the intrusion. The campaigns in this report start with device-code phishing, an XSS bug in a SaaS vendor, a WordPress race condition, stolen VPN appliance credentials. Nothing here prevents any of that.

It doesn't stop prompt injection, and it doesn't stop an agent from misusing access it legitimately holds. If the policy permits POST /v1/messages and the agent is talked into sending one, allowing that was the broker's job. The allowlist narrows the confused deputy; it doesn't dissolve it.

And it concentrates plaintext in the proxy process. That's a real trade — the mitigation is that it's a small program you run yourself, on your side of the boundary, rather than a large one with a plugin system.

What it does change is the yield. In every case study here, the attacker's reward for getting in was a reusable secret they could carry somewhere else. That is the part that's worth designing away.

Try it

npx -y @seekrit/cli proxy run --preset openai

Point HTTPS_PROXY at it, or put it in front of a base URL as a reverse proxy. The agent sends placeholders, allowlisted upstreams get real credentials, and everything else gets a 403. The agent proxy guide has the rest; if you'd rather inject into a process you control than proxy it, seekrit run does the same job for a command's environment.