Granting an AI Agent a Temporary Budget Increase Without Disabling Cost Controls

Why disabling a limit or editing the baseline fails

Budget limits exist because autonomous agents can loop. OWASP describes Denial of Wallet as an attack that causes excessive API or compute costs through unbounded agent loops. OWASP Cornucopia describes Resource and Budget Abuse as autonomous tool-chaining or recursive planning that exhausts compute budgets, API quotas or financial limits, and it names the lack of a per-session budget, with no cap on API calls, tokens or wall-clock time, as a cause. A migration, backfill or incident response task does not remove that risk. It only needs a larger number.

Two shortcuts are common. The first disables the cost control, which removes the cap exactly when the agent runs its longest and highest-volume work. The second raises the baseline limit, which changes the ceiling for every future session of that agent until someone remembers to restore it. Both leave an untracked exception with no record of who authorized it, for what scope and for how long.

The alternative is to leave the baseline alone and layer a bounded exception on top of it. The effective limit is resolved at runtime. While a valid exception exists, the higher ceiling applies. When it does not, the baseline applies again with no manual step.

What stays enforced at the higher ceiling

The point of a layered exception is that only one number changes. Per-session hard caps and loop termination stay active. OWASP Cornucopia's mitigations for resource exhaustion include a hard cap on tool calls, API requests and tokens per agent session, with the session terminated when the cap is reached. A higher ceiling should still be a cap that terminates the session.

Rate limits are a separate control and should remain independent. The same guidance recommends per-user and per-tenant rate limits applied independently of agent-level limits, so a larger agent budget does not remove protection for the rest of a multi-tenant platform. Tool permissions also stay at least privilege. A budget increase is not a reason to grant wildcard or unrestricted tool access, which OWASP lists among the practices to avoid.

Delegation needs one rule. NIST states that delegated scopes attenuate, so downstream entities cannot claim more authority than the parent. Apply the same logic to budget: a sub-agent should never receive more than the parent's grant, and normally receives less.

There are tradeoffs. Short windows reduce exposure but may force a second request if the task overruns. A tight ceiling can stop a legitimate job midway. Decide in advance what happens to sessions in flight at expiry: terminate them, or let them finish under baseline limits. Whichever you choose, document it and test it.

Evidence an auditor can use, and where runtime enforcement fits

An auditor reviewing an exception needs to confirm two things: that the increase was authorized, and that cost controls were never disabled. The record should therefore hold the requester, the approver, the agent identity and task scope, the new limit, the start and end times, actual usage under the exception, and the expiry or revocation event. These fields are design requirements rather than a published standard. Evidence that enforcement decisions continued throughout the window, including rate limit and tool-permission decisions, is what shows the controls stayed on.

This is easier when the exception is evaluated in the same place that enforces policy. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. Because enforcement happens at runtime, not after the fact, the decisions it makes produce audit-ready evidence as a by-product. The pattern in this guide can be built in other enforcement layers too. What matters is that the ceiling, the approval and the expiry are evaluated where requests are decided.