What are AI guardrails? The controls that hold when the model has a bad day

AI guardrails are the controls that sit outside a model and keep its behavior inside limits you set, whether or not the model cooperates. The word covers everything from profanity filters to compliance policies. The operator's version: a guardrail is the thing that still works on the day the model is wrong, tired, or talked into something.

• The plain definition. A control that runs outside the model and holds even when the model ignores every instruction you wrote.
• Three places to put one. Before the input, around the output, around the action. Vendors sell the first two off the shelf. Agents live or die on the third.
• What it is not. A sentence in the system prompt. A guardrail has no reader to persuade.
• The test. Ask the agent to do the thing you forbade. If nothing mechanical stops it, you have a rule, not a guardrail.
• The habit. Put the control in the object: the hook before the command, the campaign that ships paused, the flag on the deploy skill.

The working version of this definition is the twelve-gate checklist in production-ready AI agents, where gates 5, 6 and 7 are guardrails by another name. This entry is the short form.

The plain definition

Vendors agree on the shape. IBM calls guardrails the "safeguards that keep artificial intelligence (AI) systems operating safely, responsibly and within defined boundaries". F5 calls them "frameworks of policies, technologies, and controls". Truefoundry narrows it to "rule-based controls and filters placed around generative AI systems". None of them says what happens when the model ignores the boundary, and that is the part that matters.

My definition is shorter. A guardrail is a control that works when the model has a bad day. It does not consult the model, and it runs whether the prompt was followed or not.

There are three places to put one. Before the input: filters that keep a bad prompt or an injected instruction from reaching the model. Around the output: checks that keep a bad answer from reaching a person. Around the action: gates that keep a bad action from reaching the world.

A chatbot needs the first two. An AI agent has tools, and a tool is where output stops being text and becomes a deleted table, a sent email, or a spent budget. That is why the action layer is the one that counts for agents.

What do AI guardrails help to prevent?

Three families of damage, one per layer. At the input: prompt injection, pasted secrets, data the model should never see. At the output: fabricated facts, leaked personal data, answers that break a policy. At the action: a dropped table, a message to a real person, budget spent without approval. The first two waste minutes. The third gets someone fired.

What it means in practice

Types of guardrails in AI

Three layers: input guardrails filter what reaches the model, output guardrails check what leaves it, action guardrails gate what the agent may do. Cequence's five are input, output, retrieval, agentic AI and human-in-the-loop, with the agentic kind described as "controls placed around autonomous AI agents that can perform actions". In my map those fold into the three.

The mechanism differs per layer. Input and output guardrails are filters and validators. Action guardrails are structural: a permission rule, a pre-execution hook, a credential that cannot write, an object created paused, a human approval. They are hard to buy because they live in your setup, not in the model path. Across all three sits the release gate, the small evaluation stack I run before a change ships, where an unauthorized tool call fails the run.

AI guardrails examples

One per layer, from my setup. Input: a reporting pipeline that keeps a click id and an amount from a customer record before the agent sees it, and drops names, emails and IP addresses. Output: a validator that rejects any recommendation naming an object id missing from its export. Action: a search data reader holding one read-only scope, plus the three layers below.

How do I implement AI guardrails?

Start at the action layer, where the damage is. List every operation the agent may run that changes something outside the repo. Put that allowlist in code and deny the rest. Add a pre-execution check on the shell. Ship outward objects paused or as drafts. Validate output with something that is not the agent. Then try to break it.

The shell check I use is a pre-execution hook. In Claude Code the event is PreToolUse, which the docs describe as running "Before a tool call executes" and able to block it. The hook can exit with code 2, which blocks the call even if it also prints a JSON allow. Or it prints a hookSpecificOutput object with a permissionDecision of allow, deny, ask or defer and a permissionDecisionReason. deny blocks and shows the reason to the model. ask prompts the human and shows the reason to the human, not the model. The pattern-by-pattern walk through mine is in the PreToolUse post.

deny is for shapes that are never right, ask for shapes that are sometimes right. My hook returns ask for everything on its list, force pushes included, because each of those shapes is something I sometimes run on purpose. A hook that blocks legitimate work gets removed, unless it has an override word. A hook that asks gets kept.

What people get wrong

One example from my own work

Three layers, stacked, in the setup this site's agent runs inside Claude Code. Each catches what the one before it misses.

The first is a flag in a skill's frontmatter. disable-model-invocation: true closes every model-driven path to a skill and leaves it open to a human typing its name. When I audited my skill library, 18 of 55 skills touched something live and the count with the flag set was zero. Eight carry it now. It narrows a path, it does not build a wall.

The second is the hook before every shell command. It reads the whole command string, including whatever sits inside an ssh "..." wrapper, and matches it against thirteen danger patterns plus one document gate: SQL writes, recursive deletes, HTTP mutations, container rebuilds and teardowns, force pushes, hard resets, and the PDF render that signals a document leaving the team. On a hit it returns ask with a reason naming the pattern. On a safe command it prints nothing and exits zero.

The third is the object itself. Campaigns my automation builds on an ad platform come out of the code paused, and turning one on is a separate human act. The outreach sender defaults to a dry run that stops at drafts. The model can call the skill, slip past the pattern list, and create the campaign, and it still spends nothing until a person flips it. A guardrail that lives in the object survives the operator's day off. One that lives in the operator's discipline does not.

Where to go deeper

Why output guardrails exist is in what is an AI hallucination: fluent, confident, false output needs a check from outside the model. The full checklist is the twelve gates; the flag, the hook and the release gate have their own posts.

Sources, all read on 30 August 2026: IBM (quoted from the search snippet, the page refused a direct fetch), F5, Truefoundry, Cequence, the PreToolUse section of the Claude Code hooks reference, and my own hook script, read from disk.