What should an AI agent be allowed to do

Whenever I ask this question in public, someone answers with an amount. Five hundred euros a month, a merchant allowlist, a category list. Those are answers, and they are not the shape of the answer. AI agent controls are a design problem with a structure, and once you see the structure you notice that most products implement one third of it and call it done.

The structure, as written by people who had to specify it

Google's Agent Payments Protocol describes the delegated case, the one where the human is not present, and it names the pieces a mandate has to carry: the rules of engagement, price limits, timing, and other conditions. The same specification makes a recommendation that I think is the most useful line in the whole document, about the expiry claim on an autonomous payment mandate: set it to the smallest value that will allow the task to be completed.

Mastercard's Agent Pay for Machines describes the same idea from the network side. Organizations set authorization rules and spending limits that are programmatically enforced, so that transactions stay inside defined parameters. Visa describes payment instructions that a consumer sets and changes, with validation to confirm that the authorisation request matches the original authenticated instruction. Three companies, three vocabularies, one shape.

The shape is: an action, the conditions under which it is allowed, the limits it cannot cross, and the moment it stops being allowed. Four fields. If a permission system cannot express all four about a single proposed purchase, it is a limit, not a permission.

The four fields, in the version I implement

• Action. A verb with a target: pay this merchant, subscribe to this service, top up this balance. Not a category, which is a library of verbs pretending to be one.
• Conditions. The circumstances that must hold at the moment of the decision: the merchant is the one named, the amount is inside the band, the thing being bought is in the permitted list, the price did not move since the agent quoted it.
• Limits. A per transaction cap, a cumulative cap, a count cap, and the window each of them resets in.
• Expiry. The date and time after which the authority is gone whether or not it was used, plus the condition that removes it earlier.

Two design rules survive contact with real users. First, every capability expires. A permanent permission is a configuration mistake waiting to be discovered by an incident. Second, the boundary is written before the run. It is the difference between telling someone the rules of a game and explaining the rules to them after they lost.

The two ways this goes wrong

The first failure is too broad. A card with a monthly cap is a permission to spend the cap anywhere, with anyone, for anything. It is the most common setup in the market today, and its real content is not a boundary. Its content is that a human will read a statement later. Everything that involves reading a statement later is accounting, not authorization.

The second failure is too granular. If every purchase needs a human approval, you have built a very good assistant and no autonomy at all. This is not a hypothetical: it is what the largest buying surface currently ships, in its own words, by keeping the agent out of the payment step to ensure determinism. It is a legitimate product. It is also a permanent ceiling for anyone whose problem is that they do not want to be in the loop at 2am for a fifty euro purchase.

The way out is not a middle setting on a slider. It is different boundaries for different classes of decision: an allowance for the routine, a written mandate for the delegated, and a requirement of evidence for the irreversible. The user should be able to state which is which in their own words, once, and then stop thinking about it.

The decisions nobody puts on the label

A boundary that cannot answer these three questions is not finished. What happens at the edge: the purchase is for 149 euro with a 150 cap, do you allow it because of rounding, or deny it because the number is the number. There is no correct answer, which means the answer has to be written down and tested, not discovered by a user at 2am. What happens when the rules conflict: the user has one mandate for all travel and another for software, and the purchase is a flight that includes a seat fee. The engine needs a defined precedence, and the precedence needs to be explainable in the receipt.

And what happens to the record when the answer is deny. This is the one I would argue about hardest with a new engineer. A denial is still a decision. Someone asked for something, the boundary said no, and three months later that request is the most interesting line in the ledger, because it is where a bad instruction would have become a real loss. Systems that throw denials away are throwing away their own evidence.

The test I use before shipping a rule

Can I read this boundary out loud to the person who wrote it, in one breath, and have them recognise it as what they meant? If the answer requires an interface tour, the boundary is wrong. If it requires an explanation of the escalation logic, the boundary is wrong. The version that passes sounds like a sentence a person would say: spend up to four hundred a month at these three suppliers, nothing that renews, ask me above a hundred and fifty, and it all stops on the last day of November.

That sentence is the product, and every field in it is a place where a system can be wrong in a way someone can point at later. The engineering behind it, a policy document that compiles to a decision and a ledger that records it, is in designing an agent policy engine. The category argument sits in the money layer for AI agents. I am building it at Noesia, and I would rather be told where that sentence breaks than be told that limits are enough. Why I care about this more than the money is on boring systems.