LLMjacking: stolen cloud and AI keys are running up million-dollar bills

What we know as of November 4, 2026, from the report published on November 2 by Google Threat Intelligence Group and Mandiant. Figures are theirs.

Cryptojacking taught a generation of cloud teams to watch for a slow, steady creep in compute bills. The attack Google calls LLMjacking doesn't creep. In incidents Mandiant responded to this year, attackers who got hold of a company's cloud or AI credentials ran up more than $100,000 in model charges in a single day, and at some organisations the total reached $1 million before access was revoked. The victims were in financial services, retail, technology and transportation, across North America, South America and Asia Pacific.

The money is the headline. The way in is the part that matters for anyone who shares credentials at work.

How do attackers get in?

Mostly with credentials. Google says the dominant initial access vector across its investigations was exposed or stolen cloud identity tokens: IAM credentials, service account keys, GitHub personal access tokens and active session tokens. One group compromised a cloud instance through a misconfigured service account key. Another combined a stolen GitHub token, used to read private repositories, with a vulnerability in a container. A third took over corporate users' cloud credentials and used federation tokens to mint fresh access keys, getting around the MFA on the original accounts.

Some went straight for AI API keys. One actor harvested corporate keys for AI services from public GitHub repositories, then checked which still worked with tiny single-token requests, small enough to slip past monitoring before the real abuse began.

The most instructive trick came from the group Google tracks as UNC6993. It ran a fake portal, dressed up as a way to join a group of AI users, that walked people through opening the genuine AI service and pasting a raw block of JSON from it back into the attacker's page. That block contained a live access token. Once pasted, it gave the attacker a working session with no password and no MFA prompt needed.

What do they do with the access?

They turn it into a service. Attackers switched on managed AI platforms in the victim's cloud projects, created extra API keys, signed accounts up to pay-as-you-go agreements on premium models, and ran high-volume inference. Some hosted their own proxy endpoints on the victim's infrastructure. Increasingly, Google says, the access is resold through "LLM mixers": gateways that pool stolen credentials and sell cheap access to underground customers. One such service, Jet Night, offered an "unlimited" plan for about $60 a month; in one incident, an actor powering it made more than 500,000 API calls in under eight hours, passing nearly a million dollars in token costs to the victim.

Once inside, the attackers did what credential thieves always do: they looked for more credentials. Google describes repository reconnaissance to find hardcoded secrets, and abuse of token-creation privileges to pull infrastructure credentials, database passwords and third-party API keys from a cloud secret manager.

Why does this matter if you don't run AI in production?

Because an AI API key has quietly become one of the most valuable credentials a team holds, and it is often handled the most casually. Keys get created by individual developers trying something out, pasted into a .env file or a notebook, shared in a chat thread so a colleague can test the same prompt, and committed to a repository that later goes public. A cloud key with permission to enable AI services is worth even more, because it can create the AI keys itself. In practice, both behave like a company credit card with no limit attached.

The UNC6993 portal is also a reminder that a token is a credential. Most people know not to type their password into an unfamiliar page; far fewer would hesitate before pasting a block of JSON that a friendly-looking guide told them to copy.

What should you do?

Google's guidance is long and specific, and most of it comes down to a few habits.

Treat AI and cloud API keys like production credentials. Scope each key to the models, environments and usage it needs, so that a leaked key for a basic model can't call an expensive one, and give each person or project its own key so you can revoke one without breaking the rest. Put budgets and quotas on AI services, and treat the sudden enabling of an AI service in a cloud project you didn't expect to use as a security event, not a billing curiosity. Rotate keys through a secrets manager so leaked ones expire. Scan repositories for keys, including their history. Watch API logs for the tiny validation requests that precede abuse. And never paste a token, a JSON payload or a key into a page because a guide told you to.

When you do need to hand an API key to a colleague or contractor, send it in an encrypted link that expires rather than in the chat thread where the next stolen session will find it. Our guide to sharing an API key securely covers scoping and rotation in detail, sharing .env files with your team covers keeping keys out of code, and our breakdown of the Gitee repository scan shows how many working AI keys sit in public code at any given moment.

---

Sources (checked on November 4, 2026):
Google Threat Intelligence Group and Mandiant: The rise of LLMjacking (November 2, 2026)

Product names are trademarks of their respective owners. CredenShare is not affiliated with them.