AI Agent Guardrails: How to Keep Agents Within Bounds

AI agent guardrails are controls that sit around an agent and check what goes in, what comes out and, above all, what the agent is about to do. The most effective ones are ordinary deterministic code and human approval gates, not extra instructions in a prompt. This guide covers the types of guardrail, how to prevent unauthorised actions, and a rollout sequence you can apply this quarter.

TL;DR

• Guardrails are layered checks before, during and after an agent acts. No single check covers every risk.
• Unauthorised actions are stopped by least-privilege permissions, a policy check outside the model, and human approval for anything that sends, books, pays or changes data.
• Start with a narrow mission, a short list of permitted tools and approvals on every write action. Widen autonomy only once the controls have proved themselves.
• Log every proposed action, decision and approver so you can audit and tune the rules.
• Treat the rule set as living software: test it against real traffic and adversarial cases, and review it regularly.

Table of Contents

• What guardrails for AI agents are
• Why instructions in a prompt are not enough
• The main types of AI agent guardrails
• How guardrails work in practice
• How to prevent unauthorised AI actions
• A rollout plan for your first agent
• Common guardrail failures to watch for
• Personal data and privacy when agents act
• Perspective
• Putting guardrails to work with AgentWorks
• Takeaway
• FAQ
• Sources

What guardrails for AI agents are

A chatbot produces text. An agent acts: it reads your inbox, updates a record, drafts and sends a message, books a slot. That shift is why guardrails matter. A wrong sentence is an annoyance, whereas a wrong action can change data or reach a customer.

The World Economic Forum describes guardrails as layers of control around models and agents. They constrain behaviour, validate inputs and outputs, govern access to tools and data, enforce organisational policy and detect abnormal actions before they have real-world consequences. IBM frames them as a mix of policies, technical controls and monitoring.

The aim is not a less capable agent. As Weights & Biases puts it, the goal is to make the agent predictable while keeping its useful autonomy.

One point to settle early: guardrails reduce risk, they do not remove it. McKinsey notes that, like highway barriers, they do not guarantee perfect outcomes, and recommends pairing them with trust frameworks, monitoring and testing. That is why the sections below treat guardrails as one part of a governance system.

Why instructions in a prompt are not enough

A system prompt that says "never email customers without permission" is a request, not a control. The model may follow it nearly always, but nearly always is not an engineering guarantee.

The New Stack explains that guardrails restore that guarantee by wrapping the model in ordinary code. That code checks inputs before they reach the model, outputs before they reach the user, and actions before they execute.

The French cybersecurity agency ANSSI makes the same argument in its guide to securing agentic AI systems. Deterministic controls enforce the safeguards defined by design and constrain nondeterministic model decisions that could exceed them. It adds a warning worth remembering: an authorised action can still cause harm, because an agent can make mistakes, be manipulated or combine permitted operations dangerously.

That last point shapes everything that follows. Permissions alone are not enough. You also need checks on how the permitted actions are used.

The main types of AI agent guardrails

Vendors slice the topic differently, but the categories overlap heavily. The World Economic Forum groups guardrails by where they live:

• Built-in guardrails are embedded during model training.
• Middleware guardrails sit between the model and the application and monitor inputs and outputs.
• Agentic guardrails sit alongside a specific agent and control what it is allowed to do.

Security practitioners tend to slice by surface instead. Sweet Security separates input and prompt guardrails, output and response guardrails, and tool-use, data-access and authorisation guardrails, and notes that no single control covers all three. Orca Security adds agent-level guardrails that apply checks to every step in a plan.

For a team deploying agents rather than training models, the practical map looks like this:

Layer	What it checks	Typical controls
Input	The request and any retrieved content before the model sees it	Scope limits, personal data redaction, prompt injection screening
Reasoning	The plan the agent builds	Step limits, allowed-tool lists, separation of reasoning from execution
Action	The tool call about to run	Permission checks, parameter validation, approval gates
Output	What reaches the user or a downstream system	Schema validation, groundedness checks, leak scanning
Monitoring	Everything, after the fact	Audit logs, alerts, evaluations, kill switches

The action layer is where most business harm is prevented, so it deserves the most design effort.

How guardrails work in practice

A well-built agent run passes through several checkpoints.

Before the model. Input checks can filter off-topic or abusive requests, scan for prompt injection, and redact secrets or personal data. If your agent reads emails or documents, treat that content as untrusted input, because instructions hidden in a file are a classic attack route. Our guides on layered prompt injection defence go deeper on this.

