Google LLM-Jacking Warning Exposes a Dark Market for Stolen AI Access

Google has warned that LLM-jacking attacks are surging as criminals increasingly steal AI accounts, API credentials, and enterprise cloud capacity.

Underground sellers reportedly advertise unauthorized access to models from Google, Anthropic, and OpenAI at discounts reaching 97%. That figure describes observed marketplace listings, not an independently verified average transaction price.

The more important finding sits behind the headline. AI access has become a tradable criminal asset, much like stolen payment cards, cloud accounts, and residential proxy connections.

Google Threat Intelligence Group says it observed more buyers and sellers of AI accounts during 2026. Demand concentrated around Claude and Gemini credentials, alongside AI coding products such as Cursor Pro and Devin.

This is not simply subscription fraud. Attackers can steal an API key or cloud identity, route requests through another company’s account, and leave the victim responsible for the activity.

The resulting exposure combines unexpected consumption, data leakage, service disruption, and criminal use of trusted infrastructure. It also challenges security programs that still treat AI spending as a software budget rather than a controlled computing resource.

Earlier resource-hijacking campaigns usually pursued cryptocurrency mining or proxy capacity. LLM-jacking redirects the same economic logic toward model inference, developer agents, and the infrastructure needed to operate them.

The conflict is therefore larger than criminals versus AI providers. It is stolen access versus enterprise control, with every untracked key or overprivileged workload widening the market’s supply.

What Google’s LLM-Jacking Warning Actually Says

Google’s evidence shows that criminals are building a supply chain around compromised AI access, not merely experimenting with isolated stolen accounts.

The company’s September 2026 AI threat tracker describes increased theft, exfiltration, and sale of AI accounts across cybercrime communities.

Google says more underground personas sought AI-related accounts in 2026. It also observed more sellers advertising those accounts compared with the previous year.

Average marketplace prices per account more than doubled during 2026, according to posts tracked by Google. That increase suggests demand grew even while some individual listings promised extreme discounts.

The apparent contradiction makes sense inside an illicit market. Buyers value access because legitimate inference and high-performance computing require scarce, billable resources.

A stolen account can shift those costs to the victim. A seller can therefore undercut legitimate access without operating comparable infrastructure.

Reports about discounts reaching 97% appear to describe the steepest underground offers. Google’s public report does not establish that percentage as a market-wide average.

It also does not disclose a total victim count, aggregate financial loss, or verified transaction volume. Those omissions limit any attempt to measure the full size of the market.

However, the underlying activity is more firmly documented than the headline percentage. Google observed increased demand, targeted credential theft, and cloud compromises supporting unauthorized AI workloads.

The company calls the infrastructure version “LLMJacking.” The term covers the hijacking of enterprise cloud resources to run AI models or consume hosted model services without authorization.

Google also identifies account procurement methods beyond direct theft. Threat actors use automated registrations, account pooling, proxy relays, and middleware that aggregates multiple keys.

These systems can distribute requests across accounts and conceal their origin. They can also replace disabled credentials without changing the buyer’s interface.

That structure turns compromised access into a service. Buyers do not need to understand which organization pays the underlying bill.

The market reportedly includes credentials for consumer-facing AI accounts, coding assistants, and model APIs. Those assets differ significantly in what they expose.

A stolen chat account can reveal conversation history and uploaded documents. An API credential can provide programmable access to a quota, model, or connected cloud project.

A compromised cloud identity presents the broadest risk. It can let an intruder provision infrastructure, discover stored credentials, or reach adjacent enterprise services.

Google’s warning links these layers into one economy. Stolen accounts provide immediate access, while compromised infrastructure supplies durable computing capacity.

That combination explains why the threat matters beyond a single provider. Google, Anthropic, and OpenAI compete for legitimate customers, but criminals can trade access to all three as interchangeable inventory.

Why AI Access Became Valuable Criminal Inventory

The rise of LLM-jacking reflects a basic economic shift: model access now provides useful, scalable computing capacity that criminals do not want to fund themselves.

Criminal groups have long stolen infrastructure when the stolen resource could produce revenue. Cryptocurrency mining made compromised processors valuable because computing power translated directly into digital assets.

Proxyjacking created another market by routing traffic through victims’ systems. Attackers could sell bandwidth and trusted-looking residential or enterprise addresses.

