Google LLM-Jacking Attacks Turn AI Access Into a Stolen Commodity

Google says criminals are stealing AI accounts and cloud credentials as the cost of premium models creates a growing underground market for access.

The September 2026 warning changes the focus of AI security. Companies have spent years debating whether attackers can manipulate or compromise the models themselves. Google now describes a more immediate problem: attackers are stealing the accounts, API keys, configuration files, and cloud resources surrounding those models.

The resulting Google LLM-jacking attacks pit rapidly expanding AI access against identity controls that were designed for ordinary software services. LLM-jacking means using compromised credentials to consume someone else’s paid model access or computing capacity. The technique first surfaced publicly in 2024, but Google’s evidence suggests it has entered a broader criminal economy.

Google LLM-Jacking Attacks Are Expanding Beyond Stolen API Keys

Google’s central finding is that AI access has become valuable enough to steal, trade, pool, and resell.

The September threat assessment came from the Google Threat Intelligence Group, or GTIG. Its evidence draws on Mandiant incident response work, threat-actor tracking, underground forums, and activity observed across Google’s services.

GTIG found more buyers seeking AI-related accounts during 2026. Researchers also saw more sellers advertising them. Demand reportedly concentrated on credentials for Claude and Gemini, while accounts for autonomous coding environments also attracted interest.

Google did not publish a total number of stolen accounts. It did report that average underground prices per account more than doubled during 2026. That detail matters because it points to a market response, not merely scattered credential theft.

Attackers want premium AI access for several reasons. Paid accounts offer higher usage limits, stronger models, and fewer interruptions than disposable free accounts. API credentials can also support automated workloads that would be difficult to sustain through a consumer chat interface.

Cloud credentials carry even greater value. A compromised identity can expose hosted models, deployment permissions, storage, and expensive computing resources. Attackers can then run inference workloads while the victim absorbs the usage and operational consequences.

Google connects this behavior to LLM-jacking, where criminals commandeer paid model services or cloud infrastructure without authorization. The immediate goal can be free access, but the same infrastructure can support phishing, vulnerability research, malware development, or resale.

This is broader than someone finding a leaked API key in a public repository. Google observed an ecosystem that includes stolen accounts, automated registration, account pooling, API aggregation, proxy services, and anti-detection tools.

Account pooling combines several identities or API keys behind one service. That arrangement can distribute usage, reduce the effect of individual bans, and make activity harder to attribute. An aggregator can also present several providers through a single compatible interface.

Google previously documented actors using services that consolidated accounts from Gemini, Claude, and OpenAI. Its May threat report described tools for automated registration, verification, routing, quota monitoring, and browser-fingerprint masking.

Some of those tools have legitimate uses. Developers often route requests across models to improve availability or control internal workloads. The security concern arises when operators fill those systems with stolen or fraudulently created accounts.

That distinction prevents a common analytical mistake. Proxy software is not proof of criminal activity by itself. However, the combination of stolen credentials, evasive registration, concealed traffic, and unauthorized resale creates a recognizable abuse chain.

Google also found attackers targeting local configuration stores used by AI coding assistants. In May 2026, controllers associated with the ACRSTEALER malware family issued file-grabber rules for Cline’s secrets.json and Continue AI’s config.yaml.

These files can contain plaintext API keys or custom model-routing endpoints. A stolen browser session might expose one user account, while a developer configuration can open a path to organizational quotas and infrastructure.

The practical boundary of an AI account has therefore become difficult to define. It can include an identity, a session token, an API secret, a command-line configuration, a cloud role, and permission to invoke several external models.

For security teams, that expanded boundary creates the article’s central tension. Organizations want model access embedded throughout daily work, but every convenient integration creates another place where valuable credentials can escape.

Why AI Account Theft Now Pressures Every Cloud Customer

The pressure falls on organizations adopting AI fastest because their model access is spreading faster than their security ownership.

A conventional stolen software account usually gives an attacker access to data or application functions. A stolen AI account can add metered model consumption, cloud compute, autonomous tools, and connections to internal knowledge.

