Excessive Agency Explained in Plain Terms

Why this matters

• To know which actions an AI agent will be able to perform in a company's systems without asking
• To ask a vendor a verifiable question: what exactly is the agent permitted to do, and who approved it
• To let an agent into live systems in a way that keeps the worst case cheap

What excessive agency means in plain terms

A new courier is handed a key to the warehouse door. The sensible move is one key for one door. The faster move is a master key: it opens the whole building and saves a week of questions. From there, everything rests on the courier being careful.

The same thing happens with an AI agent. The agent is given tools — access to the database, email, the warehouse system, the payment gateway. Configuring each one around a specific task takes time. Connecting them wholesale is quick.

The difference between what was granted and what is needed is what excessive agency means. As long as the agent follows the script, the difference never shows. It shows on an atypical request, on tampered data in an incoming email, on a failure in a neighbouring service.

How it works

1. Write out the actions in the process. Not the systems — the actions themselves: view a ticket, change a status, write to the customer, open a refund. The list is short, usually five to fifteen items.
2. Split them into reads and writes. Reading is almost always safe and cheap. Writing costs exactly what reversing the operation costs.
3. Create a separate account for the agent. An employee or administrator key is never handed to the agent: the employee holds more rights, and the log later gives no way to tell who made an entry.
4. Put ceilings on the write actions. Transaction amount, number of actions per hour, list of recipients, specific record fields. The ceiling is set by the business, not by engineering: it is the boundary of acceptable loss from a single error.
5. Keep a human on the expensive steps. Where reversal costs more than the operation itself, the agent prepares the action and a human presses the button.

Connections through MCP and off-the-shelf connectors form a layer of their own. Such a connector often opens an external service's full function set at once, deletion and mass mailing included. The list of enabled functions is read through by eye before the first run.

An example from practice

A support agent triages tickets and issues refunds. The connection was made with an administrator key: faster that way, and everything worked in the pilot. Technically, the agent could edit any order record and send email to any address.

In a pilot this stays invisible. The flow is uniform, the scenarios predictable, there is nothing to reverse. The difference surfaces in live traffic, where emails arrive with attached documents and text along the lines of "cancel all of this customer's orders".

Rights were narrowed to four actions: read the order, change the status, reply within the same thread, create a refund up to a threshold. The threshold was named by the CFO, based on the amount the company is prepared to lose on a single error. Deletion was disabled entirely; the agent adds a flag instead.

The scale of the surplus is measured like this: take a month of call logs, count how many distinct actions the agent performed, and compare that with the list of permitted ones. The ratio of the second to the first is the reserve of rights nobody ordered.

What the business gets

• The worst case becomes calculable. The cost of a single agent error is capped by the operation ceiling, not by the size of the system. That figure can be given to the board in advance.
• Pilots reach production faster. Security sign-off on a narrow list of actions is quick, while the conversation about access to the whole database drags on for months.
• Incident investigation takes hours. A separate agent account means every action it takes is visible in the log and distinguishable from employee actions.
• Expansion happens one item at a time. A new right is added for a new task, with a date and an owner of the decision. The reverse order — grant everything, then claw it back — never finishes in practice.

The readiness checklist helps establish whether a process is ready to be handed to an agent: the action list it produces doubles as the basis for configuring rights.

When this can be skipped

An agent that only reads and hands text to a human barely needs rights configured at all. It changes nothing, and an error costs what a wrong paragraph costs. It is enough to check that personal data and trade secrets stay out of its field of view.

The same goes for a sandbox running on a copy of the data. While the agent works against a test database, operation ceilings are unnecessary, and the action list is exactly what gets collected for future configuration. There is one moment from which rights become mandatory: when the agent gains access to a system where its actions are seen by a customer or by accounting.

What to check

First: the agent needs an account of its own. If the agent enters systems on a live employee's key, its rights are exactly that employee's rights, and the two are indistinguishable in the log.

Second: the list of enabled functions on every connector. An off-the-shelf integration with email, a task tracker or a CRM usually brings dozens of functions at once. A handful turn out to be needed; the rest are switched off.

Third: the ceilings are stated by the business. The question runs like this — what amount can the company comfortably lose on a single error, and how many such errors per day count as normal. An engineer cannot name that boundary, and without it the limit is set by guesswork.