Your AI agent needs a spend circuit breaker

The first warning is not a security alert. It is a number moving in the wrong direction.

A cloud bill climbs while an agent is still "working." An API credit meter drops faster than expected. A queue fills with jobs that all look technically valid. A CI runner keeps rebuilding the same broken branch because the agent has one more idea to try.

Nobody meant to approve a blank check. The agent got a task, a credential, and a little too much room.

That is the operator problem hiding inside agentic AI. A human can approve a workflow at 2 p.m. and still lose control of its cost profile by 2:17. The agent does not need to be malicious. It only needs a loop, a metered service, and no hard stop.

Security policies decide what an agent may touch. Approval queues decide when a human needs to say yes. Cost needs its own runtime boundary.

Call it a spend circuit breaker.

The DN42 story is funny until it looks like your backlog

In May, Lan Tian published a post titled "AI Agent Bankrupted Their Operator While Trying to Scan DN42". DN42 is a volunteer hobbyist network where people experiment with routing and internet infrastructure without touching the public internet.

According to the post, an AI agent tried to join DN42 so it could scan the network. Its plan was not modest. It described five AWS instances, 20 Gbps target throughput, packet capture, filtering, state tracking, multiple scanning threads, and enough memory and network capacity to make the scan feel "unobtrusive" by finishing quickly.

At one point, the agent reportedly wrote: "The five AWS instances remain provisioned and idle, consuming credits with each passing hour."

That sentence is the whole lesson. The infrastructure was not doing useful work. It was waiting. Waiting was billable.

The story was widely discussed on Hacker News, partly because it had all the ingredients of an internet parable: an overconfident agent, a hobbyist network, expensive cloud resources, and a credit card somewhere in the blast radius.

It is tempting to treat the incident as a joke about one strange agent doing one strange thing.

Operators should resist that temptation.

The business version is more boring and more likely:

• A support agent retries a paid lookup API because the vendor returns intermittent 500s.
• A research agent opens browser sessions all weekend because "no relevant result found" keeps triggering another search.
• A coding agent runs CI again and again after making tiny changes to a failing test.
• A data agent fans out across 900,000 rows when the user meant "sample the file."
• An enrichment agent calls a paid people-data API for every contact in a CRM segment.
• An outbound workflow sends SMS messages because the agent interprets "follow up with leads" too literally.
• An RPA job keeps clicking through a slow web app because it never receives a clean completion signal.

None of these failures require science fiction autonomy. They require ordinary automation with permission to spend.

Cost is not just a finance problem

Teams often treat spend as something finance catches later. That works poorly for agents.

A normal SaaS integration usually has a predictable path. A webhook fires, a job runs, an API call happens, a record updates. You can estimate cost because the workflow is mostly deterministic.

Agents are different. They may plan, retry, branch, call tools, revise their approach, ask another model, open another browser, or loop through a queue. The cost shape depends on runtime behavior.

AWS made this point directly in its June AgentOps guidance for Amazon Bedrock AgentCore. The post says agentic AI creates operational challenges because "agents make unpredictable decisions, costs spiral unexpectedly, and debugging non-deterministic failures seems impossible." It recommends governance, operations, evaluation, and observability practices, including rate limiting per user or agent, token budgeting, cost tracking, budget enforcement, model routing by security policy, and centralized audit trails.

That is the right control surface. Not just "who can call this API?" but "how much can this agent spend while trying?"

A credential can be valid and still be dangerous in context. Microsoft's Agent Control Specification makes a similar point: traditional access control can answer whether a credential may call a resource, but not whether that call is safe given everything the agent has touched in the conversation.

Microsoft's proposed runtime governance model defines intervention points across the agent lifecycle: startup, input, pre-model call, post-model call, pre-tool call, post-tool call, output, and shutdown. At each point, policy can allow, warn, deny, or escalate based on the current runtime snapshot.

Spend control belongs in those same intervention points.

Before the agent calls a paid API, check its quota. Before it starts another CI run, check the run count. Before it provisions a cloud instance, check the budget cap and approval threshold. Before it fans out across a dataset, check row limits and sampling rules.

The bill should not be the first hard boundary the system encounters.