LLM-jacking extends that model to inference. The stolen resource is the ability to send prompts, generate outputs, operate agents, or run models on hijacked hardware.

MITRE classifies this broader behavior as resource hijacking. Its framework includes compute, bandwidth, messaging, and cloud-service abuse.

AI makes the opportunity more flexible. One credential can support code generation, reconnaissance, content production, translation, phishing preparation, or an automated offensive workflow.

The same credential can also provide access to higher limits or capabilities unavailable through an anonymous free account. That difference matters when an operation depends on sustained automation.

Google says premium access and high-performance compute remain important barriers for attackers. Stealing those resources lowers the barrier without requiring criminals to build an AI platform.

The market can serve several types of buyer. Some want inexpensive general model access, while others seek accounts that withstand high-volume or policy-violating use.

More capable groups can connect stolen access to orchestration systems. Those systems automatically select accounts, rotate endpoints, retry failed requests, and distribute work.

Google’s May 2026 threat research documented proxy relays and automated registration pipelines used to industrialize access to commercial models.

The report described anti-detect browsers, account pools, and custom middleware designed to evade billing constraints or platform enforcement. These mechanisms reduce dependence on any single credential.

They also complicate attribution. Traffic reaching a provider can pass through relays and compromised projects before producing a malicious result elsewhere.

For an enterprise victim, the first obvious signal might be abnormal model consumption. Yet the attacker may have entered through a developer device days earlier.

An infostealer, which is malware designed to collect credentials and session data, can search local files for AI configuration information. It can then export anything useful to its controller.

Google observed controllers of ACRSTEALER targeting configuration stores associated with Cline and Continue AI. Those files can contain plaintext API keys or custom routing endpoints.

This detail makes AI developer environments especially important. Coding assistants frequently sit near source repositories, package registries, terminals, and cloud tooling.

A stolen credential from that environment can deliver more than model access. It can help attackers map the development stack or identify a route into production systems.

The growing market therefore pressures security leaders, engineering managers, and cloud-finance teams at the same time. Each group sees a different fragment of the incident.

Security sees a compromised identity. Engineering sees failed requests or exhausted quotas. Finance sees unexplained consumption after the access has already been monetized.

Without shared monitoring, those fragments may never become one incident. The dark market benefits from that organizational delay.

Google LLM-Jacking Warning Puts Identity Controls Under Pressure

The central problem is not that models suddenly became easy to hack. Attackers are stealing the identities and infrastructure surrounding them.

Google’s research distinguishes attacks on AI assets from successful compromises of frontier models themselves. The observed activity focuses heavily on credentials, connectors, developer configurations, cloud projects, and orchestration layers.

That distinction matters because model safety controls cannot revoke a leaked enterprise key. They also cannot correct an identity role that grants unnecessary access across a cloud environment.

A bearer credential lets its holder act with the credential’s assigned permissions. The system may not know whether the request came from its owner or a thief.

Long-lived API keys make that weakness harder to manage. They often survive staff changes, abandoned prototypes, and migrations between AI providers.

Developers may copy them into local configuration files for convenience. Automated tools can also generate keys without placing them inside an established security inventory.

The result is credential sprawl. Organizations know which AI tools they approved, but not necessarily which identities, keys, extensions, and local agents can access them.

LLM-jacking turns that governance gap into inventory for criminals. Every reusable credential becomes a potential product.

The security challenge grows when organizations connect models to internal data. An AI assistant may have access to source code, technical documents, support records, or project discussions.

If an intruder steals the assistant’s session, the incident might expose stored conversations or connected resources. If the attacker steals only an API key, the direct data exposure depends on its permissions.

Those scenarios should not be collapsed into one claim. A compromised key does not automatically grant access to every prompt or internal system.

However, teams also should not assume unauthorized use creates only a billing problem. Logs, model outputs, connected tools, and application context can all contain sensitive information.

The risk becomes sharper with agents. An agent can call tools, retrieve documents, execute approved actions, and preserve operational context across a workflow.

Those capabilities are useful because they reduce manual work. They are dangerous when the underlying identity lacks narrow permissions and reliable audit trails.

Google reported that attackers are moving toward agentic operations with less human delay. In one second-quarter case, a compromised cloud resource supported a mass credential-harvesting campaign in under six hours.

That example does not prove every stolen AI account will power an autonomous attack. It shows why slow, manual approval chains cannot remain the only defensive mechanism.

