Skip to content

Guardrails

Guardrails are the operational limits placed on a single agent run to bound its cost, duration, and blast radius. They are the run-level complement to the architectural controls in Controls and the security boundaries in Security & Prompt Injection: controls decide what an agent may do, guardrails decide how far a single run may go before it must stop or escalate.

  1. Maximum reasoning / tool steps. A hard ceiling on loop iterations prevents an unbounded agent from running forever. Long-horizon work should be many short sessions rather than one run that needs a high ceiling (see Runtime Context Management).
  2. Time and token budgets. Every run carries a budget envelope; exceeding it halts the run and routes to review rather than silently spending. Budgets feed Smart Routing and the Economics and Routing model.
  3. Retry limits. Bounded retries prevent a failing task from looping on the same error. Exhausting retries is a recovery trigger, not a silent failure it generates a new issue or escalates.
  4. HITL / auth escalation. When a run hits a high-tier action (see the Controls autonomy ladder) or low confidence, it escalates to a human with a timeout and SLA action so it cannot stall forever.

Why Guardrails Are Not Enough on Their Own

Section titled “Why Guardrails Are Not Enough on Their Own”

Guardrails bound a cooperative agent. They do not stop an injected or misbehaving one from doing damage within its limits a single high-tier action can be catastrophic regardless of step count. That is why guardrails sit alongside, not instead of, the structural controls in Controls and Security: environment separation, action gates the agent cannot self-grant, and egress/credential constraints. Guardrails make a run affordable and bounded; structural controls make it safe.