That combination changes the potential damage. A compromised credential can generate a bill, expose proprietary information, and provide infrastructure for attacks against other targets. The victim may initially see only unusual usage rather than a familiar intrusion signal.

Developers face particular exposure. AI coding assistants often run beside source repositories, terminals, package managers, and deployment tools. Their configuration files can reveal credentials with far more reach than a single chat history.

The growing use of agentic AI raises the stakes further. An agentic system allows a model to plan steps and operate tools with reduced human input. Its credentials may authorize file access, code execution, browsing, or communication with external services.

Google reported that threat actors are also adopting multi-agent frameworks for offensive workflows. These systems can coordinate scanning, resolve errors, and manage credential harvesting with fewer pauses for human decisions.

One Q2 2026 case compressed that shift into a striking timeline. GTIG observed attackers compromise a cloud resource, then plan, build, and execute an agent-enabled mass credential-harvesting campaign in under six hours.

That finding does not mean every criminal group now operates autonomous attack systems. It shows that automation can shorten the period between initial access and scalable exploitation.

Defenders traditionally rely on time between those stages. An alert may trigger an investigation before an attacker expands access, creates persistence, or reaches sensitive systems. A six-hour build-and-execution cycle leaves much less room for manual triage.

The value of stolen AI credentials also extends beyond their direct quotas. A configuration file can expose a private endpoint, while the related cloud identity can reveal logs, data stores, or connected applications.

Organizations should therefore treat Google AI account theft as an identity-security problem, not only an AI governance issue. The control point is often the credential and its surrounding permissions rather than the model’s safety layer.

Long-lived secrets create the most obvious risk. They can remain usable after an employee closes a laptop or changes a web password. Attackers may test them quietly, route traffic through proxies, and increase usage after confirming the available services.

Shared developer accounts create another weakness. When several people or automated systems use one identity, unusual activity becomes harder to attribute. Revoking access can also disrupt legitimate work, which can delay containment.

Cloud customers face a second problem: consumption looks normal at the infrastructure level. A valid key making valid model requests may not trigger controls designed to catch malware or prohibited network traffic.

Teams need behavioral signals instead. Useful indicators include new geographic origins, unexpected model activation, sudden quota changes, unfamiliar API gateways, abnormal request timing, and usage inconsistent with the credential’s owner.

Model providers carry pressure as well. They must distinguish legitimate aggregation from criminal pooling without blocking ordinary enterprise architectures. They also need to connect account, network, payment, device, and usage signals across rapidly changing products.

The forced response is an identity redesign around AI access. Organizations need short-lived credentials, narrower permissions, separate service identities, usage limits, rapid revocation, and monitoring tied to expected behavior.

Those measures sound familiar because the underlying failures are familiar. What has changed is the asset being monetized and the speed with which stolen access can support further operations.

The Real Tradeoff Is AI Convenience Versus Credential Control

AI adoption removes friction for users, but that same convenience can hide credentials inside tools, plug-ins, agents, and local files.

Most organizations do not deploy one centrally managed AI system. Employees use browser applications, coding assistants, command-line clients, model gateways, cloud platforms, extensions, and custom automations.

Each access path handles identity differently. One may use a session cookie, another an API key, and another a cloud role inherited from the user’s environment. Security teams can struggle to inventory all three.

AI coding tools make this tradeoff especially visible. Developers expect quick setup and uninterrupted model access. Saving a key in a configuration file is convenient, but malware that already searches local systems can add that file to its collection list.

Google’s findings show that infostealers are adapting accordingly. LUMMAC.V2, STEALC.V2, VIDAR, and ACRSTEALER operators displayed interest in AI developer configurations, moving beyond the theft of browser profiles.

Infostealers are malware designed to collect valuable information from an infected device. They commonly target passwords, cookies, wallets, and application data. Adding AI configuration files is a logical extension of an established business model.

This mechanism helps explain why the problem can grow without a dramatic breakthrough against frontier models. Attackers do not need to defeat a model’s core security architecture if they can impersonate a paying user.

Google has repeatedly drawn that distinction. Its February findings said attackers needed API keys and resources to misuse LLM services at scale. That requirement creates a direct incentive to hijack organizations with substantial AI capacity.

