Every prompt sent to a large language model consumes resources. The application may pay for input tokens, output tokens, retrieval, tool calls, storage, or supporting infrastructure. A normal user rarely thinks about those costs, but an attacker does not need to compromise the model to exploit them. The attacker only needs a path that turns repeated or unusually expensive requests into a bill, a slowdown, or an unavailable service.

This problem is recognized by OWASP as LLM10:2025 Unbounded Consumption. The category covers excessive and uncontrolled inference that can produce denial of service, economic loss, service degradation, and model theft. It expands the traditional idea of resource exhaustion because the damage is not limited to server capacity. A cloud based LLM application can remain technically available while generating costs that make the service commercially unsustainable.

The operational challenge is separating expected growth from abusive consumption. A successful product may naturally receive more prompts, longer conversations, and greater demand from automated customers. Security teams therefore need more than a fixed request ceiling. They need controls that consider the account, device, network, behavior, request complexity, and cumulative cost associated with each source of activity.

Conventional availability controls usually count requests, connections, or bandwidth. LLM workloads add variables such as context length, requested output size, model selection, reasoning depth, retrieval volume, and the number of tools called during one task. Two requests can look identical at the gateway while producing very different compute costs. A simple request counter therefore provides an incomplete view of risk.

Attackers can take advantage of this asymmetry by creating requests that are cheap to send but expensive to process. They may submit large documents, demand long outputs, repeatedly regenerate answers, or trigger workflows that call several models and external services. When the application absorbs the cost, the attacker converts a small amount of traffic into a much larger operational burden.

The risk also includes intellectual property. OWASP describes model extraction and functional model replication as forms of unbounded consumption. An attacker may query an application repeatedly to collect outputs, study decision boundaries, or create synthetic training data for another model. The traffic may stay within ordinary request sizes while its cumulative purpose is abusive.

One common pattern is request flooding across many accounts. Each account remains below a simple quota, but the accounts share devices, infrastructure, timing, or behavioral characteristics. The apparent distribution makes the traffic look like normal customer activity. In reality, the requests may be coordinated by one operator or one automation framework.

Another pattern is cost amplification inside the workflow. A single request may trigger document parsing, retrieval, several model calls, tool execution, and a final answer. If the system allows recursive planning or repeated retries, one user action can create dozens of downstream operations. Without a total action budget, the application may continue spending resources after the original request should have stopped.

A slower pattern involves systematic extraction. The requester varies prompts, records outputs, and gradually maps model behavior. Individual sessions may not appear disruptive, and response times may remain normal. Detection depends on understanding repetition, coverage, account relationships, and whether the activity resembles ordinary use or a structured collection process.

Rate limits remain necessary, but their effectiveness depends on the identity being limited. An IP address is easy to rotate through cloud infrastructure, mobile networks, or proxies. An account can be created again. A browser cookie can be cleared. If every signal is evaluated separately, attackers can spread consumption across many apparently unrelated sources.

Limits also need to reflect cost rather than only request count. Ten short questions may be less expensive than one request with a very large context and several tools. Product teams should calculate a normalized consumption unit that includes tokens, model class, retrieval operations, tool calls, retries, and queue time. That unit can then support budgets at the request, session, account, device, and organization level.

Risk based controls provide another layer. A trusted business customer using a known device may be allowed a larger burst than a newly created account arriving through a suspicious network. The decision should not rely on one signal or automatically punish unfamiliar users. It should combine consumption with evidence about how the session was created and how it is behaving.

The first layer should create hard technical boundaries. Input length, output length, request duration, concurrent operations, queued actions, retries, and total tool calls all need explicit maximums. These controls should be enforced by deterministic application logic, not by asking the model to respect a budget. A model instruction is guidance, while a resource limit must be an enforceable rule.

The second layer should manage cost across time. Daily and monthly budgets can be assigned to users, teams, tenants, models, and workflows. Alerts should fire before the budget is exhausted, and graceful degradation should preserve lower cost functions when premium models or complex tools must be restricted. This prevents one abusive path from taking the entire application offline.

The third layer should monitor patterns. OWASP recommends comprehensive logging, anomaly detection, throttling, access control, and dynamic resource management. Teams should record the request source, model used, estimated and actual cost, tokens, tools, outcome, latency, and enforcement decision. Those records make investigations possible and help refine limits without guessing.

Consumption controls become stronger when the application can connect activity that appears separate. Device intelligence may reveal that many accounts originate from the same environment. Network analysis may identify proxy rotation or infrastructure shared across a campaign. Link analysis can expose relationships among accounts, devices, sessions, and repeated request patterns.

Behavior also matters. Automated interaction often produces timing, navigation, typing, and request sequences that differ from normal customer journeys. A source that creates accounts, immediately sends expensive prompts, and repeats the same workflow may deserve additional friction. The purpose is not to reject every fast user. It is to identify combinations of signals that indicate coordinated or scripted activity.

CrossClassify provides this surrounding risk context. Its bot attack detection capabilities can help identify automated activity across customer facing application journeys. The model gateway should still enforce quotas and resource budgets, while CrossClassify contributes device, behavior, network, and account signals that help the application decide when stricter controls or review are appropriate.

CrossClassify does not replace token limits, cloud budgets, model monitoring, or infrastructure protection. Those controls remain the responsibility of the LLM platform and the application using it. CrossClassify operates at the interaction layer, where an application needs to understand whether requests are associated with a trusted human, expected automation, or suspicious activity.

This distinction matters because not every automated request is malicious. Businesses may intentionally permit agents, integrations, accessibility tools, and approved scripts. A useful risk layer should recognize context instead of treating automation as one undifferentiated category. CrossClassify can provide decision support while the application retains control over the final response, throttle, challenge, or review action.

The integration can begin at account creation, login, or the first LLM request and continue through higher cost actions. Product teams can learn how the signal layer connects to existing flows through CrossClassify integration guidance. This makes consumption defense a continuous process rather than a single gateway rule.

Unbounded consumption turns ordinary model access into an availability, cost, and intellectual property risk. The attacker may flood the service, amplify expensive workflows, distribute requests across accounts, or collect outputs slowly enough to avoid simple thresholds. The visible symptom may be a larger bill long before the application becomes unavailable.

The strongest response combines hard budgets with contextual detection. Teams should limit input and output size, control concurrency, cap tool calls, manage retries, monitor cumulative cost, and degrade gracefully. They should also connect requests to accounts, devices, networks, and behavioral patterns so coordinated activity cannot hide behind superficial distribution.

OWASP provides the application security framework, while runtime fraud intelligence adds evidence about the actor and session behind each request. Together, these controls help preserve access for legitimate customers without giving every account an unlimited path to expensive inference. The goal is sustainable AI usage that remains available, measurable, and resistant to abuse.