Before giving a new manager authority to approve a payment, I would want to know their limit. Which payments, how much, under what conditions, and who gets called when something looks unusual. “They are very intelligent” would be an interesting answer to a different question.
I think we owe our AI agents the same conversation. The moment software can commit the company to an action, someone has delegated authority. That decision deserves rather more attention than a checkbox in a configuration screen.
On 8 October, Optro published findings from its report, “Authority without oversight: The 2026 agentic enterprise report,” including that 34 percent of respondents said their organizations had experienced an inaccurate agent decision or output that was acted upon, while only 9 percent said they had redesigned workflows to safely accommodate agents (Optro’s research announcement). This is a vendor-sponsored survey of 417 audit, risk, compliance and information-security decision-makers in North America and Europe, so I would read it as a warning from that population rather than a census of business.
The question it raises is worth asking in any company: can we explain what our agents are allowed to do as clearly as we can explain what our managers are allowed to sign?
A helpful assistant can acquire a surprisingly large mandate
Consider a hypothetical procurement assistant. It starts by summarizing supplier proposals. Someone connects it to the purchasing system so it can prepare an order. The next improvement lets it release routine orders automatically. Each step has a plausible business case, and the final demonstration looks wonderfully efficient.
At some point in that sequence, the company has created a purchasing authority. I would want that moment to be explicit. Who approved the threshold? Can the agent change the supplier as well as the quantity? What happens when several individually acceptable orders add up to a material commitment?
That last question is important because a limit on each transaction says little about cumulative exposure. A person can spend a great deal of money by signing many small things. Software should not get a more generous interpretation of the same rule simply because it signs them faster.
“A human checks it” needs a little more detail
Human oversight sounds reassuring until you try to operate it. Imagine a reviewer receiving fifty recommendations, each neatly explained and apparently consistent with policy. If the person has neither the time nor the underlying evidence to challenge them, the approval step offers very little protection.
I would want to know what the reviewer can actually see, how long a meaningful check takes, and whether they have the authority to refuse. I would also ask who covers the role when they are absent. Putting a person’s name into a workflow creates an obligation for that person; it does not automatically create the capacity to fulfill it. There is a commercial question here too. In Optro’s survey, 46 percent of respondents reported that employees were spending more time reviewing, validating or correcting AI outputs. That finding alone does not establish whether those organizations gained or lost productivity overall, but it gives me a good reason to include the checking work in the business case.
For a proposed deployment, I would count the full cost of completing the task correctly: execution, review, exceptions and repair. Otherwise, we risk celebrating the time saved at one desk while quietly borrowing it from another.
Give the agent a written delegation
My preferred starting point would be a short delegation statement that a business owner can understand without an interpreter. It should describe the outcome the agent serves, the systems it can access, the actions it can take and the circumstances in which it must stop. The technical permissions should then enforce that statement.
For the procurement example, I might authorize the agent to prepare orders for approved suppliers within an agreed category and budget. A new supplier, a change of bank details or an exception to contractual terms would require a different route. Those are illustrative boundaries; finance and procurement would need to set the actual ones.
I would separate permission to read from permission to change, and permission to recommend from permission to commit. I would also require a named business owner for the delegation. IT can implement the controls, but it should not quietly decide the company’s appetite for purchasing, credit or customer-service risk. Then I would test the uncomfortable cases before extending the mandate. Conflicting instructions. Missing information. Repeated attempts. A supplier record changed halfway through a task. A request that is technically valid but commercially absurd. The useful question is whether the agent stops safely and leaves enough evidence for someone to understand what happened.
Autonomy should be earned in a defined job
I am comfortable with increasing autonomy when the evidence supports it. Start with recommendations, compare them with authorized decisions, then allow execution in a bounded area where mistakes can be detected and corrected. Expand the scope only when the results justify the next delegation. A model update or a new connection should trigger a review of that evidence. The business owner should be able to explain why the existing authority remains appropriate, rather than assume that yesterday’s approval covers whatever the system becomes next.
This is how I would bring the subject to an executive committee: here is the decision we propose to delegate, the benefit we expect, the exposure we accept and the person who owns it. Here is how we will know when to pause. That is a decision an executive team can make.
The next time an agent demonstration ends with “and then it does everything automatically,” I would leave a little time before the applause. I would like to meet whoever authorized “everything,” and see what they signed.
