Guide · agent governance
AI agent guardrails: the four layers that actually constrain an agent
Most 'guardrails' are instructions in a prompt — a request made to a system that is confidently wrong sometimes. Real constraint lives in the tools you withhold, the policy evaluated before execution, and the gate a human stands at.
The four layers, weakest first
Guardrail is a broad word for four very different things. Ordered by how much they actually stop:
1. Prompt rules. “Never modify production config.” This is a preference, not a control. It lowers the frequency of an attempt and does nothing about the case that matters — when the model believes it is following the rule and is wrong.
2. Tool boundaries. The agent cannot delete a database because it has no tool that deletes databases. This is the strongest and cheapest guardrail available, and it is chronically underused because handing over one more capability is always the convenient choice in the moment.
3. Policy evaluation. Before an action executes, it is matched against rules and returns an outcome: allow, allow with constraints, require approval, require two approvals, deny. This is where nuance belongs, because it sees the actual requested action rather than the intention behind it.
4. The approval gate. A human decides, with the diff and the evidence in front of them. Reserved for what genuinely leaves the sandbox.
A policy ladder, not a switch
The common mistake is treating permission as binary: the agent is trusted or it is not. Real work needs a ladder, where the response scales with what an action can cost.
Note the top and the bottom. Reading and drafting are unrestricted, because an agent that must ask permission to think is worthless. Changing a security control is denied outright rather than held for approval — if it is on the list a tired human can approve at 2am, it is not really forbidden.
Default-deny, and the bill it comes with
Rules should be a permit list: anything not explicitly allowed is refused. This is the only posture that survives a model inventing an action name nobody anticipated — which happens, because the action vocabulary is generated text like everything else.
Be honest about the cost. A legitimate plan gets killed because the model asked for repo.pull_request while the policy knows pr.create. The fix is canonicalising synonyms and pinning the vocabulary in the planning prompt — not relaxing the default. A default-allow system fails in the other direction, and that failure is the one you read about afterwards.
Guardrails are not observability
Most tooling sold for agents watches them: traces, spans, token counts, dashboards. That is genuinely useful and it is not a guardrail. Observability answers what happened; guardrails decide what is allowed to happen. A flawless trace of an agent emailing the wrong customer list is a very good record of an incident you could have prevented.
The practical test: if your agent tried something destructive right now, would your system stop it, or would it produce an excellent record of it?
Why the gate needs evidence, not a summary
An approval gate only works if the human can actually judge. In practice they are shown a one-line summary of what the agent intends — and a confident summary is the easiest thing for a language model to produce, including when the underlying change is wrong.
We caught exactly this. An agent was asked to fix a content-security policy, and it proposed a change that inverted it — swapping the live domain for a stale one from an unrelated project — with a fluent rationale attached. The summary read perfectly. The diff was backwards. It was caught because the gate showed the diff, not the sentence.
So: the gate must present the actual change, the exact target identity, the tests that ran, and the policy outcome. If a human is approving a paraphrase, the gate is theatre.
FAQ
- What are AI agent guardrails?
- Guardrails are the constraints that decide what an agent may attempt, what it may actually do, and what needs a human first. They exist at four levels: the prompt (instructions the model can ignore), the tools (capabilities it simply does not have), the policy engine (rules evaluated before an action executes), and the approval gate (a human decision for anything consequential). Only the last three are enforcement — the first is a request.
- Are prompt instructions enough to constrain an agent?
- No. A prompt rule is a preference expressed to a system that generates plausible text, not a control that fails closed. It reduces how often an agent tries something; it does nothing when the model is confidently wrong. Real constraint comes from not handing over the capability, or from evaluating the requested action against policy before it runs.
- What is the difference between guardrails and observability?
- Observability tells you what an agent did; guardrails decide what it can do. Logging a destructive action in beautiful detail does not prevent it. Most tooling marketed for agents is observability — which matters, but reading a perfect trace of an incident is not the same as never having had the incident.
- Should guardrails block an agent or hold it for approval?
- Depends on whether the action is ever acceptable. Rotating credentials or weakening a security control should be denied outright — no human should be able to approve it in a hurry at midnight. Pushing a branch or emailing a customer is legitimate but consequential, so it should be held for a person rather than blocked. A system with only one of these two responses is either useless or unusable.
- What is a default-deny policy for agents?
- Any action not explicitly permitted is refused. It is the only posture that survives the model inventing an action name you never anticipated — and it will. The cost is real: legitimate work gets blocked when an agent asks for 'repo.pull_request' and your rules say 'pr.create'. That is a vocabulary problem to fix, not a reason to default-allow.
see the whole flow, live
Everything on this page — the queue, the evidence, the hold-to-approve, the audit trail — is working in the VIVUU terminal as an interactive preview on realistic mock data. No sign-up.