ATLAS AML.T0034 Cost Harvesting: Defences

Pay-per-use AI services turn every request into a cost, so an adversary who cannot steal anything can still hurt you by making the system work harder than it should. MITRE ATLAS tracks this as AML.T0034 Cost Harvesting: deliberately driving a victim's AI services beyond normal operating capacity to increase the cost of the service. ATLAS release 2026.10 places it in the Impact tactic (AML.TA0011), rates it feasible, and since March 2026 splits it into three sub-techniques covering high-volume queries, expensive queries and agents coerced into wasteful work. This guide is for platform owners, AI application teams and FinOps and security leads who run LLM APIs, inference endpoints or agents. It explains how ATLAS defines the technique, how to tell it apart from neighbouring threats, and which limits, telemetry and tests stop it. The detailed limit design is in the Denial-of-Wallet and AI Agent Cost Runaway Guide; this page is the ATLAS view.

Key takeaways

The goal is financial harm. ATLAS separates cost harvesting from resource hijacking: the adversary is not using your compute for their own work, they are making you pay for load you did not want.
Three routes, three controls. Excessive Queries (AML.T0034.000) needs rate limits and quotas, Resource-Intensive Queries (AML.T0034.001) needs per-request bounds, and Agentic Resource Consumption (AML.T0034.002) needs workflow-level budgets.
Autoscaling amplifies the bill. ATLAS notes that inflated load can trigger autoscaling that provisions more resources, raising cost and exposure, and can saturate GPU pipelines so legitimate users see latency or outages.
Agents multiply one prompt into many calls. A single injected instruction can push an agent into fan-out or self-delegation loops, so limits on the front door alone are not enough.
No case study yet. ATLAS rates the technique feasible and records no case study for it; the evidence base is research such as sponge examples, which raised energy use by a factor of 10 to 200.

How the technique works

ATLAS describes three sub-techniques, all added on 30 March 2026. They differ in where the cost comes from, which decides where the control must sit.

Sub-technique	How cost is driven up	Platforms (ATLAS)	Why it is hard to spot	Primary control
AML.T0034.000 Excessive Queries	Automated high volumes of normal, cheap requests that exploit rate limits, autoscaling and pay-per-use billing	Predictive, Generative, Agentic	Each request looks legitimate; the problem is volume, often spread across keys or accounts	Rate, burst and concurrency limits plus quotas per identity (AML.M0004)
AML.T0034.001 Resource-Intensive Queries	Few requests that are expensive to process: long inputs, requests for very long outputs, prompts that demand complex reasoning, or sponge examples	Predictive, Generative, Agentic	ATLAS notes that fewer, heavier queries may be harder to detect and block than a flood	Bounds on input, output, time and compute per request (AML.M0036)
AML.T0034.002 Agentic Resource Consumption	Instructions placed in the agent's context through prompt injection (AML.T0051) or tool data poisoning (AML.T0099) that cause unnecessary searches, fan-out, many tool calls or recursive self-delegation	Agentic	The user's request is small; the cost appears inside the workflow	Workflow budgets: iterations, tool calls, delegation depth, downstream spend (AML.M0036)

The precondition is access. For most deployments that means AML.T0040 AI Model Inference API Access through a public or partner endpoint, or the ability to place content where an agent will read it. The sponge examples research cited by ATLAS showed that crafted inputs to vision and language models raised energy consumption by a factor of 10 to 200 and transferred across CPUs, GPUs and an ASIC simulator; its proposed defence was to analyse energy use for the worst case rather than the average.

Telling it apart from neighbouring threats

The same spike on a billing dashboard can come from several causes. Intent and pattern decide which playbook applies.

