Learn · Explained
What are guardrails for an AI agent, and who enforces them?
Published 31 October 2026
Short answer. Guardrails are the limits an AI agent cannot cross, whatever anyone tells it: no payments, no deleting records, nothing sent outside the company without sign-off. They are enforced outside the model, in the agent’s access rights, read-only connections, approval steps and code. The company decides which guardrails an agent has. The systems enforce them, and the operator watches that they hold.
This guide explains how guardrails differ from instructions, where each kind lives, which ones a finance agent needs, and how to test them.
A rule can be argued with; a guardrail cannot
An agent works with two kinds of limit:
| Rules | Guardrails | |
|---|---|---|
| What they say | What to do: follow the bookkeeping policy, use these terms, write in this tone | Where not to go: no payments, no deleting records, nothing outside without sign-off |
| Where they live | In the agent’s instructions | In access rights, connections, approval steps and code |
| Who follows them | The model | The systems around the model |
| Can they be talked around? | Yes, a model can misread or be persuaded | No, the system refuses whatever the model asks |
“Never pay an invoice” written in an agent’s instructions is a rule. An agent whose access cannot make a payment has a guardrail.
Why a prompt is not enough
A model follows its instructions most of the time, but not every time. It can misunderstand a task, and text it reads can steer it. An invoice, an email or a web page can contain words written to make an agent act, which is called prompt injection. The security guidance for AI applications from OWASP says there may be no fool-proof way to prevent it, and recommends enforcing permissions in the systems the agent uses, not leaving the model to decide what is allowed.
So the limits that matter most are the ones the model cannot change.
Where a guardrail lives
| Where | What it stops | Example |
|---|---|---|
| The agent’s own access rights | Everything the agent’s user is not allowed to do | The agent’s user in the accounting system can create draft entries but not approve payments |
| Read-only connections | Changes to data the agent only needs to read | The agent reads the customer list through a read-only connection |
| Approval steps in the business system | A step taking effect before a person approves it | A posting stays a draft until the operator approves it in the accounting system |
| Limits in code | Actions outside fixed bounds | The code that posts only accepts the accounts on a list, below a set amount |
| No route outside | Anything leaving the company unseen | The agent can write a draft email but has no way to send it |
The more of an agent’s limits that sit in access rights and in the systems themselves, the fewer depend on the model behaving.
Guardrails a finance agent needs
A starting list for an agent that works in accounting or finance:
- No payments. The agent’s access cannot make, approve or release a payment.
- No deleting records. Corrections are made with new entries, never by deleting old ones.
- Nothing sent outside without sign-off. Emails to customers, suppliers or authorities wait for the operator.
- No changes to supplier bank details. Changing a supplier’s bank account is a common way to commit invoice fraud, so the agent may read the details but never change them.
- Only the accounts and amounts its job needs. Posting is limited to the accounts on its list, below an amount the operator sets.
Every company’s list is its own; this is where most start.
Who enforces them
| Who | What they do |
|---|---|
| The company | Decides the guardrails for each agent, and controls the access that enforces them |
| The systems | Enforce the guardrails: the accounting system, the cloud and the code refuse what is not allowed |
| Whoever builds the agent | Sets the guardrails up, with your IT, in-house or your IT partner, where access is involved, and tests that they hold |
| The operator | Watches the logbook, handles what the agent was stopped from doing, and raises a guardrail that needs to change |
The access stays the company’s: it can be granted, narrowed or withdrawn at any time.
Test that they hold
Test every guardrail before you rely on it. Evals, repeatable tests that run the agent on known cases, should include the forbidden cases: ask the agent to pay an invoice, delete an entry or send an email, and check that the system refused. Run them before the agent starts, and again after every change of model, rules or access.
Guardrails and sign-off
Guardrails and the three sign-off zones answer different questions. The sign-off zones decide when a person checks a step: “acts alone”, “asks first”, or “the operator signs off”. Guardrails decide what can never happen, in any zone. A step can move to “acts alone” because the guardrails stop it at the edge of its job.
Read When may an AI agent act on its own? and Who is accountable when an AI agent makes an entry?