Build AI agent guardrails in 90 days with durable approvals

AI agent guardrails are checks that sit between your agent and the outside world. They stop unsafe or unwanted actions before they happen. The approach that works is layered: input checks, output checks, tool checks and human approvals, each doing a different job. Get it right and every run is auditable. You know what your agent did, why it did it, and who signed off on the risky parts.

What are AI agent guardrails and why do they matter?

Think of guardrails like the bumpers on a bowling lane. The ball still moves freely. It just cannot end up in the gutter.

Guardrails sit at the joints of your system. Between the user and the model. Between the model and your tools. Between your knowledge base and the model. Between your business and the outside world.

Skip them and three things go wrong fast:

• Prompt injection. A hidden instruction buried in a document or a webpage talks your agent into doing something it should not. OWASP ranks this as the number one risk for LLM applications, and notes that retrieval and fine-tuning do not fully fix it.
• Data leakage. Personal details or secrets end up in a reply that goes to the wrong person.
• Hallucination. The agent states something false with total confidence and nobody catches it.

Guardrails work as middleware. They enforce your policy across the whole stack, not just inside the model, which is why IBM frames them as foundational to safe, compliant AI deployment. If your agent touches real customers, real money or real data, guardrails are not polish. They are the reason you can hand the thing to your team and stop watching it.

Where do you put guardrails in an AI agent?

There are four spots. Miss one and you have left a door open.

1. Input guardrails. Check what comes in before it reaches the model. Block injection attempts, catch instructions hidden in uploaded files, reject anything outside scope.
2. Output guardrails. Check what the model wants to say before a human sees it. Redact personal data, catch made-up claims, enforce your format rules.
3. Retrieval guardrails. Check what the agent pulls from your knowledge base before it goes into the prompt. Filter documents this user should not see. Redact sensitive fields.
4. Tool and execution guardrails. Check the command before it runs. This is the one that stops an agent emailing the wrong client or refunding the wrong invoice.

That four-point shape is the standard safety and guardrails pattern in production agent design. It works because each layer catches a failure the others miss.

Pro Tip: One clever prompt does not cover four insertion points. A "be safe" line buried in your system prompt is a suggestion, and agents ignore suggestions under pressure.

What types of AI guardrails should you use?

Three styles. Most working systems run all three, stacked.

• Deterministic guards. Regex, schema validation, allowlists. Fast, cheap, never confused. Ideal for known bad patterns like card numbers or SQL injection strings.
• Model-based guards. A classifier or a model judging content for intent, tone or safety. Slower and pricier. Catches what regex cannot, like sarcasm or a jailbreak phrasing nobody has seen before.
• Custom external guards. Purpose-built checks, often a separate service, for business rules that neither regex nor a generic classifier knows about.

Run the cheap checks first. Escalate to a classifier only for borderline cases. Save the full model judge for the genuinely hard ones. Mixing rule-based and model-based checks matters because a model judge tends to fail in the same blind spot every time. A rule catches what the model misses, and the model catches what the rule cannot express.

Vendor platforms package this. Amazon Bedrock Guardrails ships content moderation, prompt-attack detection, PII redaction and hallucination detection, all set by policy.

Middleware gives you the plumbing. LangChain implements guardrails as before-agent and after-agent hooks, so you can:

• Add a PII filter to every output without touching your agent logic.
• Make human approval its own layer.
• Swap a classifier for a better one later without a rewrite.

Middleware is the kitchen pass. The chef cooks. Someone else checks the plate before it leaves.

How do you build durable human approvals into an agent?

Some actions are too risky for an agent to decide alone. Big refunds. Legal replies. Anything that changes a contract.

Those need a human in the loop, and the approval has to be durable. It survives a lunch break, a weekend, a server restart.

The shape of it:

• The agent pauses and writes its exact state down, not a note saying "waiting for approval".
• That state lands in a queue a reviewer can see.
• The human approves, rejects or edits.
• The run picks up from exactly where it stopped, using the saved state.

