Agent guardrails that actually hold
The word “guardrail” gets used for two very different things: a sentence in a system prompt asking the model to behave, and a mechanism that makes the bad outcome impossible. Only the second one is a guardrail. The first is a hope.
Tests for a real guardrail
- Can the model talk its way past it? If the rule lives in the prompt, yes. If the rule is checked by the code that runs the action, no.
- Does it know who is asking? A guardrail that applies the same limits to an intern and the CFO is a rate limiter, not a guardrail.
- Does it survive a wrong answer? Models are wrong sometimes. A guardrail has to assume the model will eventually propose exactly the thing it should not, and refuse it then.
- Does it leave evidence? If nobody can see afterwards what was proposed, what was allowed, and who said yes, the guardrail cannot be audited, so it cannot be trusted.
Draft, don’t do
The single most effective guardrail is structural: the model drafts, and something else executes. In GlowForm the planner produces a proposal — the operation, its inputs, its scope — and hands it to a runner that decides, on the person’s identity and the workspace’s policy, whether it may run at all and whether it needs someone else’s approval first. The model never holds a credential and never calls a connector. It cannot “decide” to skip the check, because the check is not its decision.
Refuse with a reason
A guardrail that says “permission denied” trains people to route around it. One that says “Operations cannot delete customer records — an admin can, and I can draft the request for one” keeps the work moving inside the rules. The refusal is part of the product, and it should name the fix, not the fault.
Guardrails for reads
Writes get the attention, but reads leak. An agent answering “which customers churned last quarter” from a table the person cannot normally see is a data breach with a friendly tone. Row-level scope on reads — only records assigned to you, only your region — has to be enforced by the same mechanism as the write rules, ideally by the database itself, so no query the agent composes can widen it.
The audit log is the last guardrail
Everything above fails sometimes: policies are written wrong, scopes are too wide, a manager approves without reading. An append-only log of what was proposed, decided and run — written in the same transaction as the change, unalterable by the application itself — is what lets you find out, fix the policy, and show your auditor. Guardrails without a log are guardrails you are taking on faith.