The important result is the stopping behavior. An agent authorized to research a subject can encounter material that encourages further research, then continue spending resources while apparently performing its assigned job. Security controls therefore need to govern how much work the application can undertake, as well as what information it can access.
Dark Reading also covered Forcepoint’s analysis, describing five forms of excessive AI resource consumption. That provides additional reporting on the research, but neither publication’s coverage constitutes an independent reproduction of the simulation. The detailed 500-call comparison comes from SC Media’s reporting and its conversation with Forcepoint researcher Jyotika Singh.
Forcepoint’s agent-tool fan-out simulation makes the stopping rule visible
The demonstration concerned agent-tool fan-out: a research task branches into additional tasks, which can themselves produce more work. According to SC Media, Forcepoint simulated a research assistant encountering a poisoned source that led it to investigate an excessive number of subtopics. With no recursion limit or call budget, the agent continued until it reached the demonstration’s 500-call ceiling.
A tool call is an action the agent requests through an available tool, rather than simply text in its answer. In Forcepoint’s research scenario, following related material creates opportunities for more such actions. The critical behavior is the agent treating retrieved content as a reason to expand its workload.
Forcepoint’s illustrative attack path involves a poisoned blog post containing a long list of fake related articles. An agent conducting legitimate research follows those references, and the resulting material points it toward still more references. Both SC Media and Dark Reading describe this branching behavior in their coverage of Forcepoint’s analysis. It does not require the attacker to obtain the organization’s billing credentials: the research agent already has permission to consume resources.
The controlled version added a tool-call budget, a recursion-depth limit and an agentic circuit breaker that stopped execution when excessive task fan-out was detected. SC Media reports that this version completed one tool call, with a simulated cost of $0.02. The comparison is useful because it makes the application’s decision to stop measurable.
| Demonstration configuration | Reported tool calls | Simulated cost | Interpretation |
|---|---|---|---|
| No application-level call budget or recursion limit | 500 | $10 | The demonstration ceiling ended the measured activity. |
| Call budget, recursion limit and fan-out circuit breaker | 1 | $0.02 | The safeguards stopped further execution. |
All figures in the table are Forcepoint simulation results reported by SC Media. Singh told the publication that both the 500-call ceiling and the $0.02-per-call cost were demonstration parameters. The supposedly “unbounded” agent was therefore unbounded at the application-control level being illustrated; the experiment itself still had a finite stopping point.
That distinction prevents two misleading conclusions. The $10 figure is not a maximum exposure for a production agent, and $0.02 is not an established market price for agent tool use. Nor does stopping after one call establish that the protected assistant finished a useful research assignment. The reported result demonstrates containment, without supplying a corresponding assessment of research quality.
OWASP’s unbounded-consumption category reaches beyond traffic spikes
OWASP’s 2025 guidance defines unbounded consumption as excessive and uncontrolled inference by a large language model application. Inference is the process of producing outputs from inputs using the trained model. OWASP identifies economic loss, denial of service, service degradation and model theft among the consequences of failing to control that activity.
SC Media and Dark Reading report that the category moved from tenth place in the 2025 Top 10 for LLM Applications to sixth in the 2026 edition. The 2025 OWASP entry directly establishes the earlier position; the September reporting describes the newer ranking and Forcepoint’s use of a 2026 scenario. That movement is a prioritization signal, not a measurement of how frequently organizations have suffered this particular attack.
The fan-out demonstration is one expression of the broader problem. Forcepoint’s analysis describes several ways an application can consume excessive resources, and the differences matter when choosing controls:
- Denial of wallet can begin with a stolen or leaked API credential used to generate large numbers of chargeable requests.
- Agent-tool fan-out can turn retrieved material into a growing chain of additional tool activity.
- Reasoning-loop exhaustion can cause an extended-thinking model to spend excessive effort revisiting an otherwise ordinary question.
- Context accumulation can make successive responses more expensive as a long-running conversation grows.
- Model extraction can use extensive querying to collect outputs that help reproduce aspects of a model’s behavior.
Dark Reading reports all five scenarios as part of Forcepoint’s analysis. OWASP’s 2025 guidance independently covers the broader problems of denial of wallet, resource-intensive queries, model extraction and functional model replication.
These scenarios should not be collapsed into one generic “too many requests” problem. A compromised credential can generate conspicuous volume, while reasoning-loop exhaustion may begin with a short prompt. A long conversation can become costly without malicious involvement. In the fan-out scenario, the attacker influences the material the agent retrieves rather than directly submitting every resulting request.
The operational implication is that successful authentication and ordinary-looking input do not establish an acceptable execution cost. Access control determines who may use a resource; consumption controls determine how much authorized activity the application will permit. Forcepoint’s demonstration concerns the gap between those decisions.
Growing context and branching tasks defeat a single cost metric
Singh told SC Media that removing the demonstration ceiling could produce costs “orders of magnitude” above $10 because one poisoned source can return multiple related items, each leading to further activity. That is a warning about possible branching behavior, not a measured outcome from the published comparison. Forcepoint also told SC Media it had not observed a real-world example of this exact agent-tool fan-out scenario.
Two different dimensions of growth are involved. Fan-out increases the number of branches an agent pursues. Recursion increases how far it follows successive layers of related work. As an architectural inference from that mechanism, limiting depth alone does not necessarily limit the number of first-level tasks, while limiting total calls does not necessarily identify abnormal branching early.
The cost of an individual model interaction can also change during a run. SC Media quotes OWASP’s example in which per-turn cost rises from roughly $0.001 at the beginning to about $0.50 by turn 100 as context accumulates. Those are illustrative figures quoted in the reporting, not provider prices or Forcepoint’s measured tool-call costs.
Dark Reading likewise reports Singh’s example of a lengthy support conversation repeatedly processing its growing history. That account describes a roughly hundredfold increase in per-message cost, rather than the specific progression quoted by SC Media. The examples should remain separate: they support the same general mechanism, but they are not interchangeable measurements.
The useful distinction is between request rate and total consumption. A limit on requests within a time interval constrains one dimension of activity. It does not, by itself, establish a ceiling on the cumulative cost of a long session, the amount of reasoning a model performs, or the tool work generated by a single authorized task.
OWASP’s mitigation guidance reflects that broader scope. Alongside rate limits and user quotas, it recommends resource-allocation management, timeouts, throttling, restrictions on queued and total actions, and monitoring for unusual resource consumption. These controls address different ways work can grow; they are complementary rather than substitutes for one another.
Hard budgets give AI agents a boundary that alerts cannot enforce
Forcepoint recommends hard spending and token-usage limits for users, API keys and teams, according to Dark Reading. SC Media also reports its recommendation for per-key spending caps and circuit breakers that stop runs exceeding step, recursion or cost limits. These are controls over execution, rather than notifications that execution has become expensive.
A budget alert can tell an operator that a threshold has been reached. A hard ceiling must prevent further permitted consumption at the boundary it governs. The practical design question is therefore precise: which component actually stops the agent, and which resources does that stop cover? Calling a notification a “budget” does not establish that it enforces one.
The simulation used several safeguards together, so it does not establish how much protection each supplied independently. A call budget constrains action count; a recursion limit constrains successive layers of work; a circuit breaker detects a condition that warrants termination. Developers should not read the one-call outcome as evidence that any single one of those controls would necessarily reproduce the entire result.
OWASP additionally recommends limiting input size, applying timeouts to resource-intensive operations, and restricting access to networks, internal services and APIs. Those measures narrow the resources an application can consume or reach. Its guidance also calls for graceful degradation under heavy load, maintaining partial functionality where possible instead of allowing complete failure.
There is a real workflow trade-off here. A finite budget can interrupt a legitimate research task before completion. The Forcepoint comparison does not establish an optimal budget, an acceptable research depth or a universal spending threshold. Those choices depend on the task being authorized; the supported lesson is to make the boundary enforceable, rather than to adopt the demonstration’s figures as production defaults.
The sources do not identify a specific agent framework, model version or cloud configuration for applying these controls universally. There is consequently no supported Windows setting, Microsoft 365 policy or Azure switch that can be prescribed from this research alone. This is application-security guidance for teams building or operating tool-using agents, not a product-specific vulnerability advisory.
Enterprise teams should assign ownership before expanding agent autonomy
Teams deploying research agents should review consumption controls before increasing the amount of work those agents may undertake unattended. The most exposed design in this demonstration is an agent allowed to expand its own research from retrieved material without an enforceable overall execution boundary. Organizations can assess that design decision without waiting for evidence of exploitation in their own environment.
Start by distinguishing the scopes of existing limits. Forcepoint’s recommendations cover individual runs, API keys, users and teams; those boundaries answer different questions. A run-level limit constrains one task, while a broader key or team limit addresses consumption shared across multiple tasks. Knowing that some quota exists is less useful than knowing which activity it actually bounds.
Next, connect resource use to the activity that generated it. SC Media reports Singh’s emphasis on attribution by user, key or tool. OWASP independently recommends comprehensive logging, monitoring and anomaly detection for resource consumption. Together, those recommendations support investigating a growing bill alongside the responsible agent activity, rather than treating finance data and security data as unrelated records.
Singh also highlighted the ownership problem: security teams may watch for injection and exfiltration while finance watches cloud expenditure, leaving the connection between agent behavior and cost unexamined. The practical organizational decision is to name who notices abnormal consumption and who has authority to stop it. A circuit breaker supplies a technical boundary; accountable ownership makes the surrounding monitoring actionable.
The most concrete takeaways are:
- Treat the 500-call and $10 result as a bounded simulation, not a prediction of production losses or evidence of an active attack campaign.
- Establish which limits stop an individual agent run and which constrain aggregate consumption by API key, user or team.
- Use call, step, recursion and cost boundaries together where the application can generate additional work from retrieved material.
- Monitor consumption alongside activity, because ordinary request volume can coexist with growing context costs or excessive reasoning.
- Assign responsibility for investigating and stopping runaway activity, rather than relying on a billing alert to find its own owner.
Forcepoint’s simulation supplies a practical acceptance criterion for enterprise agents: a task that keeps discovering more work must still have a defined point at which execution stops. The next deployment decision is whether that boundary is enforced across the agent’s permitted activity and owned by an identifiable team. Giving an assistant more autonomy is easier to justify when the organization has already decided how much work—and spending—that autonomy may authorize.