Around the tool call. Tool checks run before each invocation and again on its return, according to The New Stack. Validate the arguments against policy, and raise an exception when they break it. If you connect agents to tools through servers, the same least-privilege logic applies, as we cover in securing MCP servers.

After the model. Output checks validate schemas, classify content, check groundedness and scan for leaked credentials. Failed checks can block, strip the offending content or trigger a retry. For factual accuracy, grounding answers in your own documents helps, and we explain the approach in reducing AI hallucinations.

Keep guardrails fast and layered

Guardrails that block are synchronous, so they add latency to every call. Arize's guidance recommends running cheap deterministic checks first, escalating ambiguous cases to an LLM judge, and preferring redaction to blocking wherever possible. Evaluators, by contrast, run afterwards and never block a user, so they suit slower quality scoring.

Latency is manageable. Research from Reinforced Labs found that running four guardrail checks in parallel rather than in sequence cut median latency from 36.4 ms to 14.6 ms in their tests. Run independent checks side by side.

Layering also matters because every check has blind spots. A prompt injection filter may miss a novel attack, but an output scorer can still flag the harmful result, as the Weights & Biases team observes.

How to prevent unauthorised AI actions

This is the question behind most guardrail projects: how do you make sure the agent never does something nobody approved? Five controls do most of the work.

1. Grant least privilege

Give the agent only the minimum permissions, access and capabilities needed for a specific task, and only for as long as needed, as the World Economic Forum defines it. An agent that drafts replies needs read access to a mailbox and write access to drafts, not permission to send or delete.

2. Classify actions by risk

ANSSI recommends sorting every agent action into one of three categories: autonomous execution, mandatory human approval, and prohibited. It requires human approval for critical actions, particularly those of high-risk AI systems as defined in Article 6 of the EU AI Act.

A simple starting classification:

Action	Suggested class
Read a document, summarise, classify	Autonomous
Draft an email or a record update	Autonomous (draft only)
Send, book, publish, or change customer data	Human approval
Payments, deletions, legal or regulated decisions	Human approval, or prohibited

3. Enforce policy outside the model

ISACA recommends a deterministic policy enforcement point between agent outputs and any system that can act. It should validate the action type, target system, actor identity, authorisation, business rules, risk thresholds and required approvals, according to its 2026 recommendations for securing AI agents. The OWASP AI Agent Security Cheat Sheet is explicit that authorisation belongs in the execution component outside the agent's context, and that a simple "user confirmed" flag is not enough. The component must verify that the approval belongs to the current actor and the exact tool call, is still valid and has not been used already.

4. Require approval that is bound to the action

OWASP recommends action previews before execution, approval bound to the exact action, short-lived authorisation, replay protection, and failing closed when validation fails. The FINOS AI Governance Framework describes the same pattern as an approval gate that holds execution until a person with appropriate authority decides. It adds bounded waiting with deadlines, plus tamper-evident records of the proposed action, the approver and the outcome.

In practice, that means the approver sees exactly what will be sent or changed, and the approval cannot be reused for something else.

5. Keep an audit trail and an off switch

OWASP also recommends clear audit trails and the ability to interrupt and roll back agent operations. ISACA adds global and per-capability kill switches, plus safe fallback modes such as read-only, recommendation-only and manual approval. Our piece on agent observability covers the logs, traces and evaluations that make this practical.

A rollout plan for your first agent

ANSSI's seven principles include limiting autonomy by defining and documenting the agent's mission, inventorying its accesses and capabilities, and expanding autonomy only after verifying that the security measures work. Turn that into steps:

1. Write the mission in one paragraph. What the agent does, for whom and what it must never do.
2. Inventory access. List every tool, mailbox, drive and dataset it can reach. Remove anything the mission does not need.
3. Start in recommendation mode. The agent drafts, a person executes.
4. Add approvals on every write action. Sending, booking and changing data all pass through a human gate.
5. Turn on logging from day one. Record the proposed action, the policy decision, the approver and the timestamp.
6. Test adversarially. ISACA lists jailbreaks, prompt injection, data exfiltration, unsafe tool use, cross-user leakage and guardrail bypass among the scenarios to test, and recommends regression tests for known attack patterns.
7. Widen autonomy gradually. Move low-risk, well-understood actions to autonomous execution only after the logs show the controls working.
8. Put changes under change management. Prompts, models, policy logic and tool permissions should change through a formal process, as ISACA advises.

For policy wording, our prompt governance policy template is a starting point, and the wider AI agent governance framework shows where guardrails fit.

Common guardrail failures to watch for

Guardrails fail in two directions. Too loose, and incidents slip through. Too tight, and legitimate work is blocked until people route around the system, as The New Stack warns. Watch for these patterns:

• Approval fatigue. If every low-risk action needs sign-off, reviewers click through. Reserve approvals for actions that send, book or change data.
• Permissions broader than the task. A shared service account with wide access undermines every other control.
• Controls that live in the prompt. If a rule is not enforced in code outside the model, treat it as a preference.
• Untested rules. Run the rule set against real traffic, tune it with feedback and probe it with red-teaming before someone else does.
• Untrusted content treated as instructions. Emails, web pages and uploaded files can carry hidden commands.

Personal data and privacy when agents act

Agents routinely touch personal data: names in emails, order details in a shop, contact records in a drive. Redacting personal data at the input layer, limiting which data stores an agent can read, and logging access all reduce exposure. If you handle data about people in the UK or EU, map these controls to your obligations under data protection law and involve your data protection officer or legal adviser when an agent processes sensitive categories. Our practical guide to GDPR and AI agents walks through the questions to settle, and the enterprise AI data security checklist turns them into a working list.

Perspective

We build AgentWorks around one conviction: governance multiplied by throughput is what makes an agent worth deploying. Speed without control produces incidents, and control without speed produces shelfware.

That is why approvals are part of the product, not an add-on. Our human-in-the-loop controls require sign-off for any agent action that sends, books or changes data, and audit logs record what was proposed and what was decided. Your reviewers see the action before it happens, and your compliance team sees the history afterwards.

We also think residency is a guardrail. Our servers, AI models and integrations run exclusively within the EU, and our commitment is that data is never used to train models. GDPR and EU AI Act requirements are built into the platform, so oversight is part of the workflow from the first run.

Our advice is to nail the first workflow: one narrow mission, a short tool list, approvals on every write action, then expand once the logs earn your trust.

Erwin

Putting guardrails to work with AgentWorks

If you want these controls without assembling them yourself, AgentWorks lets you configure agents for recurring tasks with approvals, audit logs and sector-ready templates already in place. You can work with several AI models, including Claude, GPT, Gemini and Mistral, and connect tools such as Outlook, Shopify and Google Drive, all within EU infrastructure.

Pricing is usage-based and published. The Free plan costs €0, and the Business plan is €29 per person per month or €290 per person per year. Extra workflow runs are available as one-off purchases between €5 and €400. See the AgentWorks pricing page for details, or explore AI workflows with agents and approvals to see how approval gates fit a real process. For oversight requirements, our guide to EU AI Act Article 14 explains what human oversight looks like in production.

Takeaway

Guardrails are a system, not a feature. Constrain permissions, check actions in code outside the model, put a human on every action that sends, books or changes data, log everything, and widen autonomy only as evidence accumulates.

FAQ

What are guardrails for AI agents?

They are the technical and procedural controls that keep an agent within defined boundaries. They check inputs, outputs and actions, and they translate organisational policy into rules that run automatically. Good guardrails make an agent predictable without removing its usefulness.

What are the different types of AI guardrails?

By location, the World Economic Forum names built-in, middleware and agentic guardrails. By surface, they split into input, output and tool-use or authorisation controls. Most teams deploying agents focus on the action layer, where permissions and approvals sit.

How do I stop an AI agent taking actions it should not?

Combine least-privilege access, a deterministic policy check outside the model, and human approval bound to the exact action for anything high-impact. Add audit logs and a kill switch so you can see and stop behaviour quickly. Fail closed when a check cannot be completed.

Can guardrails make an AI agent completely safe?

No. They reduce risk, and they work best alongside monitoring, testing and governance processes. Regular adversarial testing and rule reviews keep them effective as your agents and threats change.

Sources

• AI Guardrails: How to Adopt AI Agents Safely, World Economic Forum
• What Are AI Guardrails?, IBM
• Understanding guardrails for AI agents, Weights & Biases
• What are AI guardrails?, McKinsey
• Guardrails for AI Agents, The New Stack
• Securing an Agentic AI System, ANSSI
• Guardrails for AI Agents: Types, Benefits & How to Implement, Sweet Security
• AI Guardrails: Essential Safety Controls Explained, Orca Security
• Designing Realtime Guardrails, Arize
• AI Guardrail Latency: Sequential, Parallel, Hedged, Reinforced Labs
• 2026 Cybersecurity Recommendations for Securing AI Agents, ISACA
• AI Agent Security Cheat Sheet, OWASP
• Human-in-the-Loop Action Approval Gate, FINOS AI Governance Framework

Recommended

• AI Agent Governance Framework
• Agent Observability
• Defending Agents Against Prompt Injection

Created with help from BabyLoveGrowth