Enterprises must know which identities can consume models, which applications own them, and what normal consumption looks like. They also need a rapid method for suspending access.

This requires coordination beyond the security operations center. Platform teams must make credentials observable, while procurement teams must connect invoices to specific owners and workloads.

Developers also need approved storage and rotation paths that remain convenient. If the secure process creates too much friction, unmanaged local alternatives will continue spreading.

The winner in this conflict will not be the company with the longest acceptable-use policy. It will be the company that can identify, constrain, and revoke AI access quickly.

The Attack Chain Starts Before the First Suspicious Prompt

LLM-jacking usually succeeds through familiar credential theft and cloud abuse, then uses AI consumption as the monetization layer.

A common path begins on a developer workstation. Phishing, malicious software, a compromised package, or a deceptive browser extension can deliver an infostealer.

The malware searches browsers, configuration directories, command histories, environment files, and application stores. AI development tools create additional targets because many need model credentials.

Once stolen, a key can be tested automatically. Criminal operators can identify its provider, available quota, restrictions, and whether the credential still works.

Useful credentials may be sold directly or loaded into a relay. A relay accepts requests from customers and forwards them through one or more compromised accounts.

The customer sees a stable service endpoint. Behind it, the operator can replace a revoked credential, spread consumption, or route specific workloads to different models.

This separation protects the buyer from the instability of individual stolen accounts. It also lets the seller monetize one collection of credentials across many customers.

Cloud compromise creates another path. Attackers can obtain an identity that permits them to activate model services or deploy self-hosted infrastructure.

They may then consume hosted inference through the victim’s project. Alternatively, they can use stolen computing capacity to run a model directly.

Security company Sysdig coined the term LLMjacking in 2024 for the use of stolen cloud credentials to consume paid model services. Its later LLMjacking research describes a progression toward offensive agent workloads.

Self-hosted models create a related exposure. An internet-accessible inference server without authentication can offer free capacity to anyone who discovers it.

That route requires no stolen API key. The weakness lies in an exposed service and inadequate network controls.

The outcome can still resemble LLM-jacking because an outsider consumes an organization’s AI infrastructure. Yet the remediation differs from an account-theft investigation.

Teams need to distinguish at least three incident types: compromised user sessions, stolen model credentials, and hijacked cloud or self-hosted infrastructure.

Session theft calls for account revocation, device investigation, and review of exposed content. API-key theft requires key rotation, log analysis, and validation of associated permissions.

Infrastructure compromise demands broader incident response. Investigators must establish how the attacker entered, what resources were created, and whether persistence remains.

Consumption anomalies can reveal all three, but they are not sufficient alone. A legitimate product launch can also create sudden model traffic.

Useful detection combines volume, identity, geography, timing, model selection, and application behavior. A workload that changes several dimensions together deserves rapid review.

Teams should also monitor requests rejected by safety controls. Those events can indicate abuse, though sophisticated attackers may use benign tasks or their own models.

The best controls reduce both probability and impact. Short-lived credentials narrow the window, while workload-specific identities limit what a stolen credential can reach.

Network restrictions can block use from unexpected environments. Quotas and consumption limits can slow abuse while responders investigate.

None of these controls provides certainty. Together, they make stolen access less reliable and therefore less valuable to underground sellers.

What the 97% Discount Claim Does Not Prove

The dramatic discount is a useful warning signal, but it does not measure the market’s actual size, reliability, or financial impact.

An underground advertisement is not a completed sale. Sellers may exaggerate access quality, account type, remaining quota, or the duration before revocation.

The advertised product might also differ from legitimate access. Buyers may receive a shared proxy, a browser session, or a short-lived account rather than a transferable subscription.

That distinction changes the discount calculation. Comparing an unstable criminal relay with reliable, supported access can produce a misleading percentage.

The figure also does not reveal who absorbed the underlying consumption. Some access may come from stolen credentials, while other offers may exploit trials or automated account creation.

Google has documented all those procurement paths. The public evidence does not assign a percentage of the market to each one.

Nor does the report establish that attackers breached Google, Anthropic, or OpenAI’s core model infrastructure. The observed market largely depends on compromised customers and account ecosystems.

That nuance should shape the response. Enterprises cannot wait for providers to solve every case because many vulnerabilities exist inside customer-managed identities and devices.