OpenAI's guardrails and human review guidance calls this a serialisable state. The run's memory gets written to disk instead of held in RAM, so nothing is lost while a person thinks about it.

Here is the mistake teams make. They hold the paused run in memory and hope the process does not restart. It always restarts eventually. Durable approvals belong in a persistent queue, the same way a job queue holds a print job until the printer is free.

Pro Tip: Put a timeout and an SLA on every approval task. An approval nobody answers is a guardrail that quietly breaks your product.

Our piece on human-in-the-loop AI covers why keeping a person in charge beats full automation on the riskiest calls. If nobody owns those calls yet, start with AI agent governance instead. Ownership before tooling, every time.

How do you stop an agent's tools causing real damage?

Tool guardrails are the last line. This is where a bad decision stops being theoretical and becomes an email sent, a payment made, a record deleted.

Put the check as close to the action as you can. Not at the top of the agent. Right beside the tool call.

What works in practice:

• Argument schemas. Every call gets validated against a strict schema first. No match, no execution.
• Allowlists. The agent calls approved functions with approved parameters. No freeform shell commands. Ever.
• Limits. Set max calls, max turns and timeouts so a confused agent cannot loop forever or hammer an API flat.
• Idempotent design. Build tools so calling them twice with the same input does no extra harm. That makes retries and paused approvals safe.
• A written onFail rule. Decide in advance what happens when a check fails: retry, alert, auto-fix, or escalate to a person.

Treat tool inputs as your primary boundary for writes. Reads rarely cause lasting damage. Writes do.

Our guide on layered AI agent security covers how this stacks with the other three insertion points when several agents share tools. Devwiz has a deeper engineering breakdown in LLM guardrails: a practical architecture for engineers if you want the code-level view.

How do you test and prove guardrails actually work?

A guardrail you have not tested is a guess wearing a hard hat.

Build evals: a set of pass and fail cases covering unsafe inputs, borderline requests and clean ones. Run them every time you change a prompt, a model or a rule.

Two things must always hold:

• A blocked input never reaches a tool.
• A blocked output never reaches a user.

Check both the blocked and the passing flows. Confirm guardrail events show up in your execution history. Confirm a resumed run picks up correctly after approval.

Test type	What it checks	When to run
Unsafe input vectors	Injection, jailbreaks, malicious files	Every deploy, plus scheduled regression
Borderline cases	Ambiguous requests near the policy line	Every deploy
Tool argument fuzzing	Schema rejects malformed calls	Every deploy
Approval resume test	Paused run resumes with correct state	Weekly, or on middleware change

Log everything. Audit trails let you reconstruct exactly why a guardrail fired, which matters the first time a customer asks why your AI did that. Tools like Interval AI exist for this testing and observability layer, so you are not stitching logs together yourself. Our notes on AI agent observability cover which numbers to watch once it is running.

What do guardrails cost in latency and false positives?

Nothing here is free. Every check costs something. Usually speed, sometimes money, occasionally a false alarm that annoys a real customer.

Model-based checks are the expensive ones. A classifier call adds latency. A full model judge adds more. Run the deterministic checks first and only escalate when you have to.

Plan for four trade-offs:

• Latency. Stack too many model checks in sequence and the agent feels slow. Run independent checks in parallel.
• Cost. Every classifier and judge call is a bill. Gate the expensive checks behind cheap ones.
• False positives. Too strict and you block real requests, which frustrates real users fast.
• Drift. Attackers change tactics. A guardrail tuned for last year's jailbreak misses this year's.

Layered defence matters more for anything customers touch than for internal tools your own team runs. Internal tools can often run lighter checks than a system strangers can poke at. Watch your false-positive rate the way you watch error rate. If it climbs, retune the guardrail. Do not remove it.

What does a guardrail release checklist look like?

Run through this before anything ships. Treat it as a pre-flight check, not a suggestion.

1. Run the full test suite. Input, output, tool and retrieval, all against pass and fail cases.
2. Confirm observability is live. Event streams, audit logs and alerts wired before go-live, not after.
3. Write the reviewer runbook. An approver needs to know exactly what to check and how fast to answer.
4. Set the SLA. Decide how long an approval can sit before it times out or escalates.
5. Schedule drift checks. Re-test on a set date, not just when something breaks.

