Most attacks show up in your logs first. This one can show up on the invoice first.

On November 2, Google Threat Intelligence Group and Mandiant published a report on LLMjacking: attackers hijack an organization’s access to large language models, run huge volumes of requests through it, and leave the victim to pay. In incidents Mandiant handled this year, fraudulent charges went past $100,000 in a single day, and some organizations reached $1 million in total before the access was cut off.

The attackers don’t need to steal data or encrypt anything. They need one working key, and time before anyone notices.

For MSPs, the question isn’t whether your clients use AI. They do, or they will soon. The question is whether anyone is tracking the keys, accounts and spending that came with it.

What Google and Mandiant found

The report draws on several 2026 incidents across different cloud and AI providers. The victims were in financial services, retail, technology and transportation, in North America, South America and Asia Pacific, according to Google’s write-up. Here is what the researchers describe:

• It’s fast. Cryptojacking slowly eats compute. LLMjacking “can generate large spikes in fraudulent cloud charges in a matter of hours,” Google says. In one case, a single actor made more than 500,000 API calls in under eight hours.

• It’s a business. Google describes a split between the people who break in and the operators of “LLM mixers,” services that pool stolen access and resell it to paying subscribers. One service, Jet Night, sold an “unlimited” plan for about $60 a month and passed nearly $1 million in token costs on to one victim organization. GTIG believes the service can only turn a profit at those prices because it runs on stolen keys.

• The victim’s systems see nothing wrong. The provider logs the requests as normal usage from a credential it recognizes, and bills the victim for the tokens.

How the attackers got in

This part should feel familiar to MSPs. The most common entry point was not some exotic AI exploit. It was exposed or stolen cloud identity credentials: IAM credentials, service account keys, GitHub personal access tokens and active session tokens.

The incidents Google describes include:

• A misconfigured service account key that gave an attacker a foothold in a cloud instance, which they then used to grant themselves access to an LLM API.

• A fake “join our LLM users” portal that tricked users into pasting a raw token payload. That let the attacker get around passwords and MFA.

• AI API keys collected from public GitHub repositories. The attacker tested them with single-token requests (max_tokens=1) so the checks stayed too small to set off volume alerts.

• Publicly exposed self-hosted model servers, such as Ollama endpoints, that attackers probed so they could run their own models.

Two details matter for anyone cleaning up afterward. First, attackers persisted by creating new IAM and service accounts, including backdoor accounts disguised as “billing optimization” utilities. Second, in several incidents the AI services weren’t even switched on when the attacker arrived. The attacker turned them on.

In other words, a client that doesn’t use cloud AI at all can still get a cloud AI bill.

Why this is an MSP problem

Clients are moving fast with AI, and much of it happens outside IT. A marketing manager creates an OpenAI key for a plugin. A developer contractor hard-codes a key into a script and pushes it to GitHub. Someone turns on a generative AI service in a cloud project “just to try it.” Each of those creates a credential nobody has written down.

Three things make this fit MSP work closely:

1. It’s an identity problem first. Google’s own recommendations start with identity and access management and supply chain security. That’s work MSPs already do for Microsoft 365 and cloud tenants.

2. The damage is financial, and it arrives quickly. A client that loses $100,000 in a day will want to know who was supposed to be watching. If AI spending isn’t in your scope, now is the time to say so in writing, or add it.

3. Many default budget settings only send alerts. This is the detail most worth passing on to clients, and it’s covered in the next section.

Alerts are not caps

Many clients believe that because they “set a budget,” they’re protected. Often they aren’t.

• Google Cloud: Google’s documentation states plainly that an alerts-only budget “doesn’t automatically cap Google Cloud or Google Maps Platform usage or spending.”

• AWS: AWS Budgets can run actions when a threshold is crossed, such as applying an IAM policy or a service control policy, but you have to set those up. AWS’s own builder guidance warns that budget data updates daily, which makes Budgets a monitoring tool, not a hard gate for a runaway workload.

• OpenAI: Monthly spend limits can watch spending without stopping requests. To actually stop traffic, someone has to turn on Enforce a hard limit at the organization or project level.

So the practical question for each client isn’t “Do you have a budget?” It’s “What happens to the requests when the budget is hit?” If the answer is “someone gets an email,” then at today’s attack speeds the bill may already be large by the time anyone reads it.

What MSPs should do now

Here is a sequence you can run across your client base, starting with the clients most likely to have AI keys lying around.

1. Find the AI footprint

For each client, list every place AI is being billed or called:

• AI provider accounts (OpenAI, Anthropic, Google AI Studio, others), along with who owns each one and which card or invoice pays for it

• Cloud AI services turned on in AWS, Azure or Google Cloud projects

• Self-hosted model servers, and whether any of them can be reached from the internet

• Third-party tools and plugins that hold a client-owned AI API key

Any account no one can explain counts as a finding. So does any AI service turned on in a cloud project that isn’t supposed to use AI.

2. Turn alerts into limits

Wherever the platform allows it, set a spending ceiling that actually stops traffic, plus earlier alert thresholds that go to a shared mailbox or ticket queue rather than one person.

• On OpenAI, set project-level spend limits and turn on hard enforcement. Use Model usage to limit which models a project can call.

• On AWS, attach a budget action that applies a deny policy to AI invocation for the relevant roles. Pair it with faster usage alarms, because billing data lags.

