Agent guardrails: three limits worth enforcing
Stefan-Iulian Tesoi · · 6 min read
Close its own work, widen its own access, or erase the record of what it did. Everything else is a judgement about how much risk you want to carry. Those three are different in kind, because each one removes your ability to check the others afterwards.
Most agent guardrails are graded: more or less of them is a reasonable argument between reasonable people. These are not graded. A system missing any one of them cannot be audited back to a true statement about what happened, which makes every other control in it unverifiable too.
Which agent guardrails are not negotiable?
Three, and the test for membership is narrow: does breaking this rule destroy the evidence that it was broken?
Closing its own work. An agent that moves an item to done is asserting that the work meets the acceptance criteria, having both written against them and produced the work. There is no independent judgement anywhere in that loop, and the board stops being a record of decisions and becomes a record of completions.
Widening its own access. A credential that can extend its own scope has no scope. The blast radius of a compromise stops being what you granted and becomes whatever the agent could reach in the time nobody was looking.
Erasing the record. Anything reversible is survivable. An unrecorded change is not, because recovery depends on knowing what happened, and an audit trail with a hole in it is the one thing that cannot be reconstructed afterwards.
A limit belongs on this list when violating it also removes the trace of the violation. Everything else is recoverable by someone who can still see what occurred.
Why these three and not the others?
Because the others fail loudly. A coding agent given too much write access makes a mess you can see; the items are wrong, the commits are wrong, and somebody notices within a day. Recovery is annoying and entirely possible, because the record of what went wrong survived the going wrong.
The three above fail quietly and take the evidence with them. That is the whole distinction, and it is why AI agent limits are worth sorting by what a failure costs to detect rather than by what it costs to repair.
It also explains why the list is short. Every additional non-negotiable is a thing somebody has to enforce, argue about and test, and a long list of absolutes gets treated like a long list of suggestions. Three is a number a team can hold and check.
What is the difference between a limit and a policy?
A policy is remembered. A limit is refused. The distinction sounds pedantic until the first time something reads an instruction it was not supposed to act on.
| As a policy | As a limit | |
|---|---|---|
| Where it lives | A prompt, a runbook, a code comment | The server's tool surface |
| Who enforces it | The model, if it is paying attention | The thing being called |
| Under an unusual request | Bends, plausibly, with an explanation | Returns an error |
| After a model upgrade | Unknown until someone checks | Unchanged |
The failure mode is not a disobedient model. It is that instructions and data arrive through the same channel. A backlog item is text, and text can be written by someone outside your company — a bug reported by a customer, a request filed by a contractor. An agent reading that item is reading instructions in every sense that matters, which is why the Model Context Protocol's own security best practices are written around what the server will refuse rather than around what the client should intend.
This is the practical content of agent safety controls: not a better-worded rule, but a smaller set of callable tools. Laimonade has no tool that moves an item from In Review to Done — not a tool that declines, no tool. Every tool and its permission is published in the MCP tool reference, and the reasoning behind the shape is in what Laimonade is.
How do you test that a limit holds?
Ask the agent to break it, in plain language, and watch where the refusal comes from. That is the entire test, and it takes about a minute per limit.
There are only two outcomes and they are easy to tell apart:
- The model declines. You have a policy. It held this time, under this phrasing, on this model version.
- The call returns an error. You have a limit. It will hold under every phrasing, because the thing refusing never read the phrasing.
Run it four times a year and after every model or connector upgrade, because a policy that has held for six months is indistinguishable from a limit right up until it is not.
A worked example, from this project. Asked last week to move two backlog items to Done, the agent could not do it — and the interesting part is why. It did not decline. There is no tool in the connector that closes an item, and the one that reverses a closure says in its own description that it is not a way to mark work done. The refusal came from the tool surface, so no amount of rephrasing the request would have changed the outcome. That is what a limit looks like from the inside.
A human in the loop coding agent arrangement only means something when the loop cannot be routed around. What the person at the end of it is actually checking is the subject of definition of done when an agent wrote the code, and how to judge a connection's limits before you trust it is in coding agent security.
Frequently asked questions
Is a prompt instruction a guardrail?
No, it is a preference that usually works. A prompt is read by the same model that reads the backlog item, the repository and whatever else arrives, and any of those can carry text that competes with it. Treat prompt instructions as documentation of intent and put the enforcement somewhere that does not read the request.
What about agents that create their own tasks?
Creating work is fine; promoting it is not. An agent that files a bug it found is adding a candidate for someone to judge, which is additive and reversible. An agent that adds its own item to a queue that runs unattended has widened its own scope one item at a time, which is the second limit with extra steps.
Does this slow the work down?
It adds a human decision at one point, at the end, on work that is already finished and already carries its evidence. Reviewing against criteria written in advance takes ten to twenty minutes an item. What it removes is the class of problem where nobody can establish what happened, which is not a delay you can measure but is the one that ruins a week.
Who should own these limits?
Whoever owns the credential, which is usually not whoever runs the agent. The person configuring a connection decides the scope; the person using it feels none of it until something is refused. That split is healthy, and it is why the limits should be visible in documentation rather than discovered by hitting them.