AI access is becoming a black-market commodity

AI Model Access Is Becoming a Black-Market Commodity

AI model prices have not yet fallen low enough, but the black market has already found a “low-cost alternative.”

According to a report published by the Financial Times on September 26 local time, Google’s threat intelligence team found that illegally obtained access to AI models and computing power is becoming an increasingly popular commodity in the cybercrime market. Attackers steal login credentials, abuse cloud accounts, and even compromise enterprise servers to run their own models, then resell these capabilities to other criminal groups.

John Hultquist, chief analyst at Google’s threat intelligence team, said that so-called “LLM hijacking” activity has increased significantly this year. Dark-web markets are already trading access to models from companies such as Anthropic, Google, and OpenAI, with discounts of up to 97%. In other words, model services that would normally cost tens or hundreds of dollars per month, or incur substantial charges based on token usage, may be available on the black market for just a few percentage points of the legitimate price.

This is not simply a matter of “monetizing stolen accounts.” It means that model access is beginning to take on characteristics similar to cloud servers, proxy IPs, and payment accounts in underground markets: stable supply, price differences, after-sales service, and even “replacement guarantees if the account is banned.”

The Black Market Sells the Token Cost Difference, Not the Models

What is primarily being resold today is not the model files themselves, but authorization to call those models.

Some sellers obtain corporate and personal accounts through credential stuffing, phishing, malicious browser extensions, or supply-chain attacks, then resell usable API keys, subscription accounts, or cloud-platform credentials. Others use reverse proxies to package multiple stolen accounts behind a single unified endpoint and provide model-calling services to customers.

For buyers, the appeal is straightforward: they do not need to pay for legitimate subscriptions, nor do they have to handle account registration, payment, or regional access themselves. As long as they obtain an endpoint that can call a model, they can integrate it into their own scripts, automation tools, or attack chains.

For cybercrime groups, the cost difference is especially important. Generating phishing emails, analyzing leaked data in bulk, writing malicious code, and translating social-engineering scripts used to require human teams. Now, models can significantly reduce the marginal cost of this work. If the usage fees are effectively paid by the victim, attackers gain an additional economic advantage.

Hultquist’s assessment deserves attention: attackers obtain expensive tokens at very low cost, while defenders may also need similar AI tools to analyze alerts, generate detection rules, and handle incidents. Both attackers and defenders are using AI, but one side is paying while the other may be “borrowing” someone else’s budget.

This will change the cost structure of cyber offense and defense. Security teams typically treat attackers’ infrastructure, domains, servers, and proxy networks as resources that need to be tracked. In the future, they will also need to investigate “who is paying for the model calls.”

“Guaranteed Access” Shows That Account Theft Has Become Industrialized

Dark-web sellers have even begun offering so-called “guaranteed access” services: if the initial account is banned by the model provider, the seller promises to replace it with a new set of login credentials at no additional cost.

These promises reveal two things.

First, model providers’ risk controls are increasing the operating costs of stolen accounts. High-frequency usage, unusual geographic locations, sudden changes in model usage patterns, and the bulk generation of similar content can all trigger restrictions or bans. For sellers who depend on stolen accounts for sustained profits, an account is not a one-time product, but a consumable that must be continually replenished.

Second, black-market transactions are shifting from “selling an account” to “selling a period of usable capability.” This is very similar to the business models of proxy services, cloud servers, and botnets. Sellers no longer care how long a particular account remains usable. Instead, through account pools, proxy layers, and automatic switching mechanisms, they try to maintain a stable model-calling endpoint.

If this model continues to develop, underground services may eventually charge by token, number of calls, model tier, or even concurrency. What attackers purchase is not a particular ChatGPT or Claude account, but a “model supply chain” that can continuously produce content, code, and automated tasks.

Cloud Compute Hijacking Is Harder to Detect Than Account Theft

Compared with stolen model accounts, compute hijacking deserves greater attention from enterprises.

Some criminal groups and state-sponsored organizations compromise servers that enterprises host in the cloud, then deploy their own models or inference tasks in the victim’s environment. The victim pays for the servers, GPUs, network bandwidth, and electricity, while attackers only need to control the tasks and output.

This resembles traditional cryptocurrency mining, but AI compute hijacking may be more difficult to detect. Cryptocurrency mining typically keeps CPUs or GPUs under sustained heavy load, leaving obvious performance and billing anomalies. AI inference tasks, by contrast, can run intermittently according to business traffic and may even be disguised as normal model services, batch-processing tasks, or data-analysis jobs.

When enterprises have only just deployed AI infrastructure, their monitoring baselines are often immature. Increased GPU utilization, growing storage consumption, and higher outbound traffic may be attributed to business expansion. Newly created containers, service accounts, and model files may likewise be mistaken for normal deployment activity. Attackers exploit precisely this “noise period.”

