Unbounded Consumption in LLM Applications
detect, prioritise, remediate

Input token budget

The number of tokens an attacker can place into one prompt. Large file uploads, recursive document expansions, concatenated retrieval windows, and verbose system context all multiply the input side. Most provider pricing is per input token, so the input dimension is a direct cost lever before the model ever generates a reply.

Output token budget

The number of tokens the model is allowed to generate per call. A request for a very long answer, a request to repeat a phrase indefinitely, or a structured-output schema with no maximum length turns one call into thousands of generated tokens. Generation pricing typically exceeds input pricing per token, so the output dimension is the highest unit cost lever.

Provider billing exhaustion

The denial-of-wallet failure mode. The application keys directly into a paid provider account. An attacker who runs many cheap calls or a few extreme calls drains the monthly budget, breaches the spend cap, or triggers an alert that pauses the entire production service for legitimate users.

Request rate and concurrency

The number of in-flight requests one identity, one tenant, or the whole service can hold against the provider. The provider also rate-limits per organisation token. One abusive client can saturate the organisation-wide concurrency budget and starve every other tenant the same key serves.

Tool-call amplification

An agent that can call tools can call them recursively. One user prompt becomes a search call, which feeds a summary call, which calls another agent, which calls a third tool. Each step is a model invocation. Without a per-trace step budget, one prompt spawns a tree of calls that costs orders of magnitude more than the visible request.

Retrieval window expansion

A RAG flow that retrieves top-k documents and pastes them into the prompt has a controlled k by default. Where k is configurable through the request, where the retrieved chunks have no maximum size, or where a tool returns retrieval results that become the next prompt, the input window grows without bound.

GPU and self-hosted inference time

Self-hosted models trade provider bills for owned GPU capacity. An attacker who occupies the inference workers blocks every other request. Long-context prompts on a self-hosted model are the slowest unit of work the service runs, so a few crafted prompts can monopolise an entire fleet.

Background and scheduled inference

Cron jobs, daily summarisers, periodic enrichment, and batch jobs all call the model on schedule. A misconfigured job, a poisoned input table that turns into a long prompt, or a reschedule loop that re-fires on every retry consumes budget against an identity no human is sitting behind to notice.

No per-identity cost or token budget

The application authenticates the user but does not attach a per-user, per-tenant, per-API-key budget that decrements on every call. Spend caps live at the provider organisation level only, so the first identity to abuse the surface exhausts the budget for every other identity.

Client-controlled generation parameters

max_tokens, top_k, top_p, temperature, n (number of completions), and tool-call step counts arrive in the request body and the server passes them through. The client can ask for the maximum output, the maximum retrieval window, or the maximum candidate count, and the application has no opinion.

No rate limit at the application boundary

The team relies on the upstream provider rate limit. Provider rate limits are organisation-wide and reset on a calendar window; they do not separate one tenant from another, do not separate one user from another, and do not protect against bursts within the window. The application boundary is where per-identity limits belong.

Single provider account for many tenants

One billing account, one rate-limit budget, one concurrency pool. A tenant who abuses the surface drags every other tenant into the same throttle and the same suspension. Per-tenant provider accounts, per-tenant API keys, or per-tenant cost pools are the operational separation pattern.

Tool registrations without step or depth limits

An agent can call any registered tool, and any tool can call the model again. No per-trace step budget caps recursion, no maximum depth caps tool composition, and no per-call cost ceiling stops the chain. One user request becomes an unbounded tree of paid invocations.

No visibility into per-request token, cost, or latency

The application logs request counts but not token counts, dollar amounts, or generation latency. The team sees the monthly bill go up but cannot attribute the spend to a feature, a tenant, an endpoint, or a prompt. The detection signal lands in finance before it lands in security.

Automated detection

• SecPortal's code scanning runs against connected repositories and flags LLM provider call sites where the request body forwards client-controlled generation parameters without server-side caps, where the agent loop has no maximum step count or depth limit, where the retrieval helper has no maximum chunk count or chunk size, where the tool registration lacks a per-call cost ceiling, or where the call is missing the per-identity budget decrement
• Authenticated scanning drives the LLM-backed endpoint with payloads that probe each consumption lever: maximum-length prompts, requests for maximum-length outputs, recursive tool-call seeds, parameter-amplification attempts, and concurrent-request bursts under a real session, then captures the request, the response length, the latency, and any rate-limit or budget signal the application returned as evidence on the finding
• External scanning discovers exposed agent endpoints, public chat surfaces, free-tier API keys leaked through client-side code, and webhook callbacks that may invoke the model without per-identity rate limiting on the verified perimeter
• Continuous monitoring re-runs the consumption-probe payload on a defined cadence so a new endpoint, a regressed rate-limit configuration, a removed per-identity budget, or a parameter the server stopped clamping is caught against the previous baseline rather than waiting for the next pentest cycle

