Meta News

Artificial intelligence infrastructure has introduced a new resource that attackers can steal, abuse, and exhaust:inference capacity.

Organizations increasingly integrate large language models into applications through APIs from providers such as OpenAI, Anthropic, Google, xAI, and cloud platforms. Every request consumes computational resources and, in most commercial environments, money.

This creates an emerging attack pattern known as AI API draining: the unauthorized consumption of an organization’s AI API quota, credits, tokens, or compute budget.

At first glance, API draining may look like ordinary credential theft. Technically, however, it sits at the intersection of cloud resource abuse, API security, financial denial-of-service, identity compromise, and AI infrastructure security.

The attacker does not necessarily need to compromise the model.

They only need to compromise the ability to use it.

A conventional API key is usually considered an authentication secret. An AI API key should additionally be considered a financial credential.

Consider an application architecture such as:

Application → AI Gateway → LLM API → Inference Infrastructure

The application authenticates to the AI provider using an API key, OAuth credential, service identity, or another machine-to-machine authentication mechanism.

Once an attacker obtains that credential, they may be able to issue legitimate API requests using the victim’s account.

From the provider’s perspective, nothing necessarily looks broken.

The API key is valid. The endpoint exists. The requested model is available. The request conforms to the API specification.

The problem is authorization context:the entity consuming the resources is not the workload that was supposed to consume them.

This makes AI API draining fundamentally different from exploiting a vulnerability in the model itself.

The attacker is abusing legitimate functionality.

A simplified attack chain might look like this:

Credential exposure → API discovery → quota enumeration → automated inference → financial/resource exhaustion

The initial credential can be obtained through numerous mechanisms.

Attackers may find AI API keys inside public GitHub repositories, CI/CD logs, environment files, browser storage, container images, compromised developer endpoints, application bundles, exposed Kubernetes Secrets, cloud metadata, or stolen configuration files.

Infostealer malware represents another important source.

A developer workstation may contain credentials for several AI providers alongside GitHub tokens, cloud credentials, SSH keys, and browser sessions.

Once the attacker obtains the credential, determining whether it works can require only a legitimate API request.

The attacker can then automate consumption.

Traditional denial-of-service attacks consume resources such as:

• bandwidth,
• connections,
• memory,
• CPU,
• storage,
• database capacity.

AI introduces another measurable resource:

tokens and inference compute.

An attacker can deliberately construct requests designed to maximize resource consumption.

Instead of sending thousands of tiny prompts, an economically optimized attacker could attempt to maximize the cost associated with each request by using large context windows, expensive models, high output limits, multimodal inputs, or computationally expensive inference features where available.

The attack objective becomes:

maximize victim cost / minimize attacker cost

This changes the economics of denial-of-service.

The attacker may spend almost nothing beyond acquiring the credential and operating the automation infrastructure, while the victim pays for the inference.

The attack becomes more interesting when combined with a botnet.

Imagine an attacker controls 20,000 compromised endpoints.

Instead of generating requests from one server:

Attacker → AI API

the operation becomes:

Attacker → Botnet → AI API

Thousands of geographically distributed machines can generate requests using the same stolen credential or collection of credentials.

This creates several defensive problems.

IP-based blocking becomes less effective. Traffic may originate from legitimate residential networks, corporate systems, or cloud providers distributed across many countries.

Rate limiting based exclusively on source IP may also fail because each bot generates only a small amount of traffic.

The aggregate consumption, however, can be enormous.

The recently documented x47.c Windows botnet illustrates this concept. Researchers reported functionality designed to generate requests against commercial AI APIs using supplied credentials, effectively turning compromised machines into distributed inference consumers.

The idea resembles distributed denial-of-service, but the resource being attacked is the victim’s AI budget.

AI API draining fits within the broader concept of Economic Denial-of-Sustainability (EDoS) or financial denial-of-service.

Traditional DDoS asks:

How much traffic is required to make this service unavailable?

Financial resource exhaustion asks:

How much legitimate-looking consumption is required to make operating this service economically unsustainable?

Cloud computing already introduced this problem.

Attackers can deliberately trigger expensive serverless functions, storage operations, database queries, or autoscaling events.

Generative AI significantly amplifies the concept because inference can be expensive.

A malicious request does not necessarily need to degrade service performance.

The application can continue working perfectly while the organization’s AI bill increases rapidly.

This creates a particularly dangerous failure mode:

availability remains normal while financial damage accumulates.

An AI API draining attack may produce no malware alert, exploitation signature, memory corruption event, or suspicious executable.

From the AI provider’s perspective, the requests may look like:

HTTP 200 OK

From the network perspective:

TLS connection → legitimate AI provider

From the authentication perspective:

Valid API credential

From the billing perspective:

Rapidly increasing token consumption

This means traditional endpoint and network detection may provide limited visibility.

The strongest signals may instead exist in identity, API telemetry, and billing data.

Security teams therefore need to monitor metrics such as request volume, tokens per request, model selection, geographical origin, application identity, historical consumption patterns, concurrency, and cost velocity.

