Most write-ups of a cloud intrusion end with data. This one ends with a quota request.
In its AI Threat Tracker report of 8 September 2026, Google Threat Intelligence Group walks through an intrusion Mandiant investigated in April. The pattern has a name the industry settled on a while ago, LLMjacking, meaning the use of stolen cloud credentials to consume paid AI capacity while somebody else is billed. What is worth reading closely here is not the name. It is that the objective was compute, and that the attacker reached it without ever meeting a control that had anything to do with AI.
What the intrusion actually bought
Google's account of the sequence is unusually concrete, so it is worth following stage by stage.
The actor got in through an exposed GitHub Personal Access Token. From there they enabled Gemini Enterprise and provisioned a high-performance compute instance. They then created custom Docker repositories in Artifact Registry to build and stage container images for the LiteLLM API and the Manus agent framework, and deployed those images to publicly accessible Cloud Run services, exposed, in the report's words, "via IAM invoker bindings to allUsers", with firewall rules permitting proxy traffic. They created a rogue service account with Editor privileges and exported its authentication keys. Finally they used the Cloud Quotas API to request quota increases for NVIDIA RTX 6000 hardware and launched additional 48-vCPU compute instances to sustain the workloads.
Read that as a shopping list rather than a kill chain and it is clearer what happened. The attacker acquired, in order: an identity, a machine, a build pipeline, a public endpoint, a durable privileged identity, and then more machines. The last step is the point of the first five.
Each step is a cloud authorization decision. The AI layer is what the capacity was for, never what stood in the way.
Nothing in that chain was an AI control
Go back through the six steps and ask, at each one, what would have had to say no.
A token scope. An IAM binding. A permission to create service accounts. A quota approval. Every gate on that path is an ordinary cloud authorization decision, and every one of them was made correctly according to its own rules, by systems that had no idea they were provisioning an unauthorized inference service. There was no jailbreak, no prompt injection, no model-level guardrail in the story at all, because none was ever in the path.
This is the part worth internalizing if you are building AI infrastructure. A great deal of current security attention sits at the model boundary: what the model can be persuaded to say, what a tool description can smuggle in, whether a system prompt holds. Those are real problems, and we have written about several of them. They are also not what this intrusion touched. The controls that would have mattered here are the boring ones: token lifetime and scope, whether a binding to allUsers is allowed to exist, who can mint an Editor service account, whether a quota increase for GPU hardware is a routine approval or an event that pages someone.
We made a version of this argument about catalogs when a quote in a table name minted bucket-wide cloud credentials: once a component can hand out cloud credentials, its bugs stop being application bugs and become IAM bugs. The same inversion is happening around AI capacity. The blast radius of a leaked developer token is now measured partly in GPU hours.
LiteLLM appears as the attacker's tool
One detail deserves separating out, because it is easy to misread.
LiteLLM shows up in this report as infrastructure the attacker chose to deploy. They built container images for it, alongside the Manus agent framework, and stood the result up as a public endpoint. That is not a statement about a flaw in LiteLLM. It is a statement about what a routing layer is: a proxy that presents a uniform interface over many model providers and handles keys on the caller's behalf. Teams adopt that for cost control and provider flexibility. An attacker who has stolen a pile of credentials wants exactly the same properties, for exactly the same reasons.
So the routing layer sits at the centre of both the legitimate and the illegitimate architecture, and it is not the thing deciding whether either is allowed. A proxy multiplexes access. It does not adjudicate it. Treating the layer that routes calls as though it were the layer that authorizes them is a category error, and this intrusion is what the error looks like when someone else is holding the keys.
Google adds a supporting observation from May 2026: malicious open source packages that surreptitiously install LLM proxy services, letting threat actors route traffic to bypass regional access restrictions. Proxy infrastructure is being distributed as a payload now.
The economics explain the harvesting
Why is any of this worth an attacker's time? Google's answer is a price signal. Based on underground forum posts it tracks, average marketplace prices per AI account more than doubled in 2026, with buyer demand concentrating on Claude and Gemini credentials alongside rising demand for autonomous coding tools such as Cursor Pro and Devin.
Rising prices pull supply, and the supply side has industrialized to match. Google describes an exposed command and control server running a framework it dubbed "Recon", whose dashboard was organizing and validating over 23,800 harvested secrets in real time, cloud and AI API keys among them. It also reports a separate case in which a financially motivated actor used an AI coding chatbot, a prompt and a set of agent instructions to plan, build and execute a mass credential harvesting campaign in less than six hours.
The collection has moved onto developer machines specifically. In May 2026 Google observed ACRSTEALER controllers pushing file-grabber rules at the configuration stores of AI coding assistants, naming the secrets.json file of Cline and the config.yaml of Continue AI. Those files, as the report notes, can hold plaintext API keys and custom model routing endpoints, which is direct access to a victim's paid quotas and infrastructure. The credential that matters is no longer only in a cloud secrets manager. It is in a config file in a developer's home directory, written there by a tool that needed it to work.
What this means for anyone running an agent stack
Three things follow, and none of them is a model-layer fix.
Treat AI capacity as a billable asset with a theft model, the way you already treat cloud compute. Quota increases, new service accounts and public ingress bindings are the events that mattered in this incident, and they are all observable. Anomalous inference spend is a security signal, not just a finance one.
Treat AI assistant config files as credential stores, because attackers already do. They deserve the handling you give a .aws/credentials file, including short-lived tokens where the tool supports them.
And put the decision boundary somewhere an attacker holding valid credentials still has to pass. That is the durable lesson across this whole report, and it is the same one that runs through our argument that read-only access is not enough and through the clauses in our agent database access policy: enforcement has to sit in the path of the action, not in the reasoning of the thing taking it. The same report's supply chain findings make the point from the other direction, where a stolen build identity produced genuinely valid signatures.
Where Datapace sits in this
Datapace's concern is the production database rather than the model gateway, but the shape of the problem transfers directly, and it is the reason we argue for governed execution rather than well-behaved callers. An intruder holding a valid credential is indistinguishable, at the point of the call, from the engineer whose credential it was. The only thing that separates them is a control that evaluates the action itself: what is being asked for, against what, and whether that is permitted right now. Everything upstream of that, including the routing layer, is plumbing that will faithfully carry whatever it is handed.
The uncomfortable summary of Google's report is that the attackers in it did not need to be clever about AI. They needed to be competent about IAM, and the AI was the payout.
Sources
- Google Threat Intelligence Group, "GTIG AI Threat Tracker: From Prompting to Autonomy, The Evolution of Adversarial AI", 8 September 2026. cloud.google.com