LLMjacking: When Hackers Steal Your AI API Keys

A developer at a small startup in Mexico woke up one day to find their Google Gemini bill had gone from $180 a month to $82,000—in 48 hours. They hadn't built anything new. They hadn't gone viral. Someone had stolen their API key.

That story, which the developer shared on Reddit, is one of the more visceral illustrations of a threat that the security community is starting to take seriously: LLMjacking. The name is a bit awkward, but the mechanic is simple. Attackers steal credentials that grant access to AI services—API keys, mostly—and then use those credentials to run queries at scale, on someone else's dime. No ransomware. No data exfiltration. Just a bill that lands like a punch.

IBM's Security Intelligence podcast recently convened a panel of X-Force security researchers—Michelle Alvarez, Urban Marina, and Patrick Facel—to dig into what's driving this and what organizations should actually be doing about it. Their conversation surfaces something worth sitting with: this isn't a new category of attack so much as an old category with a new target.

It's Not Theft. It's Freeloading on Infrastructure.

To understand why LLMjacking is gaining traction, it helps to trace the lineage. Marina, an incident response consultant at X-Force, laid out the evolution clearly: in the early 2000s, compromised machines were used for sabotage or command-and-control. Then cryptocurrency mining emerged, and suddenly hijacked cloud infrastructure had direct monetary value—GPU cycles could be converted to money. LLMjacking is the next branch on that tree.

"Now you have opportunity to use cloud for mining because it's free," Marina said. "It's on top of someone else's cloud account or on top of their bill. And now it's opportunity to make money, but in the same time as well to use the API to basically do R&D, to do research, to build weapons."

That last part deserves emphasis, because the conversation around LLMjacking tends to anchor on the financial damage—and that's real—but there's a secondary effect that's arguably more significant. Frontier AI labs have been tightening access controls on their most capable models. Safety reviews, usage policies, vetting processes. A stolen API key is a backdoor around all of that. Whoever holds a legitimate key is, from the model's perspective, a legitimate user.

So the threat isn't just the invoice. It's that LLMjacking can serve as an access mechanism for actors who couldn't or wouldn't obtain credentials through normal channels—and who might be using those models to develop offensive tools, generate disinformation at scale, or probe other systems.

The Guardrail Problem

One detail from the IBM discussion that I find genuinely interesting: attackers are apparently moving fast enough to blow through spending caps before the platform can react. Usage limits exist. They just don't always work in time.

Alvarez drew the obvious analogy. "We saw this with credit card companies," she said. "Right now I get notified if there's something strange going on and I can say no, that wasn't me." The credit card industry took years—and a lot of fraud losses—to build those real-time anomaly detection systems. AI API providers are, by comparison, early in that learning curve.

There's an uncomfortable irony here. The same speed and scale that makes these AI services valuable is what makes the abuse so expensive so fast. You can burn through thousands of dollars of compute in the time it takes a billing alert to fire.

Facel, who leads adversary services at X-Force Red, reframed the API key question in a way that cuts through some of the noise. His approach when evaluating any stolen credential: what does this actually get me? A key that only calls a model and gets text back is one thing. A key that's woven into a larger application stack—connected to databases, internal systems, proprietary data—is something else entirely.

"If it's part of a larger application flow, you may be able to disclose other data or gain access to other underlying systems," Facel said. "It's all about understanding what is the key for, what does it do, and what does it get me access to that could further my goals as an attacker."

This is a point that tends to get lost when the conversation stays at the level of "don't let hackers run up your bill." API keys don't exist in isolation. In modern software development they're embedded in CI/CD pipelines, containerized services, third-party integrations. The key is a node in a graph, and the interesting question is what else is in that graph.

The Hygiene Gap

The defensive advice from the panel converges on a cluster of practices that are, frankly, not exotic. Marina's summary: don't accept cloud defaults, because cloud defaults are usually insecure. Keep secrets in secrets management systems—not in environment variables, not hardcoded in repos, and absolutely not in public GitHub, which apparently remains a common failure mode. Build automation into the pipeline so that security testing happens continuously rather than as a one-time gate.

Facel added something that I think is underappreciated: every time a developer ships a change, there should be some mechanism to ask whether that change has opened new exposure. "We often make assumptions about what we've exposed when we accomplish a particular task," he said. Developers move fast. They have broad access. That combination, without the right scaffolding, is how keys end up places they shouldn't be.

None of this is novel advice. It's the same conversation that's been happening around cloud security for a decade, rerun with a new category of credential. Which raises an honest question: if we already knew all this, why are there still developers learning about their stolen API keys from a $82,000 invoice?

Part of the answer is probably the speed at which AI tooling has been adopted. A developer who integrated a Gemini API into their side project eighteen months ago may not have been thinking in terms of enterprise credential management. The tooling was easy to set up. The security posture was an afterthought. That's not a character flaw—it's what happens when a new technology category moves faster than the security norms around it.

The credit card analogy is again useful here. Consumer credit fraud didn't get solved by lecturing cardholders about hygiene. It got solved when issuers built better detection systems and absorbed more of the risk. Whether AI providers will move in that direction—whether the liability calculus will shift—is an open question. The startup in Mexico presumably didn't have enterprise-tier fraud protection. They had a billing alert that came too late.

The Bigger Frame

Marina put a fine point on the stakes: "Imagine a $100K bill. It's sometimes equal with a bankruptcy." For a funded startup, that's a rough quarter. For a solo developer or a small team bootstrapping something real, it's potentially the end of the project.

Meanwhile, the companies providing these services are generally not absorbing these losses. The terms of service tend to be clear: you're responsible for your credentials. Which is a reasonable position, up to a point. But as LLMjacking becomes more widespread and more sophisticated, that framing will face pressure—from customers, from regulators, and from the basic economics of trust.

The security practitioners on the IBM panel represent one end of the response: better hygiene, better tooling, shift-left security culture. That's necessary. Whether it's sufficient depends on how fast the threat evolves, and how much of the responsibility the platforms decide to share.

---

Marcus Chen-Ramirez is a senior technology correspondent at Buzzrag covering AI, software development, and the intersection of technology and society.