Threat	Adversary goal	Typical signal	Reference
Cost harvesting	Raise the victim's cost	Load from your own users, keys or content sources with little useful output; repetitive or oversized requests	AML.T0034
Resource hijacking (LLMjacking)	Use the victim's AI for the attacker's own purposes	Stolen keys invoking models from unfamiliar locations, often in regions or models you do not use	ATT&CK T1496.004 Cloud Service Hijacking; see the LLMjacking 2024 to 2026 breach analysis
Denial of AI service	Make the service unavailable	Errors and timeouts for legitimate users are the aim, cost is a side effect	AML.T0029 Denial of AI Service
Model extraction	Copy model behaviour	High query volume with systematic input coverage and interest in confidence scores	AML.T0005 Replicate AI Model Behavior
Accidental runaway	None	A bug, retry storm or misconfigured agent in your own code	Internal incident

LLMjacking shows the scale of the bill when model use is not bounded: Sysdig estimated the cost to a victim at over $46,000 a day in May 2024 and over $100,000 a day in September 2024. Under ATLAS that is hijacking rather than harvesting, but the same quotas, budgets and alerts limit both.

Prevention: limits at three layers

ATLAS maps four mitigations to AML.T0034. ATLAS says resource limits must apply across the complete workflow, because one request may start many model calls or external actions, and that they complement query-rate limits rather than replace them.

Layer	ATLAS mitigation	Concrete settings
Identity and access	AML.M0019 Control Access to AI Models and Data in Production	Authenticate every endpoint; no anonymous access to paid models; separate keys per application and tenant
Request volume	AML.M0004 Limit AI Service Query Volume and Rate	Short-term rate, burst and concurrency limits with longer-term quotas, applied by user, API key, tenant or device; watch for evasion through distributed requests, account rotation or stolen credentials
Per request	AML.M0036 Limit AI Workload Resource Consumption	Maximum input size and context tokens, maximum output tokens, execution timeout, memory and batch size
Per workflow	AML.M0036 Limit AI Workload Resource Consumption	Limits on iterations, retries, tool calls, parallel tasks and delegation depth; cost ceilings, circuit breakers and safe termination
Assurance	AML.M0035 AI Red Team	Controlled tests for each sub-technique; verify budgets, quotas, alerts and termination work

Where the limits live

AI gateway: a gateway token-limit policy can enforce tokens per minute and a token quota per period keyed to a subscription or identity, returning an error once a limit is exceeded. See the AI Gateway and LLM Gateway Guide.
Application: validate input length before the model call and set an explicit maximum output length on every call; do not rely on model defaults.
Agent runtime: enforce step, tool-call and spend counters in the orchestrator, not in the prompt, so an injected instruction cannot talk the agent out of them. See AI Agent Rate Limits.
Infrastructure: cap autoscaling maximums for inference pools so a flood cannot provision unlimited capacity.
Billing: budget alerts are a backstop, not a brake; they report spend after it happens.

Decision guidance

Situation	Start with	Add when the risk grows
Internal assistant for staff on a hosted LLM	Per-user quotas and maximum output tokens	Spend alert per department or project
Public chatbot or free tier	Authentication or strong anonymous throttling, per-session token caps, input length limits	Bot detection, adaptive throttling for repetitive or oversized prompts
Partner or customer API	Per-key rate and token quotas tied to contract	Per-tenant cost dashboards and automatic suspension at a hard ceiling
Agents that browse, call tools or delegate	Step, tool-call and delegation-depth limits; per-task cost ceiling	Human approval above a cost threshold; content provenance checks on retrieved data
Self-hosted inference cluster	Request timeouts, batch and memory limits, autoscaling caps	Worst-case latency and energy testing of new models before release

Smaller organisations get most of the value from a gateway quota and a hard spend ceiling per key. Larger ones need per-tenant attribution so the cost of an attack lands on a named identity that can be suspended without affecting others.

How to implement

Map cost paths: list every endpoint, model and agent, what each request can trigger downstream, and who pays.
Baseline: measure normal tokens per request, requests per identity and steps per agent task for two to four weeks (our recommendation).
Set limits in report-only mode: configure quotas and ceilings slightly above the baseline and log breaches without blocking.
Enforce in rings: block first on free or anonymous tiers, then partner keys, then internal users, checking support tickets after each step.
Red team: run the AML.M0035 tests ATLAS lists for each sub-technique: controlled high-volume activity, requests designed to consume disproportionate inference resources, and recursive or fan-out agent behaviour. Use an isolated environment and a fixed test budget.
Roll back safely: keep limit changes in configuration with version history so a limit that blocks legitimate work can be raised in minutes rather than removed.

