Guardrails Are a Design Review, Not a Filter
An agent that can issue refunds, update inventory, or write back to a system of record does not fail in its wording first. It fails in its actions: a refund approved above the limit the business intended, a record changed that should only have been read, a write executed when the instruction was to prepare a draft. A filter placed on the final answer inspects none of that. By the time the text looks wrong, the state of the world has already changed.
That is the mistake we see in how guardrails — the controls that constrain what an AI system may receive, say, and do — are usually discussed: as a screen at the end of the pipeline. Guardrails are not a screen. They are a design review that happens before deployment, and the review produces a stack of controls, each placed where a different kind of failure occurs.
A filter checks text. A stack checks decisions
A production guardrail stack has distinct layers, and conflating them is how gaps form.
Input checks run before the model sees anything: is this request inside the system's permitted scope, does it contain data the system is not allowed to process, is it trying to instruct the system to ignore its own rules? Their job is narrow — keep impermissible material and impermissible requests out.
Tool permissions run at the point of action, and they are the layer that matters most for agents. Each tool an agent can call — reading a record, sending a message, changing a balance, writing to a warehouse system — carries its own permission: which arguments are valid, what limits apply, whether the call is reversible, and whether it may run at all without approval. The framework pattern is now standard: the OpenAI Agents SDK treats input, output, and tool guardrails as separate mechanisms, with approval requirements that pause a run until a person approves or rejects a specific tool call. The permission lives in code around the tool, never in the model's judgement about whether calling it seems reasonable.
Output checks run before anything reaches a user or a downstream system: does the response contain data it should not disclose, does it match the required structure, does it claim an action was taken that the tool layer never executed? Output checks are real, but they are the last layer, not the system.
Human escalation is a layer in its own right, not an admission that the others failed. Some decisions are routed to a person by design — because the amount is high, the action is irreversible, or the case falls outside the patterns the system has evidence for. Escalation works only when it is specific: the person receives the proposed action, the reason it was flagged, and the authority to approve, modify, or reject it. A queue of vague warnings is not a control; it is a delay.
The audit trail closes the stack. Every blocked input, permission denial, approval, and override is recorded with what was requested and which control decided. Without that record, a team cannot answer the first question after an incident: was this a control that failed, or a control that was never designed?
Authority is the layer most teams skip
Input and output checks ask whether content is acceptable. Tool permissions ask a harder question: how much authority should this agent have at all?
A useful way to grade that authority comes from warehouse operations, where actions move physical stock and mistakes are visible. Logistics Reply's LEA AI Agent Authority Model grades agent authority in five levels — Inform, Recommend, Act, Coordinate, and Governed Autonomy — and its stated principle is that an agent should hold the right authority for each task, not maximum autonomy. Authority is extended as operational evidence and trust develop. One of its pre-built agents makes the pattern concrete: it recalculates stock classifications and produces a report, and writes the new classes back to the warehouse system only upon approval. The capability to write exists. The permission to write is gated.
That is the bridge from our previous post on evals. Evals produce evidence: measured performance on real failure modes, held to a regression gate. Evidence is what buys authority. An agent that has demonstrated, on a maintained eval set, that it classifies a bounded category of cases correctly earns the move from Recommend to Act for that category — and for that category only. An agent promoted because a demo went well has been given authority on the strength of an anecdote, and the guardrail stack is where that decision gets reviewed before it costs anything.
The gap this addresses is measurable. In Deloitte's 2026 State of AI in the Enterprise survey, only 21% of respondents reported a mature governance model for agentic AI, even as most expected agent use to expand. Deployment is outrunning the design work that decides what agents are permitted to do.
Policy has to become a control, and a control has to name its source
There is a second design failure above the individual layers: policies that exist as documents but never as enforced controls. A policy that says customer records must not leave a boundary does nothing at the moment an agent assembles a prompt containing them.
The corrective pattern is to convert policy into runtime controls, each traced to the obligation behind it. Archer's Evolv AI Compliance, for example, turns regulations and internal policies into policy-as-code controls enforced on prompts before a model responds, with violations recorded in the customer's system of record. Whatever the vendor, the design questions matter: which obligation requires this control, who approved it, what exactly does it block, and where is the record when it fires? A guardrail that cannot answer those questions is a word list with confidence.
Access control and guardrails separate here too. Authentication establishes who — or what — is acting. It does not establish whether this action, on this record, under this policy, is allowed. A successful login treated as permission for everything an agent can technically do means the first layer was designed and the rest were skipped.
Where guardrails fail
Guardrails have limits, and pretending otherwise produces brittle systems.
They cannot enforce a policy nobody has written down. If the business has never decided its refund limit, no layer will invent it — the design review surfaces that undecided question, which is uncomfortable and exactly the point. They add latency and cost: checks in series slow every request, so the stack must be designed for the risk of each action, not uniformly maximum. Model-based checkers, where one model judges another's output, inherit the judging model's failure modes and need the same calibration against human decisions that eval graders do. And an over-tight stack fails in the opposite direction: legitimate work blocked so often that operators approve reflexively or route around the system, and the control exists on paper only.
Finally, guardrails do not make a bad workflow safe. If a process should not be automated at a given authority level, the correct output of the review is to keep the agent at Inform or Recommend — or not deploy it for that task at all.
The review is the work
Treat guardrails as a filter and you get a system that sounds safe in a demo and acts unsafely in production. Treat them as a design review — layers placed at input, at the tool, at output, and at the human, with authority graded, evidence-based, and auditable — and the questions change. Not "did we add a filter?" but "what is this agent allowed to change, who decided, and what evidence earned it that right?"
Bring us a problem
If your team is about to give an agent real authority — over money, records, or customers — and the guardrail conversation is still about word lists, the design review has not happened yet. Start with Trida AI's intake — a few questions, then talk with founders and experts from Trida AI.