When a breach gets framed around a trendy new attack class, ask what actually leaked and how.
OpenCode, an AI coding agent, disclosed that stored external-provider API keys (Anthropic, OpenAI, Google) were exposed for 1.4% of Console users. The disclosure ties this to a large-scale distillation attack, run partly by AI agents, over at least 48 hours. Victims reported up to $1,700 in unauthorized charges, and at least some saw Google Cloud projects suspended over hijacked resources.
Two stories sewn together
Distillation attacks are a real thing. You hammer a model with queries, harvest the outputs, and use them to train a cheaper imitation. That's an abuse-of-service problem, and it's been discussed for a while.
Leaked API keys are the oldest story in the book. Stored credentials got out. That's it. That's the incident.
The summary says plainly that the root cause and the exact mechanism of the key exposure remain undisclosed. So the credential theft may be a completely conventional breach. No clever prompt injection, no model weirdness. Just keys that were stored somewhere they could be taken.
Maybe the distillation campaign and the key exposure are tightly linked. Maybe the attackers pulled keys as a side quest, or the two are related only by timing. We don't know. And the headline stitches them together as if we do.
The hype check
"AI agents ran part of the attack" is doing a lot of narrative work. It makes the incident sound novel and a little scary. But automation in attacks isn't new. Scripts and botnets have been grinding on targets around the clock forever. Swapping in agents for some of that labor is an evolution in tooling, not a new category of vulnerability.
What I'd want to know, and what the disclosure doesn't tell us: how were those keys stored? Encrypted at rest with keys the attacker couldn't reach, or sitting in a database one bad query away from exposure? Were they scoped, rotatable, rate-limited on the provider side? "Stored keys exposed" covers everything from a sophisticated compromise to an embarrassing oversight, and the difference matters enormously.
Who benefits from the AI-attack framing? Honestly, almost everyone except the users. A breach caused by a novel, agent-driven distillation campaign sounds like something no reasonable team could have prevented. A breach caused by plaintext-ish credential storage sounds like a design decision. The first one is much easier to put in a postmortem.
What's understated
The part that should get more attention is the blast radius, and it lands on people who did nothing wrong. Users handed a tool their Anthropic, OpenAI, and Google keys, and the damage showed up on their bills and their cloud accounts. Up to $1,700 in unauthorized charges is real money to an individual developer. Google Cloud suspending projects over hijacked resources is worse in some ways, because now your legitimate work is frozen while you sort it out.
This is the structural problem with the whole bring-your-own-key model for AI tooling. The product becomes a vault for credentials that carry direct financial liability, and those credentials usually have broad permissions because nobody wants to fiddle with scoping during setup. A coding agent that holds your keys is a high-value target by design. Attackers don't need to be clever about LLMs when the payoff for a boring database theft is free compute on someone else's card.
Implications
If you're a developer using tools like this, a few plain things apply. Use provider-side spending limits and alerts. Scope keys as narrowly as the provider allows. Rotate after any disclosure like this, even if you're in the 98.6% not named. And treat any third-party tool that stores your keys as a thing that will eventually leak, because the odds over time aren't in your favor.
If you're building these tools, the question is whether you need to hold the keys at all. Every design that keeps them server-side turns your database into a jackpot. I'm not saying there's always an alternative, but "we store them, carefully" is a weaker position than it used to be.
And for everyone reading AI security news: slow down on the attack-class labels until the mechanism is disclosed. A fancy name on the campaign doesn't tell you how the front door got opened.
The open question
If the key exposure turns out to be a garden-variety breach that happened to coincide with an AI-driven distillation run, how much of the "AI attack" framing was earned, and how much was a convenient way to make an old failure sound like a new threat?
— Cor, Skyblue Soft
Sources
AI-assisted draft or imaging, human-curated, reviewed and edited.
Top comments (1)
The "AI attack" framing is a perfect shield for standard AppSec negligence. Swapping out "botnet" for "AI agents" makes a boring credential leak sound like an unpreventable sci-fi movie, which conveniently distracts from the fact that the keys were likely just sitting in a database.
The structural trap of the BYOK model is the real story. Since a server-side agent fundamentally needs the raw key to execute tasks, how do you actually secure this architecture? Are builders moving toward short-lived ephemeral tokens proxied through the provider, or is running the agent entirely client-side the only truly safe path left?