What a spend circuit breaker is

A spend circuit breaker is a short operating policy that sits between an agent loop and metered resources.

It is not a 40-page governance document. It is the practical artifact an operator can hand to engineering, security, finance, and the process owner before an agent receives production credentials.

It names the limits that stop runaway behavior while the system is still running.

A useful spend circuit breaker covers seven things:

1. Budget caps. How much can this agent spend per run, per hour, per day, and per month?
2. Loop limits. How many retries, tool calls, queue items, browser sessions, CI runs, model calls, or rows can it process before stopping?
3. External-service limits. Which cloud services, paid APIs, outbound channels, scanners, scrapers, queues, and data exports can it use?
4. Approval points. What actions require human approval before they run, not after?
5. Kill switches. Who can stop the agent, revoke credentials, pause queues, disable scheduled jobs, or block outbound calls?
6. Receipt logs. Where does the system record every paid call, cloud action, token burn, job spawn, and approval decision?
7. Rollback owners. Who owns cleanup if the agent creates resources, sends messages, modifies records, or starts jobs that need to be reversed?

The artifact should be boring. Boring is good. Boring means the team can read it during an incident.

A spend circuit breaker works best when it is enforced close to the action. Put it near the gateway, tool router, job runner, queue worker, model proxy, or agent runtime. If the policy lives only in a launch review document, the agent cannot hit it at 3 a.m.

This is the same reason tool-call governance matters. We have written about gateway interceptors for agent tool governance, sandbox contracts for agent-written code, and capability routing to avoid giving every agent every tool. Spend belongs beside those controls.

If an agent can reach something metered, the metered thing needs a runtime guard.

The controls operators should ask for

Start with the workflow, not the model.

A support agent has a different cost profile than a coding agent. A research agent has different failure modes than a data export agent. A network automation agent should not share a policy with a CRM enrichment agent.

For each agent, ask what it can spend accidentally.

Can it call a paid API? Can it create cloud resources? Can it run CI, browser automation, or long background jobs? Can it enqueue work for another system? Can it send email, SMS, postal mail, or ads? Can it export data to a warehouse, storage bucket, or third-party platform? Can it scan networks, crawl websites, or fan out over large datasets? Can one run trigger another run?

Then turn the answers into limits.

A paid enrichment agent might get 500 records per run, a daily API cap, a maximum retry count of two per record, and an approval threshold before touching any segment over 5,000 contacts.

A coding agent might get three CI runs per branch before it must summarize the failure and ask for review.

A research agent might get a browser-session cap, a token budget, a source limit, and a shutdown rule if it cannot find new evidence after a fixed number of searches.

A cloud-ops agent might be allowed to inspect resources freely but require approval before creating, resizing, or deleting anything that changes spend.

A queue-processing agent might stop after a failure ratio crosses a threshold, rather than dutifully burning through the entire backlog.

The policy should be concrete enough that a system can enforce it. "Use judgment" is not a circuit breaker. "Deny paid API calls after $25 per run or 1,000 calls per day, whichever comes first" is.

Approval is a threshold, not a vibe

Human approval is useful only if the system knows when to ask.

An AI approval policy should not depend on the agent deciding that something feels risky. Agents are bad at noticing when their own plan has become expensive. The approval point needs to be external to the reasoning loop.

Good approval thresholds sound like this:

• Before provisioning any cloud resource with estimated monthly cost over $50, escalate.
• Before running more than three CI attempts on the same branch, escalate.
• Before calling a paid API more than 100 times in one run, escalate.
• Before sending outbound email or SMS to more than 25 recipients, escalate.
• Before scanning an external network range, escalate.
• Before processing more than 10,000 rows, switch to sampling and request approval for the full run.
• Before continuing after a budget alarm, stop and notify the owner.

The wording matters. "Escalate" means the agent pauses and the system asks a named human to approve, modify, or deny the next step. It does not mean the agent writes a note in a log and keeps going.

A spend circuit breaker should also define who receives the request. The approver for cloud spend may not be the same person who approves outbound messaging or data export. During a real incident, vague ownership becomes delay.

Receipt logs make cost debuggable

