Everybody agrees an AI agent should have limits. Almost nobody has written them down, which means the limits are whatever the person who wrote the prompt happened to think that afternoon, and nobody can say afterwards whether the system did what it was permitted to do.
This is not an argument for having boundaries. That argument is settled, and I have made it elsewhere. This is the document itself: what goes in it, how long it is, who signs it, and what proves it held. One page, five sections, a couple of hours to write.
What the document is, and what it is not
It is a single page that answers one question: what may this system do without asking a human, and what must it stop and ask about. It is not a policy, not a risk register, and not a technical specification. It is written in the language of your business rather than the language of the software, so that the person who signs it can actually read it.
It exists because permissions live in three places that drift apart — the prompt, the tool configuration, and what everyone assumes. When those disagree, the assumption is the one people act on and the configuration is the one that runs.
One: scope, written as verbs and objects
List what the system can do as pairs: an action, and the thing it acts on. Read customer records. Send a quotation. Issue a refund. Change a delivery date. Create a support ticket. Update stock.
Then mark each pair as permitted, permitted below a threshold, or forbidden. Most systems end up with four or five permitted actions and a much longer forbidden list, and writing the forbidden list is where the useful arguments happen.
Write the objects precisely, because that is where scope quietly widens. Read customer records is not the same permission as read customer records including payment history, and a system given the first will behave differently from one given the second. If you cannot say which of the two you meant, the document has already earned its afternoon.
The strongest control here is not a rule but a permission, and it is enforced outside the model. Google’s own agent development documentation puts it plainly: by giving read-only permissions to a resource, no matter what the model decides, the tool is prohibited from performing write actions. Anything you can express as a credential rather than an instruction should be, because a credential cannot be talked out of its position and an instruction can.
Two: the thresholds table
Every “permitted below a threshold” needs a number, and the number belongs in a table rather than in prose. Refund up to this amount. Discount up to this percentage. Reschedule within this many days. Answer without escalating for this many exchanges.
Three columns: the action, the limit, and what happens above it. That third column is the one people skip, and it is the one that matters, because “escalate” is not an instruction unless it names who receives it and how fast.
Set the numbers deliberately low at the start. A boundary that has never been hit teaches you nothing; a boundary that is hit twice a week and always approved is telling you to raise it, which is a much better conversation than the reverse.
The European regulation shows how far this principle can be taken where the stakes justify it: for the most sensitive category of decisions it requires verification by at least two natural persons with the necessary competence, training and authority. You almost certainly do not need two signatures on a refund. The idea worth stealing is that the seriousness of the action decides how many humans stand behind it.
Three: who signs, and what it takes to change
One named person signs the page: the owner of the process, not the head of technology and not the supplier. Their signature means they accept what the system may do in their name.
Then write the change rule in one sentence: who can widen the scope, who must be told, and where the new version is kept. Without that, the document is accurate on the day it is written and fiction three months later, because someone will loosen a limit to fix an urgent problem and nobody will write it down.
This is not a formality invented for this purpose. The United States framework for AI risk asks specifically that documentation clarify roles, responsibilities and delegated authorities across the organisation. The UAE’s own charter makes oversight a stated principle, asserting the irreplaceable value of human judgment and human oversight over AI, alongside governance and accountability. A signed page is how a small company satisfies both without a compliance department.
Four: the log that proves the boundary held
A boundary nobody can audit is a claim rather than a control. So the fourth section names what gets recorded and where it is kept: every action the system took, the input that triggered it, the identity it acted as, and every time it stopped and escalated.
Retention is a decision, not a default. Long enough that a customer complaint six weeks later can be investigated, and no longer than your data commitments allow, which is where the data protection questions apply to logs exactly as they apply to everything else.
The reason this section exists at all is that regulators now treat it as basic. The European AI Act requires that high-risk systems technically allow for the automatic recording of events over the lifetime of the system. You are probably not in scope of that law. The engineering expectation it encodes has already become the norm, and your customers’ larger partners will start asking.
Five: the stop
The last section is one paragraph and it is the one people are grateful for later. Who can switch this off, how, and what the business does for the following week without it.
Name a person and an alternate, describe the mechanism in a sentence a non-technical manager can follow, and say what the manual fallback is. Microsoft’s own architecture guidance for agentic systems asks for exactly this shape of control, recommending auditability of agent activities, role-based access control, and circuit breaker functionality to prevent catastrophic outcomes. The framework used above says the same from the management side, requiring mechanisms to supersede, disengage or deactivate a system that is behaving outside its intended use.
Test the stop once, on a quiet afternoon, before you need it. An untested switch is a belief. And time it: if switching off takes four hours because only one person knows how, that is the real number, and it belongs on the page next to the mechanism.
Keeping it honest over time
Give the page a version number and a date, and review it whenever the scope changes or every quarter, whichever comes first. The format worth borrowing is the architectural decision record, long used by engineering teams: one decision per entry, with the reasoning beside it, accumulating into a decision log. Recording why a limit was set is what stops the next person quietly removing it.
Written this way, the document does a job no meeting can: it makes the boundary checkable by someone who was not there. That is the difference between having decided something and being able to show it. It follows naturally from the four questions to settle before connecting a model to a live system, and it pairs with the acceptance test, which proves the assistant behaves well, while this proves it is only allowed to. Both are part of the AI work I do in the UAE.
Writing the authority down is step one. Building an agent that respects it is step two, and my company does that: AI agents and automation at Tothiq.
Frequently asked questions
Is one page really enough?
For a single system doing a defined job, yes, and the constraint is deliberate. A document that runs to fifteen pages will not be read by the person who signs it, and an unread document provides no oversight at all. If yours will not fit on a page, that is usually a sign the system has been given too many unrelated jobs, which is worth fixing before the paperwork is.
Our supplier says this is handled in the system prompt.
A prompt is an instruction to a model, and instructions are the weakest layer available. Anything important should also be a permission at the tool or credential level, so it holds regardless of what the model concludes. Ask to see both: the prompt text and the actual access the system has been granted. When those two disagree, the second one is what your customers will experience.
Who should sign it if the system serves several departments?
One person still signs, and the right one is whoever answers for the outcome when a customer is affected. Others are consulted and named as such. A page signed by a committee is a page nobody owns, and the whole point of the exercise is to make the authority traceable to a human being who can change it.
How is this different from an ordinary access policy?
An access policy says who may use a system. This says what the system may do on its own, which is a question that did not arise when software only did what a person clicked. The overlap is real and you should not maintain two documents that contradict each other, so if you already have a policy, add this as a section of it rather than as a rival to it.
What if we are not in a regulated industry?
Then nobody will ask to see this until something goes wrong, and at that point you will want it to exist. The commercial case is more immediate than the regulatory one: the page is what lets you widen the system’s authority with confidence, because you know exactly what it is doing today and can prove it. Companies without one tend to leave their agents smaller than they need to be.