Stage	What to check	Owner
Pre-deploy	Full guardrail test suite passes	Engineering
Pre-deploy	Reviewer runbook written and shared	Product/Ops
Live	Audit logs and alerts firing correctly	Engineering
Post-deploy	False-positive rate tracked weekly	Engineering
Post-deploy	Incident drill run quarterly	Ops

Our notes on wiring AI systems together go further into the monitoring layer if you want the build detail.

What does this look like in a real 90-day build?

Here is how we do it for a real business, not a demo.

We build with Claude Code, and the deliverable is an AI Operating System: a set of AI employees that carry the founder's IP and decisions across the business. Guardrails are not a layer we add later. They are how each AI employee is defined.

That choice is practical, not ideological. Claude Code already has the tool boundary built in. A PreToolUse hook runs before any tool call and can block it, returning a deny decision from your own script. So the "put the check next to the tool call" rule stops being architecture you have to design and becomes a config file you write. Generic no-code tools like Zapier or n8n still have a place for a simple trigger, but they give you nowhere to put that check.

The 90-day build runs Explore, Map, Transform:

• Explore. We find the decisions the founder still makes by hand, and which ones cost real money if an agent gets them wrong. That list is the guardrail roadmap.
• Map. We write the founder's actual rules down. Not vibes. The real if-this-then-that logic behind lead handling, onboarding and coaching replies. That becomes the policy each AI employee enforces.
• Transform. We build the agent network with checks at every tool call, and an approval dashboard for the risky ones. The founder or their team approves or edits, and the run resumes exactly where it stopped.

What founders actually feel: they stop double-checking their own AI, because the checking is built in.

More on the build itself in custom AI delivery systems with Claude Code. For turning a founder's rules into enforceable policy, read our AI policy development guide, or our piece on multi-agent systems if you are running more than one agent across the business.

What we have learnt building guardrails that hold up

The biggest mistake we see: treating guardrails as a one-time build. Bolt on a filter, tick the box, move on.

That is backwards. Guardrails need the same ongoing attention as your monitoring. Attackers change tactics. Your business changes too. A rule written for last quarter's edge cases will not catch next quarter's.

The second mistake is quieter, and worse. Staff start using AI on their own before anyone writes a rule, and there is nothing to guard because nobody knows what is running. Njin's piece on shadow AI already inside your business is a fair description of how that arrives.

If you are starting from scratch, do not try to guard everything at once. Pick the single riskiest action your agent can take, the one that costs real money or real trust, and build a proper approval loop for that. The rest can follow.

The next step is simple. Write down every action your agent can take, then mark which ones need a human before they fire. That list is your guardrail roadmap.

James Killick

Want someone to build this with you?

You have just read how the plumbing works. Building it inside a real business, with real client data and real money on the line, is a different job.

The AI Orchestrators is the alternative to hiring a string of contractors or piecing it together with generic no-code tools. We build the guardrails, approvals and dashboards into your agent network from day one, not as a bolt-on after something breaks.

Our 90-day program is built for founder-led coaching and consulting businesses doing $1M+ a year, the kind with a proven method that only lives in the founder's head. We map that method, then build the AI employees, tool guardrails and approval dashboard around it, so your team can run it without you in every decision.

If that sounds like your business, start with our assessment: how monetisable is your IP? It takes a few minutes and shows where you are ready to scale with AI, and where you still need guardrails you have not built.

Sources

• Guardrails, Safety and Guardrails Pattern | GenAI Patterns
• What Are AI Guardrails? | IBM
• LLM01:2025 Prompt Injection | OWASP GenAI Security Project
• Guardrails and human review | OpenAI API
• Generative AI Data Governance, Amazon Bedrock Guardrails, AWS
• Guardrails | LangChain Docs
• Agent guardrails | Orkes developer guide
• Hooks reference | Claude Code Docs