The conflict becomes sharper when agents receive broad tool permissions. An agent may need access to repositories, documentation, issue trackers, and deployment systems to provide useful assistance. Every added connector increases both utility and potential exposure.

A stolen AI credential does not automatically grant all those connected permissions. The outcome depends on how the organization designed authentication and authorization. Poorly separated identities, however, can turn one stolen secret into several paths.

Secrets should not sit in prompts, source files, notebooks, or broadly readable configuration directories. Organizations should store them in managed secret systems and issue them only to the workload that needs them.

That recommendation is easy to state and harder to enforce. Developers may create temporary experiments outside central platforms. Teams may share credentials to meet a deadline, while abandoned prototypes can retain active keys for months.

AI gateways can reduce sprawl by centralizing authentication and policy. They can also become high-value targets. If one gateway has access to many providers and broad quotas, compromising it gives an attacker a concentrated pool of capacity.

The answer is not to avoid gateways. It is to limit what each gateway identity can invoke, establish per-user attribution, and prevent one compromised component from activating unrelated services.

Organizations also need to separate model access from administrative access. A service that sends inference requests should not automatically receive permission to change billing, enable new models, create identities, or retrieve unrelated cloud secrets.

Strong authentication matters for interactive accounts, but multi-factor authentication does not solve every path. API keys and service identities often operate without an interactive challenge, and stolen session material can sometimes bypass a fresh login.

Short credential lifetimes reduce that exposure. So do workload identity systems that replace static keys with temporary tokens based on the running application’s verified context.

Usage controls provide another layer. Per-identity budgets, rate limits, model allowlists, and alerts for new regions can reduce the time and capacity available to an attacker.

Logs must also retain enough context for investigation. A model request should be traceable to a user, service, environment, and approved purpose without exposing sensitive prompt contents unnecessarily.

For knowledge workers, the lesson is more personal. A browser extension, downloaded coding utility, or unofficial client can sit between the user and several paid AI services. Installing one creates a trust decision about how it stores and transmits credentials.

Employees should not paste organizational API keys into unapproved tools. They should also report unexpected login alerts, model-usage notices, and sudden quota exhaustion as possible security incidents rather than ordinary billing errors.

The convenience-versus-control tradeoff cannot be eliminated. AI tools become useful by reaching more information and taking more actions. The defensible approach is to make each connection visible, limited, attributable, and easy to revoke.

Google’s Warning Does Not Measure the Full Scale of LLM-Jacking

The evidence shows a real and maturing threat, but it does not establish how many organizations have suffered LLM-jacking losses.

Google’s report uses directional language such as “increased targeting” and “growing number of intrusions.” It provides examples, observed tactics, marketplace trends, and incident-response cases rather than a complete prevalence estimate.

That limitation matters. Threat intelligence reflects the environments, customers, platforms, and underground spaces visible to the researchers collecting it. Activity outside that field of view may go uncounted, while heavily monitored actors may appear more prominent.

The reported doubling of average underground account prices is informative but incomplete. Google did not publish the underlying sample size, price distribution, or methodology needed to compare that market rigorously across time.

Higher prices can indicate growing demand, restricted supply, better account quality, or changes in the marketplaces being tracked. They do not independently prove that successful account theft doubled.

The “surge” framing should therefore be read as evidence of increased observed activity, not a census of global incidents. Google’s strongest claims concern what its teams directly saw: more buyers and sellers, targeted configuration theft, and cloud compromises supporting unauthorized workloads.

There is also a terminology problem. LLM-jacking can describe several related behaviors, from using one stolen API key to hijacking an enterprise cloud environment. Combining them under one label can obscure substantial differences in impact.

The original public research on stolen cloud credentials defined LLM-jacking around unauthorized use of hosted model services. Later reporting expanded the picture to proxy networks, resale, and offensive agent development.

That history offers a useful comparison. Cloud cryptojacking followed a similar economic logic: attackers stole computing capacity because the victim paid the bill. AI workloads create another monetizable use for compromised infrastructure.

