AI Agent Guardrails (2026): Deciding What It's Allowed to Do

Your agent works. It read the demo ticket, looked up the order, drafted a reply that sounded like your best support person, and offered a refund. Then somebody asked the only question that matters before you put it live: what is it allowed to do on its own?

In most builds we review, the answer is a paragraph in the system prompt. "Never issue refunds over $50. Always escalate angry customers. Don't share other customers' details." That paragraph is a request, not a guardrail. The model will honour it most of the time, and you wouldn't accept most of the time from a payment system.

This article is about how you decide what your agent may do without asking you, what it must ask you about, and what it must never be able to do at all, in numbers you can hold a supplier to. It's the operational half of a decision that the evaluation article covers from the other side. That one tells you how to find out how often your agent is wrong. This one tells you what to do with the answer.

A rule in the prompt is a request. A rule in the code is a guardrail

Three things get lumped together under the word guardrail, and you build them in different places.

A permission decides which actions exist for the agent at all. If you never give it a refund tool, no prompt injection on earth can issue a refund. A gate decides which of the actions that do exist pause for a person. A limit decides how much and how fast: the largest refund, the most calls in an hour, the most turns a run may take before it's stopped. Logging is the fourth thing, and it's what lets you check the other three instead of assuming them.

Both major labs agree on where these live. OpenAI's guide to building agents tells you to rate every tool low, medium or high on read-versus-write access, reversibility, the permissions it needs and its financial impact. The rating decides whether a tool pauses or escalates before it runs. Its developer docs add a line worth pinning above your desk: put validation next to the tool that creates the side effect, not only in the model's instructions. Anthropic recommends stopping conditions such as a maximum number of iterations, and extensive testing in sandboxed environments before you trust an agent with anything real.

Our agent development service lists permissions, approval points, logging, fallback paths and clear limits as deliverables, and this is why. A persuasive input can talk a model out of an instruction, and the input is often written by a stranger. Nobody can argue with code. So you put the rules with the highest consequence in code above the model, and you give the prompt the judgement calls that genuinely need judgement.

Rank every action by blast radius

Every action your agent can take sits on one of five rungs, and the rung decides the default permission. What decides the rung isn't how often the agent will get it wrong. It's what happens when it does: who pays, how much, and whether you can undo it. We've called that blast radius across this cluster, and it's the only ranking that survives a real incident.

Rung four is where your real decisions are, because "send" covers everything from a tracking update to a legal position, and those don't belong on the same setting. Split it by message class and decide each class with the line below.

The approval threshold: one line of arithmetic

Here's the rule that sets every gate on rung four, and it fits in a sentence.

The review side is easy. Two minutes of a loaded $22 hour, the same rate as the cost article, is $0.73. The mistake side is whatever it takes to make the customer whole plus the time to notice and fix it, and you know that number better than any benchmark. The error rate is what your test set measured, and you have to measure it per action class, because an agent that's 99% right on tracking questions can be 80% right on returns.

Rearranged, the rule tells you the most a mistake may cost before an action needs a gate: $0.73 divided by the error rate.

Read it against a support agent you've measured at 95%. An order-status reply that's wrong costs you one ten-minute human follow-up, call it $3.67. Expected loss per reply is 18 cents, well under the 73-cent review, so it runs unsupervised and you sample it. A $15 goodwill credit at the same accuracy has an expected loss of 75 cents, just over the line: gate it, or drive the error rate down on that class alone. A $40 refund is $2 of expected loss per action. Gate it without a second thought.

Notice what this does to the usual argument. "The agent is 95% accurate" is neither a reason to let it run nor a reason to stop it. It's a number that, combined with what a mistake costs you, tells you which actions it has earned.

What a hundred clean tests actually earn

The threshold has a second, less comfortable reading. Turn it round and it tells you how accurate the agent must be before you can take a gate away, and you have to prove that accuracy, not assert it. A test set proves less than it feels like it does. The evaluation article works through why; the short version is that a clean run of 100 cases doesn't prove 100%. It proves the true rate is at least 96.3%, with 95% confidence.

So a hundred clean cases earns your agent unsupervised authority over roughly twenty-dollar mistakes. To earn a $73 mistake you need 381 consecutive passes. To earn a $733 one, 3,838. Nobody runs 3,838 test cases, and that's the point. The gate on the refund isn't distrust of your software. It's arithmetic, and it stays until production data, not a test set, supplies the missing zeros.

This is also why "we'll remove the gates once it's proven itself" needs a number attached. Proven to what? Write the error rate that removes each gate next to the gate, and the conversation you have later is a measurement instead of a mood.

Cap the worst hour, not the average one

Gates handle the agent being wrong. Limits handle it being wrong quickly, or being pointed at something by someone else, and the two need different maths. The question for a limit isn't what your agent normally does. It's what it could do before you look.

Take a refund permission capped at $25 per action, ten actions an hour. That reads as conservative. It's $250 an hour. That's $3,000 overnight, and $15,000 across a weekend if the agent goes wrong at five on Friday and nobody's watching. A $500 daily ceiling that stops the agent and pages someone turns the same weekend into $1,500 at worst. The per-action cap protected you against one bad decision. Only the daily ceiling protects you against a bad pattern.