Hultquist pointed out that enterprises are still figuring out how much AI compute they actually need. For attackers, this creates a window in which they can infiltrate target accounts and servers. An enterprise may know that its costs are rising, but it can be difficult to determine immediately whether the increase comes from genuine business activity, changes in model efficiency, or someone running unauthorized tasks in the background.

Private Deployment Does Not Automatically Provide Security

More and more large enterprises want to deploy customized models on their own servers to reduce dependence on cloud providers or meet data-compliance, latency, and cost-control requirements.

However, private deployment also means that responsibility shifts from the cloud provider to the enterprise itself. Enterprises must protect GPU nodes, model weights, inference gateways, container clusters, object storage, key-management systems, and logging platforms on their own. A breach at any layer could give attackers access to model capabilities or computing resources.

Particular attention is needed because internal AI systems often have extensive privileges. To allow agents to retrieve information, write files, execute code, access databases, and call external APIs, development teams may be tempted to configure long-lived cloud credentials and overly broad network permissions. Once those credentials are exposed, attackers gain more than model usage quotas; they may also obtain access to databases, internal code repositories, and production environments.

AI systems therefore cannot be protected merely as “an application.” They must be managed as production infrastructure with computing, network, and data permissions. At a minimum, enterprises should:

• Use separate credentials for model calls, cloud platforms, and inference clusters, avoiding a single key that grants access across every environment.
• Apply least privilege, expiration dates, source-IP restrictions, and usage quotas to API keys, and prohibit the long-term use of non-expiring master keys.
• Maintain asset inventories for GPUs, containers, nodes, and object storage, recording who created, modified, and used each resource.
• Monitor token consumption, model-call frequency, concurrency, outbound traffic, and GPU utilization, and establish baselines broken down by business unit and account.
• Sign model files, images, and dependency packages and verify their sources to prevent malicious models or supply-chain packages from entering production environments.
• Set permission boundaries for agents accessing files, executing code, modifying configurations, and initiating external network requests, while requiring human approval for high-risk actions.

What Developers Really Need to Prevent Is “Credentials Entering Logs”

For development teams using model APIs, the most easily overlooked problems are often not complex attack chains, but everyday details surrounding credential exposure.

An API key committed to a Git repository, written into front-end JavaScript, appearing in CI logs, embedded in a Docker image, or mistakenly included in an exception stack trace can give attackers access that can be monetized immediately. Model usage is typically billed according to consumption. Attackers do not need to take control of an entire server; as long as they obtain one still-valid key, they can start consuming its quota.

The same applies when using aggregation platforms. Model endpoints such as OpenAI Hub that are compatible with the OpenAI format allow developers to switch among models such as GPT, Claude, Gemini, and DeepSeek using a single calling method. This does not mean credential management can be ignored, however. A unified endpoint reduces integration costs, but it also increases the scope of impact if that endpoint is compromised. Both the platform and the enterprise need to implement key rotation, quota isolation, call auditing, and anomaly alerts properly.

A more robust engineering practice is to ensure that clients never directly hold production keys. All requests should first pass through the enterprise’s own backend gateway. The gateway can then issue short-lived credentials based on the user, project, and environment, while recording the model, tokens, request source, and result status. Development, testing, and production environments should use separate accounts and quotas to prevent a single accidental commit from affecting the entire organization.

AI Security Has Expanded From Models to Operational Systems

The most important change brought by this wave of risks is that attackers no longer treat large models only as targets. They also treat them as infrastructure and production resources.

They can steal model access to generate attack content, hijack computing resources to run their own models, or exploit agents connected to internal systems to escalate their privileges. The security of the model itself is only one part of the problem. What truly determines the risk is what the credentials can access, who pays for the compute, whether usage can be audited, and whether the enterprise can quickly contain the damage when anomalies appear.

For model providers, account controls and abuse detection will become part of their commercial capabilities. For cloud providers, identity authentication for GPU resources, runtime detection, and billing-anomaly analysis will need to resemble traditional security products more closely. For enterprise developers, AI gateways, key management, and runtime auditing are no longer patches to apply after launch; they should be designed together with model integration.

For some time to come, the AI black market may not primarily focus on “selling models.” More likely, it will sell usable quotas, proxy endpoints, stolen cloud accounts, and short-term computing power, along with automated integration and replacement services built around these resources.

This also explains why “cheap model APIs” require particular caution. When a price is far below the provider’s official cost, what the user is buying may not be efficiency, but someone else’s bill. For developers, verifying the service source, isolating credentials, limiting quotas, and retaining usage audits are already basic skills for using AI infrastructure, not optional security enhancements.

Sources

• ITHome: Hackers Sell AI Model Access on the Dark Web, with Prices as Low as 3% of the Legitimate Cost — Describes the LLM hijacking, credential resale, and compute abuse disclosed by the Google threat intelligence team and cited by the Financial Times.