A guardrail architecture is a documented arrangement of controls around inputs, retrieval, generation, tool use, and downstream effects, where each control names the failure it addresses. The word is used as though it named a product feature. It names a placement problem.
Controls go where they can be enforced
The organising rule is that a control belongs at the boundary capable of enforcing it. Validate data shape where the data is parsed. Constrain tool arguments and access where the tool is dispatched. Check action authority in the system that performs the action.
This rules out the common arrangement, which is instructions in a prompt asking the model not to do things. Injection guidance distinguishes direct inputs from malicious or unintended instructions arriving through external content, and describes mitigations without claiming any foolproof prevention. A control living inside the text the attacker can influence is not a boundary.
It also rules out asking the model whether its own action is permitted. Guidance on excessive agency is direct about this: narrow the tool’s functionality, grant minimum downstream permissions, and enforce authorisation outside the model for every request.
Five boundaries
Input and retrieval. Which content is untrusted, and what can it influence? Retain provenance, the permitted data scope, and injection test cases.
Generated output. Is the structure valid, and is the task result supported? Schema results, semantic checks, and unresolved claims are recorded separately, because passing a schema establishes neither truth nor permission.
Tool dispatch. Is this action, with these arguments, allowed for this request? Retain the authorised intent, the target, the bounded arguments, and evidence of denials.
Downstream service. Does this identity hold only the permission it needs? Retain effective permissions and the results of attempted out-of-scope actions.
Execution and recovery. What happens on timeout, partial completion, or failure of a control itself? Retain correlated outcomes and the correction procedure.
A retrieved invoice carrying an instruction to send funds to a new account illustrates how the layers divide. An assistant whose tool identity cannot initiate payment is prevented from that effect by the fourth boundary. That says nothing about whether the drafted account details are correct, which is the second boundary’s question and needs its own verification of source and destination.
Testing the controls, including their failures
Exercise harmless adversarial fixtures in an authorised environment: instructions embedded in retrieved material, malformed tool arguments, requests outside the permitted identity’s scope. Then test the bypass paths, and test what happens when a control itself fails.
Where a classifier does the filtering, measure both missed cases and incorrect blocks against the actual task. A classifier’s label becoming a new unverified authority is the failure that replaces the one it was added to fix.
Each failure needs a defined consequence — reject, request review, narrow the result, or stop the action. Approvals bind to a concrete target and parameters, and are rechecked when those change, so an approval granted for one action cannot be inherited by a modified one.
Autonomy sets the load
Autonomy level is the parameter deciding how much each boundary has to carry. A system that proposes and a system that acts have identical failure modes and entirely different consequences, so the same control set is adequate at one level and insufficient at the next.
That makes escalation a design event rather than a configuration change. Moving from suggestion to unsupervised action requires rechecking every boundary against the new consequence, and the tool permissions granted during a prototype are the ones that quietly persist.
Human review is a boundary with a workload
Human review is an assigned decision before or after a specified action, with an explicit consequence. Designing it means stating what the reviewer must determine, what evidence they can inspect, and which actions they can stop or change. A post-action audit and a required pre-action decision are different controls.
The empirical position is narrower than the practice assumes. A study on a meal-substitution task with 199 retained participants found that cognitive-forcing conditions reduced overreliance relative to simple explanation conditions, and reported no significant overall performance difference between those categories. Reducing overreliance is a real result. It is not the same result as better decisions.
So the workflow needs measurement rather than assumption: arrival volume, active review time, available reviewer time, queue age, rework, and unresolved escalations. Each queued item carries an identity, the proposed outcome, the source evidence, the relevant uncertainty, the affected party, and a deadline, with approve, correct, reject, and escalate as distinct outcomes.
Two structural rules follow. The approved scope is recorded so that later changed parameters cannot silently inherit the approval. And an absent reviewer triggers a defined hold, a narrower workflow, or escalation — never assent by default.
The rule
What stays fixed is that structure, truth, and permission are checked separately at boundaries that can enforce them. What changes is the autonomy level, and every increase reopens all five.
Not to be confused with
A security standard. These are control questions rather than complete coverage, and no protection rate is established for any of them.
Prevention. Monitoring and rate limits reduce damage after an undesirable action occurs. That is worth having and it is a different function from stopping the action.