Default hard budget caps: the missing control for agent-built software
Coding agents make it trivial to wire up paid APIs and hosting, and a runaway loop can turn into a large bill before an alert email is read. Simon Willison argues that hard, default-on spending caps are now a baseline control, and AWS and Google Cloud have both begun shipping them.
Key Takeaways
- A soft cap that emails a warning is not a control. A hard cap cuts the service off and returns errors once a monthly limit is reached.
- Coding and personal agents lower the friction of deploying code that calls paid APIs, so runaway spend becomes more likely and harder to notice in time.
- AWS and Google Cloud have both introduced cap features, but with different scope and enforcement behaviour, so check the details before relying on either.
- Treat a budget cap as one control on an agent's blast radius, alongside scoped credentials and monitoring.
Simon Willison has made the case that pay-by-usage services and APIs need default hard budget caps: after $X a month, the service is cut off and returns errors. His point is that soft caps, which send a warning email after $X, do not do the job. We think this is right, and that it belongs in the security conversation as well as the finance one.
Why agents change the risk
Coding agents, and the personal agents built on them, reduce the friction of spinning up code that does useful things. Some of those things cost money: calls to paid APIs, or hosting. When a person writes and deploys that code by hand, the effort acts as a natural brake. When an agent does it, the brake is gone, and the person approving the work may not be reading every line or every dependency.
The failure mode is familiar to anyone who has handled cloud incidents: a loop, a leaked key or a misconfigured job consumes paid resources faster than anyone is watching. Willison's concern is that runaway applications can run up large charges before a warning email is acted on.
Why soft caps fail
- Alerts depend on a human. An email at 3am on a weekend is only useful if someone reads it and can act.
- Billing data lags. Warnings tell you about spend that has already happened; they do not stop the next request.
- Defaults decide outcomes. Teams that never configure a limit get no protection, which is why the cap has to be on by default.
Willison also addresses the objection that a hard cap causes service errors. His answer is that most users would choose errors over a surprise bill above $10,000. For opting out, he proposes an explicit, prominent checkbox stating that the application will not be shut down if it exceeds the budget and that the user is responsible for subsequent charges.
What the major clouds now offer
Both large providers have recently moved in this direction, with different designs.
- AWS: spend limits in AWS Settings are described as applying per project. When spending reaches the limit, AWS pauses the project rather than accruing further charges, and work resumes once the owner raises the cap. Help Net Security reports on the sign-up changes around this feature.
- Google Cloud: Spend Caps set a monthly cap on a specific service within a project. Once enforced, new requests to that service in that project are paused until the cap is manually lifted. In public preview, a cap applies to a single project and service, and the mechanism is non-destructive.
The differences matter. A per-service cap leaves other services running, and a per-project pause stops everything in scope. Neither is a substitute for understanding which of your workloads you can afford to have interrupted.
What security teams should do
- 1Enable available hard caps on every account or project where an agent can create resources or call paid APIs.
- 2Set caps per workload and per environment, so a runaway experiment cannot exhaust the production budget.
- 3Keep alerts as a secondary signal, and route them to a channel someone owns.
- 4Scope the credentials agents hold, since a leaked key with no spending ceiling is a billing incident and a security incident at once.
- 5Test what happens when a cap trips, so a pause degrades a feature rather than breaking a critical path.
Willison also suggests that agents themselves should recommend providers that offer hard budget caps and warn inexperienced builders against uncapped services. That is a reasonable guardrail to build into agent instructions and review checklists.
Frequently Asked Questions
What is a hard budget cap?
A hard budget cap is a spending limit on a pay-by-usage service. Once the monthly amount is reached, the service stops and returns errors, rather than only sending a warning email.
Why do AI coding agents make budget caps more important?
Agents reduce the friction of deploying code that calls paid APIs or uses paid hosting, so costs can accumulate faster and with less human review than in hand-written deployments.
Do AWS and Google Cloud offer hard caps?
Both have introduced cap features. AWS describes project spend limits that pause a project at the limit. Google Cloud's Spend Caps, in public preview, restrict a specific service within a project once the monthly cap is reached. Scope and behaviour differ, so read each provider's documentation.
Sources
- 1We're going to need default hard budget caps on pretty much everything — Simon Willison
- 2AWS's new sign-up gives accounts spend caps, email invites, and agent-set permissions — Help Net Security
- 3New early anomalies and spend caps on Google Cloud Budgets — Google Cloud