Guardrails & Safety
Where guards sit on one request (input, each tool call, output and stream), what each may decide, how to budget and overlap their latency, how to count their false blocks before enforcing, and what to do when a guard is down.
Last updated
After this section you can
- Place a guard at each checkpoint and pick its verdicts
- Budget guard latency and count its false blocks before enforcing
- Choose fail-open or fail-closed for each action, with a reason
12
Guardrails & Safety
Where guards sit on one request, what each verdict does, and what happens when a guard is down.
Key idea
A guard is a probabilistic check with a latency, an error rate and a failure policy. Put it where its verdict can still change the outcome, and count its false blocks before you enforce it.
Three checkpoints on one request, each with a fallback
Blue request, amber model, teal checkpoints, red failure path, green output.