squidbrake

Guide

AI agent guardrails: input, output and action guardrails compared

By Pulkit Batra · · 4 min read

"Guardrails" now means at least three different things, and most products marketed as AI guardrails only do one of them. If your agent can write to production, the kind you need is the one that is least talked about: the guardrail on actions. Here is how the three kinds differ, and what we measured when we compared approaches on 62 real and realistic agent sessions.

In short

  • Input guardrails filter what goes into the model. Output guardrails filter what comes out as text.
  • Action guardrails decide whether a tool call runs. They sit outside the model, where injected text can't reach them.
  • "Ask for everything" stops harm but held 40 of 41 routine steps in our benchmark. People stop reading.
  • Checking whole sessions stopped 65 of 66 harmful steps while holding 3 routine ones.

Three kinds of guardrail

Where AI agent guardrails sit Input guardrails and output guardrails sit around the model and can be influenced by the content they inspect. Action guardrails sit between the agent and its tools, outside the model's reach, and decide allow, hold or block. INSIDE THE AGENT LOOPOUTSIDE THE MODEL'S REACH Inputguardrail Model Outputguardrail Actionguardrail Tools Filters text: toxicity, PII, jailbreaks, topics.Often a model judging a model, so the same injected textit inspects can talk it round. Probabilistic. Decides on the tool call.Rules and history, not a prompt.Same call, same answer.
Text guardrails decide what the model says. Action guardrails decide what it does. An agent with write access needs the second kind.
  • Input guardrails screen prompts and retrieved content: jailbreak detection, PII redaction, topic limits. Useful for chatbots. They are usually a model judging text, so they share the model's weaknesses.
  • Output guardrails check what the model writes: toxicity, leaked secrets, format, grounding. Useful when text is the product.
  • Action guardrails sit between the agent and its tools and decide whether each call runs, waits for a person, or is refused. When the agent can delete, pay, push or email, this is the layer that matters.

What an action guardrail needs

  • Out of the model's reach. If the guardrail lives in the system prompt, injected text can argue with it. It has to run as a separate process the agent can't edit.
  • Reads the real action. Parse the shell command, the SQL, the API request. rm -rf ./build and rm -rf ~/ are one character apart.
  • Remembers. Single calls look fine; chains don't. Backups off, then a delete. A secret read, then an upload.
  • Has a middle answer. Allow and block aren't enough. Most risky actions are legitimate sometimes; they need a person, with the effect shown.
  • Deterministic. The same call gets the same answer, so you can test it, review it in a pull request and explain it to an auditor.

What we measured

65/66harmful steps stopped, Squidbrake on whole sessions
3/41routine steps held (the false positives)
112times "ask for everything" asked a person
3.9 msmedian decision time, in-process
Five approaches on 62 agent sessionsHarmful steps stopped out of 66: auto-run 0, ask for everything 65, allowlist 53, Squidbrake one step 62, Squidbrake whole session 65. Routine steps held out of 41: 0, 40, 10, 2, 3.Harmful steps stoppedmore is betterAuto-run (no checks)0/66Ask for everythingAsk for everything: 65 of 6665/66Allowlist of dev toolsAllowlist of dev tools: 53 of 6653/66Squidbrake, one stepSquidbrake, one step: 62 of 6662/66Squidbrake, whole sessionSquidbrake, whole session: 65 of 6665/66Routine steps heldfewer is betterAuto-run (no checks)0/41Ask for everythingAsk for everything: 40 of 4140/41Allowlist of dev toolsAllowlist of dev tools: 10 of 4110/41Squidbrake, one stepSquidbrake, one step: 2 of 412/41Squidbrake, whole sessionSquidbrake, whole session: 3 of 413/41
62 agent sessions, 113 steps, each labelled before any approach saw it. Last run 21 October 2026 on Squidbrake 0.14.2. Full method on the benchmark page.
Show as a table
ApproachHarmful stopped (of 66)Routine held (of 41)
Auto-run (no checks)00
Ask for everything6540
Allowlist of dev tools5310
Squidbrake, one step622
Squidbrake, whole session653

Two things stand out. Asking a person about everything stops nearly as much harm, but it held 40 of 41 routine steps and asked 112 times; nobody reads the 112th prompt. An allowlist of common developer tools is quieter but stopped only 53 of 66 harmful steps, because it can't tell a safe curl from one that posts your config to an address a web page named. We kept our 3 false positives in the published numbers rather than tune them away.

Guardrails compared with what you already have

Action guardrailIAMPolicy engine (OPA, Cedar)Text guardrail
Remembers what the agent did beforeYesNoNo, statelessOnly in the prompt
Reads the actual commandYes, parsedAPI action onlyIf you write itAs text
Out of the model's reachYesYesYesOften not
Holds one step for a personYesNoNoAsks in the chat
Shows the effect before approvalRows, resources, commitsNoNoNo

You still want IAM and least privilege. The action guardrail covers what they can't: the gray area where the agent is allowed to do something, but not right now, not this way, or not without someone else agreeing.

Rolling one out

  1. Start in shadow mode: log what would have been held or blocked, change nothing.
  2. After a week, read the would-have-held list. Tune the rules that fired on routine work.
  3. Enforce for irreversible actions first: deletes, destructive SQL, infrastructure, money, outbound messages.
  4. Route approvals to the right people (finance for refunds, the on-call for infra) where they already are, such as Slack or their phone.

FAQ

What are AI agent guardrails?

Controls that limit what an AI agent can do. Input and output guardrails filter text going into and out of the model; action guardrails decide whether each tool call the agent makes is allowed, held for a person or blocked.

What is the difference between LLM guardrails and agent guardrails?

LLM guardrails are mostly about text: what the model is asked and what it says. Agent guardrails add control over actions: commands, API calls, database writes, payments and messages.

Do guardrails use an LLM?

Many input and output guardrails do. Squidbrake does not: decisions come from rules, a command parser and the agent's recent history, so the same call always gets the same answer.

How do you avoid approval fatigue?

Only ask about what can't be undone, show the effect rather than the raw call, and look at sessions instead of single steps. In our benchmark that held 3 of 41 routine steps, against 40 for asking about everything.

Try it on your own agents. pipx install squidbrake, then squidbrake connect all. Start in shadow mode: nothing is blocked in week one, you see what would have been. Quickstart · Benchmark · Book a demo