The dominant story about AI agents is a story about capability. Agents will become useful when the models get better at planning, tool use, and recovering from their own mistakes. The bottleneck, according to that story, is intelligence. Intelligence is improving, so the bottleneck should be temporary.
We think that story misses the main reason agent projects stall. In every agent system we have built or reviewed, the thing preventing deployment was rarely the model failing to work out what to do. The blocker was that nobody could write down what the agent was permitted to do, which systems it could touch, whose authority it was using, and what would happen when it got something wrong.
The constraint is mandate.
A mandate is how organisations delegate safely
The word comes from how organisations already delegate authority. When a company gives someone authority, it does not hand over general competence and hope for the best. It grants a mandate. You may approve expenses up to this amount, in these categories, for these teams, and this is what requires a second signature.
The mandate is deliberately narrower than the person’s ability. A finance manager could authorise a million-pound payment. Their mandate says fifty thousand. Nobody treats that as an insult to their intelligence. It is how accountability works.
Software agents have arrived inside organisations with enormous capability and no matching structure. The question every deployment stalls on becomes simple: who said it could?
The capability story sounds convincing in demos
The capability story persists because it is the vendor’s story, and because it is true in the demonstration.
In a demo, the agent’s mandate is implicit. It is whatever the demonstrator set up, inside an environment with no real consequences. The impressive part is the reasoning, so the reasoning gets discussed. Nobody asks which credentials it held, because in the demo it held all of them.
Move the same system into a business and the questions invert. The reasoning becomes much less interesting. What matters is that it has a token, meaning a machine credential, that can write to the CRM. Nobody has decided what it may write, or how anyone would notice if it wrote something wrong.
Wide mandates create business risk quickly
The same pattern appears again and again. An agent is given broad authority because that makes the pilot easier. The cost appears later, when the system touches real data, real records, and real audit trails.
An agent that can read everything becomes a permissions bypass
The common starting position is broad read access. The agent gets a service account, meaning a shared machine identity, with broad read access so it can find what it needs. It is convenient, and it is how most pilots begin.
The cost appears at the first compliance conversation. An agent that can read everything has, in effect, been granted the union of every permission in the organisation. Any user who can prompt it can reach data they could not reach directly. You have built a permissions bypass and called it a productivity tool.
Writing to the same places turns reading errors into bad records
The natural next step is write access. If it can read the ticket, let it update the ticket.
The cost is that read errors become write errors. A misread document is a wrong answer. A misread document that triggers a write is a corrupted record, and corrupted records propagate. We have seen a single misclassification write an incorrect status to four thousand rows before anyone noticed, because the write path had no rate limit and no sample check.
Letting the agent choose any tool widens the blast radius
Tool use is where agents become powerful, and where mandate matters most. Given a set of tools and a goal, the model chooses. That choice is a decision with consequences, made by something that cannot be held accountable.
The cost is that your blast radius becomes the union of every tool you registered, combined in ways nobody enumerated. Each tool was reviewed individually. The compositions were not.
Acting as the user makes audit unclear
Impersonation is convenient because it pushes permissions onto someone else. The agent inherits the user’s rights, so the model looks safe.
The cost is that audit becomes meaningless. The log says the user did it. The user says the agent did it. Both are true and neither helps. In a regulated environment, that ambiguity is itself the finding.
A narrow mandate makes authority explicit
A narrow mandate does not make agents weak. It makes their authority explicit. That requires five things.
- An enumerated scope. Named systems, named operations, named record types. A list, rather than a role.
- A quantitative bound. How many writes per hour, what value of transaction, how many records in one action. Every human mandate has a number in it and agent mandates should too.
- A time bound. Credentials that expire. An agent that has held a token for eleven months is a standing risk nobody re-approved.
- A named owner. A person who granted it and can be asked why. Accountability cannot terminate at a service account.
- A reversal path. For every action in scope, a defined way to undo it, tested before the mandate is granted.
None of these items are about the model. You could grant exactly this mandate to a rule-based script or a junior employee and the framework would still make sense. It is a governance structure, rather than an AI feature.
A tight mandate can still leave room for reasoning
The fair objection is that constraining an agent this tightly removes the thing that made it interesting. If you enumerate every operation, you have written a workflow with extra steps and a language model doing the branching.
There are two responses to that objection.
- That is frequently the correct system, and the industry would be better off admitting it. A great many agent projects would be cheaper, faster and more reliable as a deterministic workflow with one model call inside it for the genuinely ambiguous step.
- The mandate constrains authority, rather than reasoning. Within an enumerated scope there is still enormous latitude: which records to look at, in what order, what to conclude, when to escalate.
The model does the part it is good at, which is interpretation. The mandate governs the part it should not be trusted with, which is consequence.
The permission model decides what can ship
We have come to think the permission model is the most important design decision in an agent system, ahead of model choice, prompt architecture and tooling.
It determines what you can deploy, because it is what security review actually examines. It determines your failure cost, because blast radius is defined by scope rather than by error rate. It determines whether audit is possible. It also determines how fast you can expand, because a narrow mandate that works can be widened deliberately, whereas a wide one that fails has to be withdrawn entirely.
Teams that start narrow ship in weeks and widen steadily. Teams that start wide spend months in security review and often never ship at all. We have watched both happen at comparable organisations with comparable engineers.
We write the mandate before we give the agent credentials
Every agent we build gets a written mandate document before it gets a credential. It is a page long and it is reviewed by whoever owns the systems in scope.
The agent runs under its own identity, never a user’s, so the audit log distinguishes them. Reads and writes are separated into different components with different credentials. The read side is where untrusted content enters, and it should not hold anything with consequences.
Every write passes through a validation layer that checks the structure, the bounds and the rate before anything reaches a system of record. That layer is deterministic code. It is the last thing that would ever be replaced by a model.
There is always a kill switch: a single flag that suspends the agent’s credentials. It is tested as a drill before go-live, rather than discovered during an incident.
A real mandate fits on one page
Abstract principles are easy to nod at, so this is a real mandate, lightly anonymised, from an agent that handles inbound supplier correspondence for a distributor.
- Scope. May read messages in one named mailbox. May read supplier records in the ERP, restricted to the supplier the message is matched to. May write exactly one thing: a status field on a purchase order, restricted to four permitted values. May not read customer data, pricing agreements, or anything in finance.
- Bounds. No more than 40 status writes per hour. No write to any purchase order over a set value. No write to an order already marked disputed, ever, under any circumstance.
- Time. Credentials rotate every 30 days. The mandate itself is reviewed quarterly by the operations director, who has to actively renew it rather than let it persist.
- Owner. Named individual, in the document, who granted it and can explain why.
- Reversal. Every status write is logged with the prior value. A single command restores any window of changes. That command was executed as a drill before the agent went live, and again after the first month.
The document is one page. Writing it took an afternoon. It is also the reason the system passed security review in a week rather than a quarter, and the reason the operations team was willing to let it touch anything at all.
A written mandate changes how people treat the agent
There is a second-order effect worth naming, because it is the one that surprises clients.
A written mandate changes how the people around the agent behave. When the boundaries are explicit, the operations team stops treating the system as an unpredictable colleague and starts treating it as a tool with a known envelope. They stop double-checking everything, because they know precisely what it can and cannot have done. Trust becomes specific rather than general, and specific trust is far more durable.
The reverse is also true. Teams working alongside an agent with undefined authority develop a low-grade suspicion of everything it touches, and that suspicion is rational. They cannot tell which records it might have changed, so they verify all of them. The productivity gain evaporates into checking, and nobody can point at the reason because the reason is an absence rather than a defect.
The agent market will sort by mandate
Our expectation is that the agent market sorts itself by mandate rather than by capability, and reasonably soon. The systems that get deployed at scale in regulated industries will be the ones that can produce, on demand, an answer to what were you allowed to do and who said so.
That is the same structure every organisation already uses for every other kind of delegated authority, and there is no reason software should be exempt as models improve.
This thinking is why BotUp sells defined jobs rather than open agency, and why our financial services and healthcare work draws the line at anything that acts without a human in the loop. If you are trying to get an agent past a security review, the mandate is usually the conversation worth having first.