Where identity fits

Rate limits and quotas only work when they are keyed to an identity the attacker cannot cheaply multiply. ATLAS warns specifically about evasion through account rotation and stolen credentials. Issue a separate API key or workload identity per application, tenant and agent; avoid shared keys that pool everyone's usage; and treat an agent's credentials as having a spending authority that needs its own ceiling. A leaked AI API key is both a secrets incident and a cost incident. See the OWASP LLM Top 10 LLM10 Unbounded Consumption Guide for the identity requirements in that risk.

Detection and measurement

Cost per identity: tokens and spend per key, user, tenant and agent, with alerts on deviation from that identity's own baseline. See Cloud Cost Anomalies as Security Signals.
Request shape: distribution of input length, requested output length and processing time; heavy tails point to .001.
Agent traces: steps per task, tool calls per task, fan-out width and delegation depth; repeated identical tool calls point to .002.
Limit hits: 429 and quota responses per identity; many identities hitting limits together suggests distribution across accounts.
Autoscaling events: scale-outs without a matching business event.

ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring supplies the records these signals depend on.

Metrics

Bounded coverage: share of model calls with an explicit maximum output length.
Attributed spend: share of AI spend attributed to a named identity or tenant.
Agent budget coverage: share of agent workflows with step and cost ceilings enforced by the runtime.
Time to contain: from cost anomaly alert to suspension of the responsible key or workflow.
Cost per useful outcome: spend per resolved request or completed task, tracked weekly.

Response

Identify the identity, endpoint or content source driving the cost.
Suspend or throttle that key or workflow rather than the whole service.
For .002, find and remove the injected content from the data the agent reads.
Rotate the key if it may have been stolen, and check whether the case is hijacking rather than harvesting.
Ask the provider about billing review for clearly abusive traffic, and record the incident cost.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	SC-5 Denial-of-service Protection; SC-6 Resource Availability	Limits on consumption by any one user or process
NIST SP 800-53 Rev 5	SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting	Usage and cost telemetry and review
NIST CSF 2.0	PR.IR-04; DE.CM-09	Adequate capacity maintained; runtime monitoring
MITRE ATT&CK	T1499.003 Application Exhaustion Flood; T1496.004 Cloud Service Hijacking	Conventional counterparts; see MITRE ATT&CK T1499 Endpoint Denial of Service
OWASP Top 10 for LLM Applications 2025	LLM10 Unbounded Consumption	Lists Denial of Wallet, Variable-Length Input Flood, Continuous Input Overflow and Resource-Intensive Queries
OWASP API Security Top 10 2023	API4 Unrestricted Resource Consumption	See the OWASP API Top 10 API4 Unrestricted Resource Consumption Guide

Common failure patterns

Rate limits without token limits: request counts are capped but one request can still ask for a maximum-length output.
Limits in the prompt: the agent is told to stop after a number of steps, but nothing in the runtime enforces it.
Shared keys: one key for many apps or tenants, so an abusive caller cannot be cut off without an outage.
Unlimited autoscaling: inference pools scale to whatever traffic arrives.
Budgets as brakes: teams assume a billing budget stops spend when it only sends an alert.
Retries multiplying load: clients retry heavy requests on timeout, doubling the cost of every slow call.

Practitioner checklist

Require authentication on every paid model endpoint.
Issue separate keys or workload identities per application, tenant and agent.
Set rate, burst, concurrency and quota limits per identity.
Set explicit maximum input and output tokens and timeouts on every call.
Enforce step, tool-call, delegation-depth and cost ceilings in the agent runtime.
Cap autoscaling for inference pools.
Alert on cost and token anomalies per identity, not only on total spend.
Red team each sub-technique in an isolated environment and retest after changes.

AML.T0034 Cost Harvesting: Stop Attackers Turning Your AI Bill into a Weapon