• On Google Cloud, use granular API quotas per model, as Google recommends. Don’t count on a budget alone to stop spending.

A hard cap will break a legitimate workflow if it’s set too low, so agree on the numbers with the client and write them down.

3. Scope every key

Google recommends restricting API keys to specific models, environments and usage limits, so that a stolen key for a cheap utility model can’t call an expensive frontier model. Give each environment or use case its own project and key. One shared organization key used by five tools makes the damage worse and the investigation harder.

4. Deny AI services by default

Google’s guidance is direct: “Deny all permissions that are not explicitly required, including access to Cloud LLM services.” If a cloud project has no business reason to call a model, it shouldn’t have the permission. That one change shuts down the “attacker turns on AI in a project that never used it” scenario.

5. Scan for leaked secrets

Turn on secret scanning wherever client code lives. On GitHub, secret scanning runs automatically for free on public repositories. For organization-owned private repositories, it requires GitHub Secret Protection on a Team or Enterprise Cloud plan. Move keys into a central secrets manager and rotate them on a schedule, so a leaked key has a short useful life.

6. Alert on the early signs

Google points to specific signals that show up before the big bill:

• AI services being turned on. Treat it as a critical security event when it isn’t authorized.

• Tiny validation requests, such as max_tokens=1 pings, which attackers use to test stolen keys.

• New service accounts, access keys or SSH keys, especially ones with innocent-sounding names.

• Attempts to view or turn off model invocation logging.

One catch for Google Cloud clients: AI inference calls are recorded in Data Access audit logs, which Google notes are disabled by default. If they aren’t on before an incident, the record you need won’t exist.

7. Require phishing-resistant MFA

The fake portal in Google’s report worked by stealing a session token, and another actor used federation tokens to generate fresh access keys and get around MFA requirements. Phishing-resistant MFA on cloud consoles, identity providers and developer platforms makes both of those harder.

If you suspect it’s already happening

Containment and cleanup are separate steps. Revoking the key the attacker used stops the immediate spending, but Google’s incidents show attackers routinely set up more ways back in: new IAM users, new service accounts and injected SSH keys. Before you call the client clean:

• Revoke and rotate the affected AI keys and any cloud credentials that could reach them.

• Review identity changes made during the incident window: new accounts, keys, role assignments and policy attachments.

• Check for AI services or GPU resources that were turned on in projects and regions the client doesn’t normally use.

• Contact the cloud or AI provider’s support team about the fraudulent charges as early as possible, with your timeline in hand.

Turning this into a service

AI cost and access governance fits naturally alongside the identity and cloud reviews MSPs already sell. It’s also easy for a business owner to understand: “Here is every place your company pays for AI, here’s who can use it, and here’s the most it can cost you this month.”

For each client, keep:

• An inventory of AI accounts, keys and cloud AI services, each with an owner and a business purpose

• The spending limits in place, and whether each one is an alert or an enforced cap

• Key scopes and rotation dates

• The alert rules for AI service activation and unusual usage

• A dated record of keys revoked and services shut off

That record is good security practice. It’s also the kind of evidence clients will increasingly need as insurers, auditors and their own customers start asking how they govern AI use. In a QBR, the before-and-after works well: “Last quarter you had six AI keys with no limits. Today you have three, each capped and owned.”

LLMjacking turns AI adoption into a billing risk. The fix isn’t to slow clients down. It’s to make sure every key has an owner, every account has a ceiling, and someone gets the alert before the invoice does.

Frequently asked questions

Q: What is LLMjacking?

A: LLMjacking is when attackers hijack an organization’s access to large language models, usually through stolen API keys or cloud credentials, and use it to run their own AI workloads while the victim pays. Google and Mandiant reported fraudulent charges over $100,000 in a single day and up to $1 million in total at some organizations in 2026.

Q: What is an LLM mixer?

A: An LLM mixer is an underground service that pools stolen AI access and resells it to subscribers at below-market prices. Google identified services including Jet Night, which offered an “unlimited” plan for about $60 a month and passed nearly $1 million in costs to one victim.

Q: Can a client be hit if it doesn’t use cloud AI services?

A: Yes. In several incidents Mandiant investigated, the AI services were not turned on at the time of compromise. The attackers used stolen cloud credentials to turn them on. Denying AI service permissions in projects that don’t need them removes that option.

Q: Does setting a budget stop the charges?

A: Often, no. On Google Cloud, an alerts-only budget doesn’t automatically cap spending. On OpenAI, a spend limit only stops requests if hard enforcement is turned on. On AWS, budgets need configured actions to do anything more than notify, and billing data can lag. Check what happens when each limit is reached, not just whether one exists.

Q: How do attackers get AI API keys?

A: According to Google, the most common route is exposed or stolen cloud identity credentials, such as service account keys, GitHub tokens and session tokens. Attackers also collect AI keys accidentally committed to public code repositories, and probe self-hosted model servers that were left open to the internet.

Q: What’s the first thing an MSP should do?

A: Inventory where each client pays for AI, then check whether each account has an enforced spending cap or only an alert. Those two steps show the biggest exposure fastest, and they set up the rest of the work: scoping keys, denying unneeded AI permissions, scanning for secrets and alerting on AI service activation.