Cost becomes security telemetry.

Monthly budget alerts are poorly suited to this type of attack.

Suppose an organization normally spends $10,000 per month on inference.

A traditional alert might trigger when consumption reaches $8,000.

That does little to stop an attacker capable of generating thousands of dollars of usage within minutes.

Security monitoring should therefore consider cost velocity:

cost / unit of time

For example:

$50/hour → $80/hour → $2,500/hour

The absolute monthly total may still appear acceptable while the rate of change clearly indicates abnormal behavior.

This is analogous to detecting network attacks using packet rates rather than waiting until total bandwidth consumption exceeds a monthly quota.

Simple IP rate limiting is insufficient for modern AI infrastructure.

Organizations should enforce limits at multiple dimensions:

API key

service identity

user

application

model

tenant

IP / ASN

geographical region

tokens per minute

requests per minute

concurrent requests

daily monetary spend

A production application might legitimately generate thousands of requests, while a development environment should never consume more than a small budget.

Those identities should not share the same limits.

A compromised development credential should not have the ability to consume the production organization’s entire inference allowance.

The principle of least privilege applies directly to AI infrastructure.

One of the worst architectures is:

Entire organization → One AI API key → Unlimited models → Shared billing

Compromising that single credential provides an enormous blast radius.

A stronger architecture separates identities:

Production App A → Credential A

Production App B → Credential B

CI/CD → Credential C

Development → Credential D

Security Testing → Credential E

Each identity should have independent quotas, model permissions, monitoring, and revocation capabilities.

Where supported, short-lived credentials and workload identities are preferable to long-lived static secrets.

The objective is straightforward:

compromising one workload should not expose the organization’s entire AI budget.

Credential theft is not the only possible attack vector.

Agentic AI introduces another possibility.

Consider an autonomous system capable of recursively invoking models or spawning subagents:

Agent → LLM → Tool → Agent → LLM → Tool

A malicious input could potentially manipulate the workflow into generating excessive model calls.

For example, an indirect prompt injection embedded inside a document could instruct an insufficiently constrained agent to repeatedly invoke expensive tools or create recursive tasks.

The attacker never sees the API credential.

Instead, they manipulate the legitimate application into consuming its own resources.

This resembles application-layer denial-of-service.

The difference is that every iteration can carry a direct inference cost.

Agentic systems therefore require controls such as maximum execution steps, token budgets, tool-call limits, recursion limits, timeouts, and per-task monetary ceilings.

As organizations adopt multiple models and providers, an AI gateway can become an important enforcement point.

Instead of allowing every application to communicate directly with external AI APIs:

Application → Provider

organizations can use:

Application → AI Gateway → Policy → Provider

The gateway can enforce authentication, authorization, model restrictions, rate limits, token budgets, logging, anomaly detection, and emergency shutdown policies.

This architecture also reduces credential exposure.

Applications authenticate to an internal gateway while provider credentials remain isolated behind the control plane.

From a Zero Trust perspective, every inference request becomes an authorization decision.

The question is no longer simply:

Is this API key valid?

It becomes:

Should this workload be allowed to consume this model, at this cost, at this rate, for this purpose, right now?

AI API draining also blurs the traditional boundary between cybersecurity and FinOps.

A SOC might detect unusual authentication behavior.

A FinOps team might detect abnormal spending.

An AI platform team might detect increased token consumption.

Individually, none of those signals necessarily proves an attack.

Combined, they can provide strong evidence.

For example:

New geography + unusual model + 20× token rate + unexpected cost spike

is considerably more suspicious than any individual signal.

Organizations deploying AI at scale therefore need to correlate billing telemetry with security telemetry.

Unexpected spending should increasingly be investigated as a potential security incident, not merely an accounting anomaly.

When AI API draining is suspected, simply blocking an IP address is rarely sufficient.

The potentially compromised credential should be revoked or rotated immediately.

Security teams should then determine where the credential was exposed, identify all workloads that used it, inspect historical API activity, establish the beginning of unauthorized consumption, and determine whether the attacker used the credential for anything beyond resource exhaustion.

That final question matters.

An attacker possessing an AI credential may use it to access models, retrieve stored information, interact with connected resources, or probe organizational AI infrastructure before beginning the draining operation.

Credential rotation therefore stops the immediate abuse but does not complete the investigation.

AI API draining represents a broader shift in cloud security.

Inference is becoming infrastructure.

Tokens are becoming resources.

API credentials are becoming financial assets.

And AI usage telemetry is becoming security telemetry.

The attack does not require breaking a model or discovering a sophisticated zero-day. A stolen credential, poorly designed agent workflow, or insufficiently protected API can be enough.

As AI becomes embedded throughout enterprise software, security teams will need to protect inference capacity much like they already protect cloud compute, databases, identities, and payment systems.

The key architectural principle is simple:

No credential, application, user, or AI agent should have unlimited authority to spend computational resources.

In the age of generative AI, controlling who can consume tokens — how many, how quickly, and at whose expense — is becoming a fundamental part of cybersecurity.