Guardrails are the runtime's safety net. They sit BETWEEN the agent and the action - if the agent tries to do something a guardrail forbids, the action never happens. Per-agent guardrails can be overridden by a Publish-time tenant default, so a SaaS Admin can ratchet down agent permissions across the whole tenant from one place.
Built-in guardrails
- max_approval_amount - the agent cannot approve invoices/POs above this number; trips HITL
- max_response_size - cap on the size of the agent's final response (per run) to keep costs predictable
- max_tool_calls - cap on how many tool calls the agent can make in one run; trips fail-out
- max_run_duration - wall-clock cap (default 5 minutes)
- require_human_review - HITL trigger condition (see HITL guide)
- content_filter_categories - toggleable: hate/harassment, sexual content, self-harm, weapons, PII detection
Configuring
Agent Builder > Guardrails tab. Each value can be a fixed number or driven by a tenant setting (so your admin can adjust it centrally without re-publishing every agent that uses it).
What happens when a guardrail trips
The runtime pauses the run at the offending node and writes a RunNode with status=guardrail_tripped. Behavior from there depends on the guardrail: approval-amount and confidence-based trips escalate to HITL; tool-call and duration trips fail the run with a structured error; content-filter trips fail the run and write an audit row marked content_blocked.
Tenant defaults set the floor
Admin Settings > Guardrails > Tenant Defaults sets the most-permissive value any agent in the tenant is allowed to use. Per-agent guardrails can ONLY tighten, never loosen, this floor. Useful pattern: SaaS Admin caps max_approval_amount at $100k tenant-wide; individual agents drop it lower for specific verticals.