If an agent creates a surprise bill, the team needs more than a monthly invoice.

They need a receipt log.

A receipt log records the spend-relevant events in the agent run: model calls, token usage, paid API calls, cloud resources created, queue jobs spawned, browser sessions opened, CI runs triggered, outbound messages sent, approvals requested, approvals granted, and denials enforced.

This log should connect the cost back to the agent, user, workflow, run ID, tool call, and business object.

Without that trail, every incident becomes archaeology.

Apache Burr is useful context here because it treats agent workflows as stateful systems that can be observed, persisted, paused for human input, tested, replayed, and traced step by step. Burr is not a spend-control product by itself, but its framing is right: reliable agents need state, replay, and visibility. You cannot govern a workflow you cannot reconstruct.

The same applies locally. Endpoint telemetry for agents helps teams see what ran, where it ran, and what it touched. Spend telemetry adds the economic trail.

A simple receipt log answers questions finance and operations will ask after the fact:

• Which agent spent the money?
• Which user or schedule started the run?
• Which tool calls drove the cost?
• Which limit should have stopped it?
• Was there an approval?
• Who owned rollback?
• What needs to change before the agent runs again?

If the team cannot answer those questions in minutes, the next version of the workflow should not get broader permissions.

Circuit breakers should fail closed

Spend controls need a bias toward stopping.

If the cost meter is unavailable, stop. If the quota lookup fails, stop. If the approval queue is down, stop. If the agent cannot estimate the blast radius of a tool call, stop. If the receipt log cannot write, stop.

This may feel heavy-handed. It is cheaper than discovering later that "temporary observability issue" also meant "unmetered loop ran for six hours."

Failing closed is especially important for agents connected to services where cost can scale nonlinearly: cloud compute, GPU jobs, model inference, paid enrichment APIs, browser automation, search APIs, CI minutes, storage egress, SMS, email deliverability platforms, ad systems, and data warehouse queries.

A retry loop against a free local function is annoying. A retry loop against a paid vendor API is spend. A retry loop that also writes to an outbound channel is liability.

The circuit breaker should distinguish those cases.

A practical spend circuit breaker checklist

Before an agent touches production credentials, write down the answers.

• What metered services can the agent reach?
• What is the per-run budget cap?
• What is the hourly, daily, and monthly cap?
• What is the token budget?
• How many tool calls can one run make?
• How many retries are allowed per failed operation?
• How many CI runs, browser sessions, queue jobs, or rows are allowed?
• Which actions require approval before execution?
• Who receives each approval request?
• What happens when the approver is unavailable?
• Where are receipt logs stored?
• Do logs include run ID, user, tool, cost estimate, and business object?
• What cloud spend alarms exist outside the agent runtime?
• Who can pause the agent?
• Who can revoke its credentials?
• Who owns cleanup and rollback?
• What test proves the circuit breaker works?
• What happens if the budget service, approval queue, or logging system is down?

The test is not optional. Create a dry run that intentionally crosses the cap. The agent should stop, log the attempted action, notify the owner, and refuse to continue until the policy allows it.

If the test merely sends a warning while the agent keeps running, it is not a circuit breaker. It is a dashboard.

The operator lesson

The DN42 incident is memorable because the image is absurd: an AI agent trying to justify high-throughput cloud infrastructure to scan a hobbyist network while AWS instances sit idle and burn credits.

The lesson is mundane. Agents spend money by acting.

They spend through cloud accounts, API calls, queues, CI jobs, browser sessions, outbound messages, data warehouse queries, and retries that nobody sees until the bill arrives.

Agent runtime governance is already moving toward interception points, audit trails, policy snapshots, and human-in-the-loop pauses. Cost should be first-class in that design, not a finance afterthought.

For teams deploying AI automation, the minimum bar is simple: before an agent gets production credentials, give it a spend circuit breaker.

If you are mapping agent workflows that touch paid APIs, cloud resources, queues, or outbound systems, BaristaLabs can help turn that into a practical operating policy. Our process automation work focuses on useful automation with clear boundaries, approval paths, and telemetry. If you want a second set of eyes on an agent spend boundary, start here.