Guardrails for AI agents are layered runtime controls that check inputs, outputs and tool calls to keep agent behaviour safe and predictable. The recommended approach is defence-in-depth: deterministic checks before the model runs, validation attached to individual tools, output checks after generation, and human-in-the-loop approval for anything with a real-world side effect. Success looks like auditable events, measurable pass and fail rates, and a system that fails closed rather than open.
TL;DR:
- Deterministic guardrails should be used for input validation and only run on the fast, pre-LLM side to prevent unnecessary latency and cost.
- Model-based guardrails are more expensive and should be reserved for cases where deterministic rules cannot detect issues like tone or grounding problems.
- Attach guardrails directly to tools for side effects and prefer blocking mode for high-stakes actions to ensure checks complete before execution.
- Continuous telemetry and red-teaming are essential to monitor guardrail effectiveness and identify new attack vectors in real time.
- Start building guardrails by blocking high-risk actions such as payments or data writes, then expand to data protection and output quality improvements.
Wattleheywattle.comBuild Safer AI ConversationsWattle combines controlled workflows, protected actions, human handoff, and audit events across customer communication channels.Explore Wattle
Table of Contents
- Core guardrail types and where they run in the agent loop
- Middleware, tool guardrails, and how to intercept an agent run
- PII handling, prompt-injection defence, and self-correction in practice
- Telemetry, continuous evaluation, and red‑teaming
- Risk management, documentation, and human oversight
- Practitioner patterns: self-correction loops and a real guardrail stack
- What I’d build first if I were starting from scratch
- Sources
- FAQ
Core guardrail types and where they run in the agent loop
Guardrails split into two families, and mixing them up is one of the most common mistakes engineers make when they first wire safety controls into an agent.
Deterministic guardrails run on fixed rules: regex patterns, JSON schema validation, allow-lists, and simple keyword matching. They’re cheap, fast, and predictable. A deterministic check either passes or fails, with no ambiguity, and it typically adds single-digit milliseconds of latency. That makes it the right tool for anything that runs on every request.
Model-based guardrails use a classifier or a second LLM call to judge something fuzzier, like tone, factual grounding, or whether a response drifted into a policy-sensitive topic. They catch what regex can’t, but they cost real money and add real latency, often hundreds of milliseconds per check. Reserve them for cases where a deterministic rule genuinely can’t do the job.
Where a guardrail sits in the execution flow matters as much as how it’s built. Arthur’s guidance on agent guardrails draws a clean line between pre-LLM and post-LLM checks:
- Pre-LLM (input side): PII redaction before anything touches the model, prompt-injection detection on user input, and basic input format validation. These should be fast and deterministic wherever possible, because they run before you’ve spent any tokens.
- Post-LLM (output side): hallucination and unsupported-claim detection, toxicity and tone checks, and format compliance (does the output match the schema the downstream system expects).
- Mixed placement: some checks, like PII detection, need to run on both sides. A user might paste in a phone number, and the model might also generate one.
Get the placement wrong and you either waste compute checking things twice or, worse, let an unvalidated input reach a tool call that changes a customer record.
Middleware, tool guardrails, and how to intercept an agent run
The architecture question every team eventually asks is: where, mechanically, do these checks live in the code? LangChain’s guardrails documentation answers this with layered middleware interceptors, and it’s the pattern most modern agent frameworks now converge on.
- Start-of-run interceptor. Runs once when the agent receives a request. This is where input validation, PII redaction, and injection screening happen, before the model sees a single token of untrusted content.
- Tool-call interceptor. Fires every time the agent attempts to invoke a function. This is the checkpoint for argument validation, permission checks, and rate limiting on individual actions.
- End-of-run interceptor. Runs on the final output before it reaches the user, catching hallucinations, tone violations, and schema mismatches.
For any tool that performs a side effect, whether that’s sending an email, cancelling a booking, or writing a database row, attach the guardrail directly to the tool instance rather than relying purely on agent-level hooks. This is a subtle but important distinction: agent-level middleware sees the intent to call a tool, but a tool-attached guardrail validates the exact arguments at the boundary where the action actually fires, which closes off race conditions and stops a compromised or confused agent from bypassing checks by calling the function through an unexpected path.
You also need to decide between blocking mode, where the agent waits for the guardrail to finish before proceeding, and parallel mode, where the guardrail runs alongside the model call and only intervenes if it flags something. Blocking mode is safer for anything that touches money, health data, or irreversible actions. Parallel mode saves latency for lower-stakes content checks where a slightly delayed correction is an acceptable trade-off.
Pro Tip: Default every new tool to blocking guardrail mode. Only move it to parallel once you have telemetry proving the tool’s failure modes are low-risk and rare.
PII handling, prompt-injection defence, and self-correction in practice
The gap between “we have guardrails” and “our guardrails actually work” comes down to a handful of tactical decisions.
Start with the cheap wins. Run deterministic PII detection and prompt-injection screening on every input, before it reaches the model. Arthur’s best-practice guidance is explicit that these checks belong on the fast, deterministic side of the pipeline precisely because they run on every single request; adding a slow model-based check here multiplies your latency bill for no real safety gain in most cases.
Where deterministic rules aren’t enough, for instance judging whether a response is actually grounded in retrieved documents, a self-correction loop earns its cost. The pattern is straightforward: detect an unsupported claim, isolate the specific span of text responsible, generate a targeted correction prompt that names the problem, and retry. This loop improves output quality without demanding a human review every single response, and it only escalates to a person when the retry itself fails to resolve the issue.
For anything that changes state in the real world, payments, cancellations, data writes, message sends, build explicit protected-action patterns:
- Require a confirmation step that names the exact action and its exact arguments before execution.
- Add identity verification (a one-time code by SMS or email) for financially sensitive actions specifically.
- Log the confirmation event separately from the action event, so an audit trail shows what was proposed and what was approved.
- Fail closed: if verification can’t complete, hand off to a human rather than proceeding on a best guess.
One number worth building your budget around: model-based checks routinely cost more per call than the deterministic ones they’re meant to backstop. Arthur’s guidance frames this as a scoping decision: apply model-based checks conditionally, only where deterministic logic genuinely can’t do the job, rather than running an expensive classifier on every response by default.
Telemetry, continuous evaluation, and red‑teaming
A guardrail you can’t measure is a guardrail you’re guessing about. Every trigger, every pass, every intervention needs to become telemetry, not just a silent block.
LangChain’s documentation treats this as core to the middleware pattern itself: emit an event for every guardrail decision so pass and fail rates become visible over time, and so a sudden spike in interventions gets flagged as a possible regression or an active attack rather than discovered three weeks later in a support ticket.
At minimum, track:
- Pass and fail rate per guardrail type, trended daily or weekly.
- Intervention reason codes (PII detected, schema mismatch, injection flagged, low grounding score).
- Latency added per guardrail, so you can spot when a model-based check has crept into the hot path.
- Retry counts from the self-correction loop, to check whether it’s actually converging or just looping.
Telemetry catches what you already expected. Red-teaming finds what you didn’t. Google’s safety guidance treats automated red-teaming and continuous preparedness evaluations as essential, not optional, because attackers iterate on jailbreak techniques faster than most internal QA cycles do. Run adversarial prompts against your agent on a schedule, not just before launch, and feed anything that gets through back into your guardrail rules and your eval suite immediately.
Risk management, documentation, and human oversight
Governance isn’t paperwork bolted onto engineering. For anything classed as higher-risk, it’s the difference between a defensible system and one you can’t explain when something goes wrong.
EU Regulation 2024/1689 sets out a risk-based approach that’s become a reference point well beyond its own jurisdiction: high-risk AI uses need a documented risk-management system, human oversight mechanisms, and records that regulators or auditors can actually inspect. Whether or not that specific regulation applies to your deployment, the underlying discipline is worth adopting on its own merits.
Practical governance steps that hold up under scrutiny:
- Maintain versioned documentation for every model, prompt template, and guardrail rule, with change history.
- Keep audit trails for sensitive operations, not just the outcome, but the approval chain that led to it.
- Define who is authorised to approve high-risk overrides, and write that down rather than leaving it to whoever’s online.
- Build staff AI literacy so the humans in the loop actually understand what they’re approving, not just clicking “yes.”
- Escalation paths need to be documented before an incident, not improvised during one.
OpenAI’s frontier safety work makes a related point that scales with model capability: more capable models warrant proportionally stronger safeguards, including isolation and blocking evaluations before deployment, not the same fixed checklist applied regardless of what the system can actually do. Governance should scale with capability, not stay static while capability grows around it.
Practitioner patterns: self-correction loops and a real guardrail stack
Abstract principles are easy to nod along to. The harder part is what the code actually looks like.
The self-correction loop, in practice, follows four steps every time:
- Detect. A post-LLM guardrail flags an unsupported claim, a schema violation, or a grounding failure against retrieved context.
- Isolate. The system identifies the specific span or field responsible, not the whole response, so the correction is targeted rather than a full regeneration.
- Generate a correction prompt. The model receives a new prompt that names exactly what was wrong and asks for a fix, not a generic “try again.”
- Retry and re-check. The corrected output runs back through the same guardrail. If it passes, it ships. If it fails again, it escalates to a human rather than looping indefinitely.
Arthur’s framing of this pattern is that it maintains user experience while enforcing accuracy, the system fixes what it can automatically and only interrupts a person when automated correction genuinely can’t resolve the issue.
For tool guardrails specifically, OpenAI’s approach to guardrails and human review treats sensitive side effects as approval points: the SDK can pause execution, serialise the run state, and wait for a human decision before resuming the exact same run rather than starting over. That resumability matters more than it sounds. Nobody wants an agent that has to restart a five-step booking flow because a human took ninety seconds to approve step three.
An agent that answers a phone call and books an appointment is making dozens of small decisions a minute, but only a handful of them actually change something in the real world. A practical approach to this is to treat those moments differently: routine conversation flows freely, while protected actions, cancelling a job, taking a payment, changing account details, require explicit confirmation of exact arguments, and financially sensitive requests carry mandatory identity verification before they execute. Every sensitive operation logs as an audit event, so a business can see not just what happened, but what was approved and by whom.
That’s the practical shape of guardrails for AI agents in a live, omnichannel system: deterministic checks doing most of the work quietly, and human judgement reserved for the moments that actually warrant it.
What I’d build first if I were starting from scratch
Sequence matters more than completeness. Start by blocking high-risk side effects, payments, cancellations, irreversible writes, because that’s where a failure actually costs someone money or trust. Only after that’s locked down should you turn to protecting sensitive data in transit and at rest, then improving output quality through self-correction, then expanding observability across the whole system.
Add human-in-the-loop approvals the moment an action is expensive to reverse, not after an incident forces your hand. Automated red-teaming deserves a permanent slot on the calendar, monthly at minimum, because attack patterns evolve faster than most teams update their eval suites.
None of this stays effective without organisational habits behind it: scheduled guardrail reviews, periodic audits of what’s actually being logged versus what you think is being logged, and internal SLAs for how fast a flagged intervention gets investigated. A guardrail system without a review cadence quietly decays. Teams that treat this as a consultancy-grade engineering problem, and firms like LogicBranch work specifically in this space, tend to catch drift before it becomes an incident report.
— Christopher
Sources
For teams building this out, start with the primary technical docs rather than secondary summaries. OpenAI’s guardrails and human review guide covers approval interrupts and resumable run state in detail. LangChain’s guardrails documentation is the clearest reference on middleware interception patterns. Regulation (EU) 2024/1689 sets the governance baseline many teams now build toward regardless of jurisdiction. See a live example of guardrails, protected actions, and audit trails in production at Wattle.
FAQ
Are there any guardrails for AI?
Yes. Modern agent frameworks and SDKs support layered guardrails, deterministic input checks, tool-attached validation, output checks, and human approval steps for sensitive actions, rather than relying on the model’s own judgement alone.
How do I implement guardrails for an AI agent?
Start with fast deterministic checks on inputs (PII redaction, injection detection), attach validation directly to any tool that performs a side effect, add post-LLM output checks with a self-correction retry loop, and require human approval for financially sensitive or irreversible actions.
Is there any AI without guardrails?
Technically yes, a raw model call with no validation layer has none, but any agent handling real user data, payments, or side-effecting actions without guardrails carries unmanaged risk and typically fails compliance and audit requirements.
How many types of guardrails are there in AI?
Two core categories: deterministic guardrails (rule-based checks like regex and schema validation) and model-based guardrails (classifiers or secondary model calls), applied at pre-LLM input, tool-call, and post-LLM output points in the agent loop.