Providers still carry significant responsibility. They can detect account pooling, suspicious relays, impossible usage patterns, and coordinated registration abuse across their platforms.

Google says it uses threat intelligence to strengthen safeguards and disable malicious projects or accounts. Such enforcement can increase the cost of maintaining an underground service.

Yet provider action introduces another uncertainty. Aggressive automated blocking can disrupt legitimate shared infrastructure or globally distributed development teams.

Security systems therefore need evidence beyond a single traffic spike. They must distinguish a product launch, a misconfigured application, and a stolen credential quickly.

The absence of aggregate loss data also limits comparisons with ransomware, cryptojacking, and other cloud threats. LLM-jacking might be widespread while producing modest losses per victim.

The opposite pattern is also possible. A smaller number of cloud compromises might generate severe exposure because the stolen identity reaches valuable data and infrastructure.

Google’s telemetry represents another boundary. It offers strong visibility into its own ecosystem and incident-response work, but not every provider or underground transaction.

Independent research helps confirm the attack pattern. It still cannot convert fragmented observations into a complete global market estimate.

The defensible conclusion is narrower and more useful. Criminal demand exists, sellers are responding, and stolen AI access now has a repeatable monetization path.

That conclusion does not require accepting every dark-web listing at face value. It requires treating AI credentials as assets that attackers actively seek.

The skeptical reading therefore strengthens the operational lesson. Teams should respond to verified attack mechanics, not build policy around one promotional number from an illicit seller.

Three Signals Will Show Whether LLM-Jacking Keeps Growing

The next stage will become visible through credential-stealer targeting, provider enforcement, and enterprise consumption anomalies.

The first signal is whether infostealers expand their targeting of AI configuration files. Google has already observed malware controllers searching for specific coding-assistant secrets.

New rules aimed at additional agents, model routers, and local developer tools would indicate that attackers continue finding valuable credentials there.

Security teams should therefore inspect endpoint detections for unfamiliar searches across configuration directories. They should also inventory applications that store model credentials locally.

The second signal is provider enforcement. Watch for disclosures about disabled account pools, dismantled relay networks, stricter registration checks, and narrower authentication options.

More enforcement would confirm that providers see coordinated abuse at meaningful scale. It might also push criminals toward self-hosted models and direct cloud compromise.

That displacement matters. Blocking stolen consumer accounts does not end demand for low-cost computing capacity.

The third signal is enterprise telemetry. Unexplained increases in inference requests, new model usage, unfamiliar regions, or consumption outside deployment windows can expose compromised access.

MITRE’s cloud-service hijacking model recommends looking for sudden resource changes and unauthorized service consumption. AI teams can adapt that logic to tokens, requests, endpoints, and model families.

Google’s API key guidance recommends restrictions, usage monitoring, isolated keys, periodic rotation, and stronger authentication where available.

Teams should translate those principles into ownership rules. Every model credential needs a named application, accountable team, approved environment, and documented revocation path.

Avoid sharing one key across people and workloads. Separate credentials create better audit trails and reduce the reach of a single compromise.

Do not store production secrets in repositories, notebooks, browser-accessible code, or loosely managed local files. Use a managed secret store and automate credential delivery.

Prefer short-lived identity credentials where providers support them. A temporary credential gives attackers less time to test, package, and resell access.

Set consumption alerts at the workload level, not only for the overall cloud account. Aggregate billing can hide abuse inside normal enterprise growth.

Monitor rejected requests and abrupt changes in model selection. A compromised application that suddenly calls different models may reveal experimentation by an attacker.

Restrict which services, applications, networks, and methods each identity can use. Least privilege turns a stolen key from a master credential into a limited asset.

Review AI-connected tools with the same discipline applied to source repositories and cloud consoles. Agents can inherit sensitive permissions through connectors that teams overlook.

Keep an incident playbook for AI credentials. It should cover revocation, log preservation, endpoint inspection, provider notification, and checks for adjacent cloud access.

A searchable engineering knowledge base can help teams preserve ownership records and response procedures. It should never contain live secrets.

Google’s LLM-jacking warning changes the question enterprises should ask. The issue is no longer whether criminals value AI access, because the underground market shows they do.

The practical question is whether your organization can identify every credential that reaches a model, detect abnormal use, and revoke access before it becomes inventory.

Audit those credentials now. Assign an owner to every remaining key, remove abandoned access, and test the revocation process under realistic conditions.