Manual testing

• Enumerate every LLM-backed endpoint, the model used, the provider, the credential the call runs under, the per-identity budget that decrements on each call, and the per-trace step budget for agent flows
• For each endpoint, send a request with maximum-allowed input length, then with a request for maximum output length, then with the largest retrieval window the parameters accept, and confirm whether the server clamps, truncates, refuses, or simply forwards
• For agent flows, submit a prompt that seeds a recursive tool-call chain (one tool calls another tool that calls the model again) and trace the resulting call graph to confirm a maximum step count, a maximum depth, and a per-trace cost cap actually exist
• From one identity, fire concurrent requests up to and past the documented rate limit and confirm whether the rate limit is per identity, per tenant, per organisation-wide provider key, or absent
• Read the activity log for the test session and confirm that each model call captures input token count, output token count, the dollar amount the provider invoiced, the latency, the model name, the actor identity, and the time stamp a finance or security responder would need to attribute the spend

Finding record with prompt, parameters, and observed cost

The finding captures the prompt that triggered the abuse probe, the parameters the request sent, the input token count, the output token count, the latency, the dollar cost the provider invoiced, the model, and the actor identity. The evidence is what AppSec, AI engineering, and security operations need to reproduce the abuse against the same surrounding code path and the same cost model.

Code scanning across LLM provider call sites

Code scanning runs against connected GitHub, GitLab, and Bitbucket repositories. Findings surface at provider call sites where client-supplied generation parameters reach the server without clamping, where the agent loop has no maximum step or depth, where the retrieval helper accepts an unbounded top_k, where the tool registration lacks a per-call cost ceiling, or where the per-identity budget decrement is missing.

Authenticated scanning with consumption probes

Authenticated scanning drives the LLM-backed endpoint with a curated set of consumption payloads under a real session: maximum-length prompts, maximum-length output requests, recursive tool-call seeds, retrieval-window expansion, and concurrent-request bursts. Each probe records whether the server clamped, refused, or forwarded, and how much budget the call actually consumed.

Continuous monitoring against regression

Continuous monitoring re-runs the consumption probe on the configured cadence. A new model with different per-token pricing, a regressed rate-limit configuration, a removed per-identity budget decrement, or a parameter the server stopped clamping shows up against the baseline rather than waiting for the next manual review.

Retest after the remediation ships

Once the fix deploys (parameters clamped, per-identity budgets wired, per-trace step caps added, per-tenant key separation in place), a targeted retest replays the original consumption probe against the new surface and records the post-fix response on the finding. The finding closes against the evidence rather than against a developer assertion that the surface is now bounded.

AI-assisted writeups with explicit honest scope

AI reports generate the writeup, the executive summary, and the developer-facing reproduction steps from the finding record. The narrative stays within the verified evidence (the prompt, the parameters, the token counts, the cost, the actor identity) and does not invent rate-limit middleware, AI-gateway behaviour, or provider integrations the product does not have.

Activity log for the cost-event audit trail

The workspace activity log captures the security-side audit trail: who created the finding, who suppressed it, who closed it, who approved a related exception, and when the retest fired. Pair the workspace activity log with the engineering-side per-call cost log the application writes (input tokens, output tokens, dollars, latency, identity) so post-incident reconstruction reads from both records.

Finding overrides for sanctioned high-budget calls

Where a high-token call is a deliberate, sanctioned workload (batch summarisation, scheduled enrichment, internal-only report generation), finding overrides record the suppression rationale, the owner, and the expiry on the finding itself. The exception lives on the operating record alongside every other documented deviation.

Compliance tracking pairs the fix to control evidence

Compliance tracking maps unbounded-consumption findings to the controls that read against them (ISO 27001 A.5.30 ICT readiness for business continuity, A.8.6 capacity management, A.8.20 networks security; SOC 2 A1.1 capacity availability, CC7.2 system monitoring; NIST 800-53 SC-5 denial-of-service protection, SC-6 resource availability, AU-12 audit record generation; NIST AI RMF Manage; ISO/IEC 42001 AI management system; NIST SSDF PW.5 secure coding). The same finding feeds the engineering ticket and the auditor evidence pack.