Who gives AI authority to act
An assistant finds an overdue invoice. It drafts a polite reminder, identifies the right contact and suggests sending it. So far, the arrangement is straightforward. Then it offers a discount to secure payment. Somewhere between those two actions, a useful assistant has started making commercial decisions.
That boundary deserves more attention than it gets. As AI systems gain access to business tools, the practical question becomes who authorised each action, within what limits, and who can stop it. A system can understand a request perfectly and still exceed the authority that anyone intended to give it.
Businesses already manage delegation between people. An employee may approve a refund below a certain amount, negotiate within agreed terms or prepare a contract that somebody else signs. These arrangements are often imperfect, but they recognise that competence and authority are separate properties. Being very good at negotiating does not give someone permission to sell the company.
AI makes the gaps in those arrangements more visible. Instructions that work between colleagues can depend on years of shared context. “Sort this out” may carry an understood set of limits. A model sees words, tools and whatever context the surrounding system supplies. It should not have to infer the company's entire constitution from a frustrated message sent on a Friday afternoon.
The security community has a practical name for part of this problem. OWASP's guidance on excessive agency identifies excessive functionality, permissions and autonomy as sources of risk. Its recommendations include limiting available tools and privileges and requiring approval for consequential actions. These are engineering decisions with direct commercial implications.
The sensible starting point is a clearly bounded job. An assistant might be allowed to identify overdue invoices and prepare reminders, while changes to payment terms remain with a named person. Another could reorder a specific consumable within an agreed quantity and budget. Permission should describe the action and its limits in terms the business understands, then be enforced by the systems that execute it.
Access controls help, but they answer only part of the question. The Model Context Protocol's authorisation specification describes how clients can access restricted servers on behalf of resource owners. That technical permission still needs to fit the business mandate. A valid credential may allow access to an invoicing service without settling whether a particular debt should be waived.
This is why delegating everything through one powerful account is an uncomfortable shortcut. It makes a demonstration easy and an incident difficult to explain. The person reviewing an action should be able to understand whose authority was used, which instruction justified it and whether the action stayed within the agreed scope. Records need to be useful enough to reconstruct events without exposing unnecessary private information.
There is an obvious counterargument. If every small action needs approval, automation becomes a queue of interruptions. People will stop reading the requests, click whatever clears the screen and recreate the original risk with extra administration. Excessive caution can make a system both less useful and less carefully supervised.
The answer is to make delegation proportionate. Reversible, familiar actions can have wider standing permission. Unusual commitments, changes to access and decisions with serious consequences deserve a different process. The exact boundaries will vary. A useful system should make them visible, allow them to be withdrawn and recognise when the current situation falls outside them.
Responsibility also needs to survive the arrival of another supplier. NIST's AI Risk Management Framework places responsibility for AI risk decisions with organisational leadership and calls for defined roles. A company cannot sensibly outsource its own judgement about acceptable exposure simply by purchasing a capable model.
The most useful question before granting more autonomy may be mundane: what happens when this goes wrong? Can the action be reversed? Can access be removed immediately? Will the affected customer know whom to contact? A clear answer makes it easier to delegate confidently. An unclear answer usually means there is more design work to do before the assistant gets another button to press.