Autonomy, Authority, and Delegation

An office shop ran for about a month with an AI as its shopkeeper. Real money, real pricing authority, a real Slack channel. Anthropic ran it with Andon Labs in 2025 and called it Project Vend. The operator was Claude Sonnet 3.7, named “Claudius”.

The financial authority was real. The approval gate around it was not. Anthropic's own performance review of the run says what that combination produced: “Claudius was cajoled via Slack messages into providing numerous discount codes and let many other people reduce their quoted prices ex post based on those discounts.” It also sold specialty metal items below cost. TIME reported that the shop's net worth fell from about $1,000 to just under $800 after Claudius ordered roughly 40 tungsten cubes.

Nothing in that sequence was a tool failure. Every discount code went through a mechanism the shop had been handed. Every price change sat inside the discretion it had been granted. Each step was technically valid. The system confused being able to set a price with being allowed to give one away. No rule stood between a persuasive message and the money.

Bounded autonomy is four limits rather than one. Decision scope: which choices may be made without consultation. Action scope: which tools, records and side effects are permitted. Resource budget: limits on money, time, tokens, calls and retries. The escalation rule: conditions that transfer control to a person or service. Revocation — a mechanism to stop or narrow authority during the task — is the fifth box. The escalation rule and revocation need separate owners and separate tests.

For high-risk systems in the EU, the last two boxes are not design advice. They are law. Article 14 of the Artificial Intelligence Act requires that the people assigned to human oversight be enabled, among other things, “to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system;”. That is Article 14(4)(d). It is the escalation box written as an obligation. Article 14(4)(e) is the revocation box: the overseer must be able to interrupt the system through a “stop” button that brings it to a halt in a safe state. Halting in a safe state is stronger than stopping. It is the part that has to be tested.

Article 14(4)(b) adds a limit on the humans in the diagram rather than on the runtime. Overseers must remain aware of automation bias. An escalation rule that routes a decision to someone who will approve whatever the system proposes has an owner but no effect.

Autonomy describes which decisions the runtime may make without another actor. Authority describes which effects it is permitted to cause. Delegation links both to a principal, a purpose, a scope and a time window.

Capability is not permission. An agent that can call a payment API, delete a file or message a customer should receive only the narrow authority the current task needs.

The failure has a number, and it has kept one across editions. The OWASP Top 10 for LLM Applications listed it as LLM06:2025 Excessive Agency in the 2025 edition. It carries it as LLM03:2026 Excessive Agency in the 2026 one. The definition is the same in both: “Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction.”

Read the last clause again. The vulnerability holds regardless of what is causing the LLM to malfunction, which puts the whole of it on the far side of the model. Both editions give the root cause as one or more of “excessive functionality”, “excessive permissions” and “excessive autonomy”. A deployer configures all three. A model acquires none of them by itself. The remedies keep that shape: fewer extensions, narrower permissions, human approval for high-impact actions.

Build the authority matrix for a workflow that already exists. List every action against the principal who may authorize it. That is what keeps broad credentials from quietly converting a reasoning error into an operational incident, and it is what makes the record show no action exceeding the principal's documented scope.

Five columns. List action classes: separate reading, drafting, staging, committing, notifying and deleting. Name the principal: record whose authority the agent is exercising. Set per-action limits: scopes, budgets, destinations and valid time windows. Attach approval gates: put confirmation before irreversible or high-impact transitions. Test revocation: verify that the runtime stops using withdrawn permissions immediately.

Two of those columns already carry a control number in a federal catalogue. NIST Special Publication 800-53, Revision 5, calls it AC-6, LEAST PRIVILEGE: “Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.” The parenthesis is what makes the matrix unremarkable rather than novel. “Processes acting on behalf of users” is an agent, described in a control published in September 2020 — years before anyone deployed one.

Enhancement AC-6(7) supplies the revocation column, and a calendar with it: periodic review of assigned privileges, with reassignment or removal when the need for them cannot be revalidated. A permission nobody can justify at review is one the matrix is supposed to remove, not to record.

The safest design grants less authority than the model appears capable of using. That is not new advice for agents. Saltzer and Schroeder set it out in 1975 as one of eight design principles, under the heading Least privilege: “Every program and every user of the system should operate using the least set of privileges necessary to complete the job.” Every program. The principle never asked how competent the program looked.

The same paper explains why the check cannot live inside the thing being checked. Its complete mediation principle requires that “Every access to every object must be checked for authority”, and it warns that cached authority checks must be updated when authority changes. That is the revocation test in the authority matrix, fifty years early. A runtime that decided once at the start of a long task and kept acting on that decision is running a stale check.

Additional permissions should therefore be earned by evidence and attached to a specific task state. Two lines belong in any review of bounded autonomy. The failure: broad credentials turn reasoning errors into operational incidents. The evidence that answers it: no action can exceed the principal's documented scope.