Yet LLM-jacking can produce risks beyond consumption costs. Model access may help an attacker analyze stolen code, generate localized lures, automate research, or build services for other criminals.

Google’s own findings require another qualification. The company says attackers are becoming more capable users of AI, but it has also reported that many model-abuse attempts triggered safety systems or produced no major capability leap.

In earlier investigations, state-backed groups used Gemini for research, coding, translation, and troubleshooting. Google disabled related assets and updated its defenses. It did not conclude that those actors had defeated the model’s core safeguards.

That contrast is important. Account theft provides access, but access does not guarantee unrestricted output or successful operations. Providers can still detect abuse, enforce policies, disable accounts, and update model protections.

Criminals may also prefer stolen accounts precisely because safety enforcement remains active. Pools of disposable identities can help them absorb bans, distribute requests, and hide the broader pattern.

The resulting contest is not simply attackers against model guardrails. It is attackers rotating identities faster than providers and customers can connect suspicious behavior across accounts.

Independent research supports the underlying mechanism. Sysdig documented LLM-jacking in 2024 and later reported more varied targets and tactics. However, vendor research often comes from selected incidents rather than a representative global sample.

Readers should resist two opposite conclusions. It would be wrong to dismiss the threat because Google lacks a global count. It would also be wrong to claim that every AI account or cloud customer faces an immediate compromise.

The defensible conclusion is narrower. Stolen AI access now has observable marketplace value, established technical pathways, and demonstrated criminal use. That is enough to justify specific controls without inflating the available evidence.

What to Watch After Google’s AI Account Theft Warning

The next phase will be defined by provider telemetry, infostealer targeting, and whether enterprises can isolate AI identities before attackers scale their access.

The first signal is more detailed reporting from model and cloud providers. Google has established a direction of travel, but future reports need incident counts, affected credential types, abuse duration, and clearer marketplace methodology.

Those disclosures would strengthen the case that Google LLM-jacking attacks represent a distinct growth category. A lack of measurable expansion would suggest that current reporting combines several established forms of credential abuse under an AI-specific label.

The second signal is the behavior of infostealer operators. Google observed targeted rules for AI coding-assistant configurations, showing that criminals know where developers store model credentials.

Defenders should watch whether more malware families systematically add AI clients, agent frameworks, and model gateways to their collection lists. Broad adoption would show that AI secrets have become a standard target beside browser cookies and cryptocurrency wallets.

Security teams can look for this shift internally. Endpoint detections involving AI configuration paths deserve review even when no source code or traditional password store appears affected.

The third signal is enterprise identity architecture. Organizations will either keep issuing portable, long-lived secrets or move toward temporary workload credentials with narrow permissions and per-user attribution.

That transition will determine whether stolen access remains easy to reuse and resell. Centralized inventories, rapid rotation, default usage limits, and alerts for model activation can make compromised credentials less valuable.

Model providers also have a role. They can identify account pooling through network, device, payment, and request-pattern signals. They can require stronger verification when activity suddenly crosses regions, models, or usage profiles.

Those protections must avoid punishing legitimate enterprise routing. A company may intentionally distribute workloads across regions or providers. Detection systems need context from customer policies, not only generic anomaly thresholds.

Organizations should begin with a concrete inventory. Identify who can access paid models, which applications hold credentials, which cloud roles can enable services, and where model requests are logged.

They should then test revocation. A credential that cannot be located and disabled quickly is already an incident-response liability. Teams should confirm that removing one identity does not require shutting down unrelated AI workloads.

Developers can reduce risk by replacing local static keys, separating experimental accounts from production systems, and refusing to share credentials through chat or source repositories. Security teams should make the approved path easier than the workaround.

Executives should ask a simple question: if an AI credential were stolen tonight, would the organization notice the attacker, the bill, or the leaked data first?

Google’s warning makes that question urgent because attackers no longer see AI access as a novelty. They see an asset that can be acquired, pooled, consumed, and sold.

The next few months should reveal whether providers publish stronger measurements and whether infostealers broaden their target lists. Readers should use that window to audit AI access before the underground market matures further.