AI Agent Guardrails

Concretely, a guardrail is something like: blocking certain tool calls outright, validating an agent's output against a fixed schema before it's used, or requiring human approval before a high-risk action executes. What these have in common is that the check runs on its own — it doesn't depend on the agent itself deciding, mid-task, that something is a bad idea.

That independence is the point. Relying solely on a model to reason its way to safe behavior is fragile: models make mistakes, can be misled by content they read (see agent-safety on prompt injection), or simply misjudge the boundaries of a task. A guardrail sits between the agent's reasoning and the actual execution of an action, so a flawed decision doesn't automatically become a real-world action.

Guardrail support has become a fairly standard feature across the space — many agent platforms and orchestration tools now ship built-in guardrail options, typically as configurable rules or policies rather than something a team has to hand-code from scratch.

How it works

Mechanically, a guardrail check usually sits between the step where an agent proposes an action and the step where that action actually runs. The proposed action is checked against a policy — is this tool call on an allowlist, does the output match the expected schema, does this fall into a category that needs human sign-off — and only proceeds to execution if it passes; otherwise it's blocked, modified, or routed to a person.

Example

rule: deny tool_call "send_email"
  unless recipient_domain in allowlist

rule: require_approval
  when action.risk_level == "high"

How it differs

Common misconceptions

FAQ