Most teams evaluating AI agents ask the wrong first question. They ask what the agent can do. The question that decides whether you can run the thing in production is narrower: what happens in the milliseconds between the model naming an action and that action touching a real record. Everything worth calling a guardrail lives in that gap.
A guardrail is not a system prompt that asks the model to be careful. A model instruction is a request. A guardrail is code that refuses. The distinction matters because the two are indistinguishable in a demo and completely different in an incident.
The six places a guardrail can sit
An AI agent stack has six distinct control points, and each one catches a failure the others cannot. Evaluate a platform by asking which of the six it actually implements, not by counting how many times the word “safe” appears.
| Control point | What it bounds | The failure it prevents | Question to ask |
|---|---|---|---|
| Input screening | The text that reaches the model | Instructions hidden in a ticket, email or web page the agent reads | Is it on for every call, or is it a setting? |
| Tool grant | Which capabilities exist for this agent | An agent improvising a capability nobody gave it | What happens when the model names a tool it was not granted? |
| Run ceilings | Steps, tokens, time, write actions | A loop that spends money and never terminates | Are the numbers published? Counted per run or per branch? |
| Dispatch check | Every write, at one chokepoint | A second path to a record that skips the rules | How many code paths reach a write? |
| Category lock | Whole classes of action | An autonomy setting someone changed on a Friday | Does the lock survive a human approval? |
| Spend reservation | Credits or cost, before generation | A runaway bill discovered at month end | Is it checked before the call or reconciled after? |
The order is deliberate. Reading down the table is reading the life of a single action: text arrives, a capability is selected, the run consumes resources, a write is attempted, the action class is checked, and the spend is accounted for. A control missing from any row leaves that stage unguarded regardless of how strong the others are.
The tool grant is the strongest control, and the cheapest
The single most effective guardrail is also the least discussed: an agent can only call tools it was explicitly granted, from a fixed catalogue, and a tool it names outside that set is refused rather than improvised.
This works because it is subtractive. Every other control has to decide whether a given action is acceptable, which requires judgement and can be wrong. A tool grant does not judge anything. The capability is either in the set or it is not, and the check happens before the model’s intent is even considered.
The practical consequence is that read-only agents are genuinely safe in a way that no amount of prompt engineering can achieve. An agent holding only read and draft tools cannot alter your business no matter what it concludes, what it was tricked into believing, or how many times it loops. You do not have to trust its reasoning, because its reasoning has nowhere to go.
Run ceilings, and the failure case that explains them
Ceilings look like operational plumbing until you have watched a run without them.
Here is the concrete case. An agent is given the goal “chase every overdue invoice” and granted a send-email tool at full autonomy. Its reasoning loop reads the receivables list, drafts a chase, sends it, then re-reads the list, which still contains the same invoices because payment has not arrived in the last four seconds. Nothing in the loop is wrong. Each individual step is a reasonable inference. The run sends the same customer eleven emails before anyone notices, and the eleventh is the one that ends the relationship.
Three separate ceilings would have stopped it, and it is worth being precise about which:
- A write-action ceiling counted across the whole run, not per branch. Per-branch counting is the common implementation mistake, because a loop simply creates new branches.
- A no-progress detector. Two identical observations in a row is enough evidence that the agent is circling. Ending the run there is cheaper than every mechanism that would otherwise catch it.
- A wall-clock limit, which is the only ceiling that holds when the failure is a slow external call rather than a fast loop.
What happens at the ceiling matters as much as the number. A run that hits a limit should end and hand back to a person with the reason recorded. A run that hits a limit and then produces its best guess at a conclusion has converted a resource guardrail into a quality problem.
A control with a settings toggle is not a guardrail
Here is the position I will defend: any control that can be switched off is a preference, and it should be described as one.
This is not pedantry about vocabulary. It changes what you can assume during an incident. If PII redaction is a setting, then the correct answer to “was customer data sent to the model provider in March?” is “let me check the configuration history”, which is a different answer from “no”. Controls that cannot be disabled produce answers that do not require an investigation.
The corollary is that a vendor should be able to tell you, per control, which category it falls into. Two of Oneop’s are unconditional: every prompt is screened for injection patterns and scrubbed of personal data before it reaches a model, on every plan, with no setting anywhere that turns either one off. Others are deliberate configuration, and the AI governance page marks which is which rather than presenting a single blended promise.
Defaults are a guardrail too
The default state of a dangerous capability is a control, and it is the one most often given away for the sake of a smoother onboarding.
The rule worth adopting: a capability whose misuse is irreversible ships off, and turning it on is a separate, deliberate act performed by someone who knows why. In Oneop, money and stock actions such as posting a bill, issuing a purchase order, placing a credit hold or sending a payment reminder are refused at the single point where every agent action is dispatched, and they stay refused until that entire class is switched on for the workspace. The refusal holds in the most permissive autonomy mode, and it holds even after a person has approved the action, because the check sits below the approval rather than beside it.
That last detail is the one worth copying. A lock that an approval can satisfy is not a lock; it is a confirmation dialog.
What guardrails do not cover
Two honest limits, because a checklist that claims completeness is the least useful kind.
Injection screening is a filter, not a boundary. Pattern-based screening folds obfuscation such as leetspeak and full-width characters before matching, and it runs on every call, but it is best-effort by design. It should never be the only thing standing between untrusted text and a write action. The tool grant is what makes an injection survivable, which is why reducing prompt-injection risk in business AI is mostly a permissions exercise rather than a filtering one.
And guardrails say nothing about whether the action was correct. An agent can operate entirely inside its tool set, under every ceiling, and still send a well-formed, on-brand, completely wrong email. That failure belongs to approval workflow design, not to the guardrail layer.
How Oneop implements the six
Every Oneop agent is configured with a subset of a fixed twenty-tool catalogue, eleven of which read or draft and can change nothing at all. Four ceilings bound every run: six reasoning steps by default with a hard cap of twelve that configuration cannot raise, six thousand tokens, forty-five seconds of wall clock, and three write actions counted across the whole run. Two identical observations in a row ends the run as no-progress. Hitting any ceiling ends the run as escalated with the reason stored, out of nine distinct exit reasons, rather than pushing on to invent a conclusion.
The nine write tools all pass through one governed dispatch function. There is no second path to a record. Credits are reserved atomically before the model call and the reservation has to fit what is left of the month, so a run that cannot be paid for does not begin half-finished. The published numbers and the tool split are on the AI agents page, and the autonomy dial that sits on top of them is covered in suggest, approve, autonomous.
Start every agent read-only. Add one write tool when you can say what it is for, following the sequence in deploying AI agents safely. The guardrail you will rely on most is the one you did not grant.