Loop Guardrails and Safety
This content was developed with AI assistance and is regularly reviewed for accuracy.
Snapshot: October 2026. Model names, prices, and product features change monthly; What's New in AI is the maintained chronology.
A loop runs without you watching. That is the point, and that is the risk. An agent prompting itself for hours can finish a week of chores, or it can repeat the same wrong action a thousand times and hand you the invoice. This guide covers the five guardrails that make an unattended loop safe, what agent teams really cost in tokens, and how to design approvals people will not rubber-stamp.
Learning focus
By the end of this guide, you'll understand:
- Why a budget must be enforced by the runtime, not by a billing alert
- How to estimate a loop's token cost, and why agent teams multiply it
- How containment and approvals work together, and why approvals alone fail
- The failure modes that catch people first, and a pre-flight checklist
Guardrail 1: Budgets the runtime enforces
Every loop needs hard limits on iterations, time, and money, whichever it hits first. The 2026 lesson is that the limit must be enforced by the thing running the loop. An alert that emails you after the spend has happened is a notification, not a brake.
The runaway-spend stories of 2026 make the point. An Australian consultant with a small budget alert and a $1,400 hard cap still received a bill of about $18,000 after an exposed key was abused overnight, because billing data lagged behind usage (reported). A vendor blog described a two-agent loop that bounced messages back and forth for 11 days and cost $47,000 (self-reported, unverified). Neither had a stop condition inside the loop.
Claude Code now ships several runtime brakes, and a loop should use all that apply:
| Brake | What it bounds |
|---|---|
--max-budget-usd on a headless claude -p run | Dollar spend for that run; the run stops at the ceiling |
/loop expiry | Session-scoped loops expire after seven days, so a forgotten loop is bounded |
/goal no-progress stop | The goal check stops after several turns without progress |
| Dynamic workflow caps | Hard cap of 1,000 agents per run, with a warning for runs projected above 25 agents or 1.5 million tokens |
| Routine minimum interval | Cloud Routines fire at most hourly on a schedule |
Add your own limits on top: a maximum number of tasks per run, a wall-clock limit, and a rule to stop after the same failure twice. Set them low at first. You can raise a limit once you trust the loop; you cannot un-spend money.
Guardrail 2: Know the token cost before you scale
Loops spend tokens, the units of text a model reads and writes, on every iteration, and the bill grows in ways that are easy to underestimate. Three numbers from Anthropic's 2026 documentation and engineering posts give you a sense of scale. Enterprise Claude Code use averages about $13 per developer per active day, with 90% of users under $30 a day. A full planner, generator, and evaluator harness for one long application build ran about 6 hours and $200, against about 20 minutes and $9 for a single agent that produced a broken result. And 16 parallel agents building a C compiler over two weeks cost about $20,000 in API usage.
Agent teams are where costs jump. Claude Code's documentation estimates that agent teams use about seven times more tokens than a standard session when teammates run in plan mode, because each teammate carries its own context and the team spends tokens coordinating. That can be worth it for genuinely parallel work. It is waste for a task one agent could do in sequence.
Estimate before you schedule:
cost per run ≈ (tokens per iteration × iterations per run × agents) × price per token
monthly cost ≈ cost per run × runs per month
Then measure. The /usage command attributes spend to skills, subagents, MCP servers, and loops, so after a week you know which part of the harness is expensive. The usual savings come from four habits: send verbose output such as test logs to a subagent so it never fills the main context, clear context between unrelated tasks, use a lower effort setting for routine steps, and choose a single agent over a team unless the work truly divides.
Guardrail 3: Contain the blast radius
Blast radius means everything a loop could damage if it did the worst plausible thing on every iteration. Shrink it before you start, because containment works even when every other guardrail fails.
Run the loop on a branch or a copy, never directly on production or main. Give it the narrowest access it needs: read-only database users, scoped tokens, one repository rather than an organization. Keep credentials out of any file the agent can read; the April 2026 PocketOS incident, in which a coding agent deleted a production database and its backups in about nine seconds, started when the agent found an over-privileged key in an unrelated file. Strip every connector a Routine does not need, because a Routine includes your attached connectors by default. Use an operating-system sandbox and egress controls where your tool offers them; Anthropic reported that its sandbox cut Claude Code permission prompts by 84% while tightening what the agent could reach.
Treat everything the loop reads at run time as untrusted. A webpage, an issue body, an email, or a Slack thread can contain instructions, and an agent may follow them. Claude Code wraps the payload that fires a Routine in a block labeled untrusted for exactly this reason. Containment is what limits the damage when injected instructions get through, and vendors concede they sometimes will.
Guardrail 4: Approvals that resist fatigue
Autonomy is a dial, not a switch. Decide which actions the loop may take alone and which need a person:
- Auto-approve: low-stakes, reversible, easily checked work such as drafting, analysis, or opening a pull request for review.
- Require approval: anything irreversible or outward-facing, such as merging, deploying, sending email, spending, deleting, changing permissions, or touching customer data.
The catch is that people stop reading prompts they see constantly. Anthropic found users approving about 93% of manual permission prompts in Claude Code, which is approval fatigue, not oversight. Its answer was auto mode, a classifier that replaces most per-action prompts, and it published the honest number: a 17% false-negative rate on real overeager actions in a small test set. Neither humans nor classifiers catch everything, which is why containment comes first.
Three design rules make approvals meaningful. Put hard allow and deny rules in the permission system, not in hooks, because the docs describe hooks as best-effort for enforcement. Use a PreToolUse hook as a second line, for example to block rm -rf, and branch protection so an agent cannot push to main. And approve the release rather than every step: the loop writes and tests code all night, and a person approves the merge in the morning.
Guardrail 5: Observability you will read
If you cannot see what the loop did, you cannot trust it. Log each iteration's task, result, and decision; this is the memory component from Anatomy of an Agent Loop doing safety work. Have the loop post a short summary somewhere you actually look, and alert you when it stops, escalates, or hits a limit. For teams, OpenTelemetry trace export for Anthropic's agent platform entered public beta on October 14, 2026, so agent runs can flow into the observability tools you already use.
One rule from the Routines documentation deserves a poster: a green status in the run list does not mean the task in your prompt succeeded. Read the result, not the light.
Failure modes that bite first
| Failure | What happens | Fix |
|---|---|---|
| Runaway loop | No budget stop, so it iterates until someone notices | Runtime budget caps, always |
| Confident wrong success | Weak evaluation marks broken output "done" and repeats it | Objective checks that run outside the agent |
| Doom loop | Fails the same way and retries identically | Stop after two identical failures and escalate |
| Hallucinated checks | The agent claims tests passed that never ran | Grade in CI or a separate evaluator, never self-report |
| Scope creep | Loose task selection grabs work it should not do unattended | Filter the queue; require approval for sensitive work |
| Silent drift | Wrong behavior for days because nobody reads the log | Summaries you read, alerts on stop and escalation |
Pre-flight checklist
Before a loop runs unattended, confirm each of these:
- A runtime-enforced budget: dollars, iterations, and time, plus a stop after repeated failure
- A cost estimate per run and per month, and a single agent unless the work truly divides
- Containment: a branch or copy, scoped credentials kept out of readable files, unneeded connectors removed
- Approval gates on every irreversible or outward-facing action, set in the permission system
- Evaluation outside the agent, plus logs and alerts you will actually read
Finally, watch the loop run once, attended, end to end. If you cannot tick every box, it is not ready to run alone. Agent Safety and Guardrails covers the wider incident record, and Evals for Agents covers building the evaluation step.
Key takeaways
- Budgets must be enforced by the runtime; billing alerts arrive after the money is gone
- Estimate token cost before scheduling, measure with
/usage, and remember agent teams can use about seven times the tokens - Containment comes first: branches, least-privilege credentials, no secrets in readable files, untrusted input treated as untrusted
- Approvals fatigue quickly, so gate the release and the irreversible, and put hard rules in the permission system
- A green status is not success; read the result
Next steps
Continue to: The Overnight Coding Loop to apply these guardrails to a real loop.
- Wider incident record and controls? Read Agent Safety and Guardrails
- Not sure the task needs a loop at all? Run When a Workflow Beats a Loop
- Setting rules for a whole team? See How to Write an AI Policy (Template)