The same logic applies to the agent's own bill. Every turn in an agent loop re-sends the whole conversation, so cost grows with the square of the turn count. The six-turn support task from the cost article costs 1.7 cents, a 20-turn run 6.2 cents, and a 100-turn run 65 cents, 38 times the normal price for a run that almost certainly achieved nothing. OWASP calls this loop amplification and lists it under tool misuse. An agent stuck overnight, one run every 30 seconds and a cent for each tool it calls, costs you about $74 with a turn limit of six and about $1,586 with a limit of 100.

The rule of two

Meta published a rule in October 2025 that's the most useful sentence written about agent permissions so far, because it's about design rather than detection. Within one session, an agent should have no more than two of these three properties: it can process untrusted input, it can reach sensitive systems or private data, and it can change state or communicate externally. If it needs all three, in Meta's words, it should not be permitted to operate autonomously and at a minimum requires supervision, through human-in-the-loop approval or another reliable means of validation. The reasoning is blunt. Prompt injection is, in their phrase, a fundamental, unsolved weakness in all LLMs, so you have to design as if the attack works.

Now look at a support agent. It reads your customers' emails, which is untrusted input. It looks up orders, which is private data. It replies, which is communicating externally. That's all three, in every session, by definition. No configuration of a support agent satisfies the rule on its own, so the reliable means of validation has to come from outside the model. The next two examples show you what that looks like.

What CollageDepot decides before the model writes a word

CollageDepot handles over 5,000 support emails a month in four languages, and the part of the pipeline that earns the automation rate runs first. Every inbound email is scored for negative sentiment intensity, urgency language and complexity signals before any reply is drafted. Anything that crosses the defined thresholds bypasses the automation layer entirely: an angry customer threatening a chargeback, a multi-issue complaint with legal language, a VIP account with a high-value order problem. It lands with a person, with the classification and the order context already attached.

Two design choices matter more than the thresholds themselves, and both are things you can ask for. The routing decision is made by a separate step before the reply model runs, so the model that writes the answer never gets to decide whether it should be the one answering. And the thresholds are adjustable from the dashboard, with every stage of the pipeline living as a separately logged node that can be paused or replaced on its own. When the team wants less automation for a week, they turn a dial. Nobody rewrites a prompt and hopes.

The gate that's allowed to stop the line

The strongest guardrail we've designed isn't a judgement. Bella Luxe sells professional lash and brow products from Bergen to salons and private customers through one storefront, and under EU cosmetics rules eyelash dyes are restricted to professional use. Supplying one to a consumer isn't a service failure, it's a regulatory one. So in the process we designed for them, a concept rather than a measured deployment, a professional-only eyelash dye in a consumer basket halts the order. Not downgraded, not substituted, not fulfilled with a note. Held before payment capture and before stock allocation, and routed to a named compliance owner with the complete record attached.

That rule lives in deterministic code above the language model. A persuasive customer message can't talk the process into shipping a restricted product, and a model update can't quietly weaken it. Just as important, the same gate passes a verified professional without friction. Verification means an organisation or VAT number, or a certification on file from Bella Luxe's own training courses, not a customer stating that they run a salon.

The general lesson: find the one decision in your process where being wrong is a legal or financial event rather than an inconvenience, and take it away from the model entirely. The model can gather the facts. You write the rule that decides. In our forecasting agent concept for ProSports, a renewal signal scoring under 0.70 is shown to the reviewer but has no route into the forecast: the accept control is disabled and the underlying function refuses the call.

A setting is not a guardrail

One of our ecommerce clients asked, reasonably, whether order-status replies could send automatically while everything else stayed a draft for review. Order-status was the best-performing category, so it was the obvious place to start. The honest answer, and the one you should expect from anyone you ask, was that this was a build, not a toggle. The send switch in that system was global. Flipping it would have sent every category, including the conversations the classifier had already marked as needing a person. A safe version needs per-category eligibility, a confidence gate for each, monitoring that catches drift within hours, and a rollback that doesn't depend on someone remembering the switch. That's the difference between a setting and a guardrail. A guardrail knows which action it's guarding.

The same test applies to logging. If you can't reconstruct what your agent did last Tuesday, tool by tool, with the inputs it was given and the gate decisions along the way, you don't have guardrails. You have hopes with a dashboard. Log every tool call with its arguments, its result, whether it was gated, and who approved it. The first time a customer disputes what your agent did, that log is the only account of events that isn't a guess.

What to require from whoever builds it

Whether that's us or anyone else, this is the guardrail specification you should see written down before an agent touches production. Most of it takes an afternoon.

If working through this list leaves you gating most of what the agent does, that's information. An agent whose every action needs you isn't an agent, it's a slow form. When an agent is the wrong tool covers that decision; the short version is that a workflow with the model doing one job inside it needs far fewer guardrails, because it can only take the path you drew.

Frequently Asked Questions