Google Warns of Hackers Hijacking Cloud Accounts for AI

An exposed GitHub personal access token was all an attacker needed to get into a company's Google Cloud account in April. What came next, according to Google's Mandiant incident responders, was a full AI infrastructure build: GPU servers, AI agent software and requests for higher GPU quotas. All of it ran on the victim's account.

Google Threat Intelligence Group (GTIG) published the case on September 8 as an example of what it calls LLM-jacking, where criminals hijack a cloud account to run AI workloads at the owner's expense. GTIG says a growing number of intrusions fit the pattern. It did not name the victim, say how long the attacker had access, or put a figure on the bill.

Why steal AI access at all

The term borrows from cryptojacking, where attackers hijack someone else's computing power to mine coins. LLM-jacking swaps the coins for AI: the stolen power runs models and agents instead. Google's explanation is cost. Its report says the price of premium model access and high-performance computing is one of the main barriers for criminals who want to use AI at scale, and stealing access removes that barrier. There is also a market for the stolen access. Across the underground forums GTIG tracks, more people tried to buy AI accounts in 2026 while more sellers advertised them. Demand was concentrated on Claude and Gemini credentials and coding tools such as Cursor Pro and Devin, while Google says average prices per account more than doubled in 2026.

How the keys get out

The usual routes are dull: a token committed to a public repository, a leaked API key or malware on a developer's machine. Google's report adds a more specific one. In May, operators of the ACRSTEALER malware pushed instructions to grab configuration files used by AI coding assistants, including Cline's secrets.json and Continue's config.yaml. Google says such files can hold API keys in plain text, along with custom endpoints that point to the victim's paid model access and infrastructure.

What one token bought

In the April case, the token got the attacker into the victim's cloud environment. From there, Google's timeline shows them switching on Gemini Enterprise and launching a high-performance compute instance. They built container images for LiteLLM, a gateway that routes requests across AI models, and the Manus agent framework, then deployed them as publicly accessible services with firewall rules that allowed proxy traffic. The attacker then widened their reach by creating a service account, a non-human login, with Editor rights that gave them broad control over the project and exporting its keys. They ran BigQuery queries looking for tables that held environment variables and more credentials, then tried to make an external email address the project's owner. Google lists that last step as an attempt and does not say whether it worked.

The compute came next. The attacker enabled generative AI APIs across the project, set up a notebook environment, asked for higher quotas on NVIDIA RTX 6000 hardware and launched additional 48-vCPU instances to keep the workloads running. Google's Cloud CISO Perspectives newsletter says the customer was left to absorb the hardware and platform costs.

The cloud account becomes an attack platform

A cloud invoice is easy to see. Other damage in Google's report is harder to spot. In a separate Q2 case, GTIG says a suspected financially motivated attacker compromised an organization's cloud infrastructure and ran an autonomous multi-agent framework from it. Using an AI coding chatbot, one prompt and a set of agent instructions, the attacker planned, built and launched a mass credential-harvesting campaign in under six hours. Thousands of third-party credentials were compromised, and because the traffic came out of the victim's cloud, it carried legitimate IP addresses.

Google also tracks suspected activity by UNC6508, a China-linked espionage group, involving the compromise of cloud environments to run open-weight models locally. Running the models on the victim's infrastructure also avoids the usage monitoring and controls applied by commercial AI providers to their APIs. None of the underlying tactics are new. Stolen tokens and cloud abuse predate the AI boom. The payload has changed, along with how much an attacker can get done in an afternoon.

Google does not say where the April victim is based, and nothing in the report is specific to Kenya. But the setup is familiar to teams using GitHub, AI coding assistants and shared cloud infrastructure.

Where the attack can be stopped

Google's report describes the attack, not a fix, so this is our reading of where the April chain could have been broken. The first break is the token: keep credentials out of repositories, turn on GitHub's secret scanning, give tokens short lifespans so a leaked one expires, and rotate anything exposed immediately. The second is permission. The attacker was able to create a service account with Editor rights, giving them broad control over the project. Least privilege is the first thing to audit, and MFA on privileged accounts belongs in the same pass.

The third is compute. A budget alert tells you money is leaving; a GPU quota limits how much can leave. Teams with no use for GPUs can keep that quota at zero. The fourth is visibility. Alert on new VMs, new service accounts and quota requests, and watch for ownership changes. Keeping development, testing and production in separate accounts limits how far a leak in one can spread.

The April attacker needed one token. Everything after it came from what that token could reach and how long it took anyone to notice. Developers decide where a key sits and what it can touch. Platforms decide what an unfamiliar login can launch, and who hears about it.

Sources: Google Threat Intelligence Group, "GTIG AI Threat Tracker: From Prompting to Autonomy" (September 8, 2026); Google Cloud CISO Perspectives.