Rodrigo Jorge · Prepared November 4, 2026, at 5:57 a.m. Brasília time (UTC-3). Publication time to be confirmed.
An alert triggers a search. The search finds more indicators, which generate new queries. The agent splits the analysis into parallel tasks. Every call stays within its size and duration limits. Yet the investigation keeps generating more work.
This is a hypothetical scenario. It does not require the agent to receive a malicious instruction. An overly broad expansion rule can drive excessive consumption from legitimate inputs. An attacker might also try to exploit this path, but demonstrating that capability would require testing the integration.
OWASP addresses uncontrolled consumption in LLM10:2025, Unbounded Consumption. Its recommended measures include per-user quotas, timeouts, and limits on total and queued actions. The operational point is that availability and financial consumption also belong in an AI application's security assessment.
For an investigation, I would distinguish three questions:
- How much can one call consume?
- How much work can the entire investigation accumulate?
- How much can all investigations for that user or integration consume together?
One limit does not automatically answer the other questions. A per-minute quota may let an investigation run for a long time. A per-investigation cap may allow many investigations to run simultaneously. Scope is part of the control.
Child tasks do not get a fresh budget
I propose tying searches, retries, and delegated tasks to the identifier of the investigation that spawned them. The executor should check the shared remaining budget before admitting more work. If every child task gets an independent budget, delegation can multiply total capacity rather than divide it.
That budget can cover action count, concurrency, total elapsed time, and use of paid services. These are separate dimensions. Limiting output tokens does not bound the cost of external tools. This article recommends no numerical limits: caps need to be selected and evaluated for the specific operation.
AWS documents timeouts for both tasks and the state machine in Step Functions. This is a concrete example of controls at different scopes. It does not mean adopting the service implements the proposed budget, or that a timeout undoes work already sent to another system.
View the diagram: a shared budget across tasks. A proposed architecture, with no measured values or performance results.
The team also needs to define what happens when the budget runs out. I would preserve the evidence already gathered, mark the analysis as incomplete, and prevent new tasks in that workflow until continuation is authorized. Increasing the limit needs an accountable owner and a record. The agent should not be able to raise it because it still has questions.
A useful test is to trigger expansion with synthetic data, including parallel tasks and retries, and check the total work admitted. When only enough budget for one task remains, can two concurrent tasks both get authorization? Checking the counter after execution may reveal the overrun only after the resource has been consumed.
The expected evidence is a refusal to admit new work at the correct scope, along with a record of what happened to tasks already in progress. An investigation stopped by a limit should be recorded as such. Ending the workflow without answering the question is not the same as concluding that no attack occurred.
References
- OWASP: LLM10:2025 Unbounded Consumption, accessed November 4, 2026.
- AWS: Best practices for Step Functions, Using timeouts to avoid stuck executions section, accessed November 4, 2026.