What should a business AI agent be allowed to do?

Sort by consequence, not by capability

The instinct is to ask what the agent is capable of and then decide how much of that to allow. That produces a permission list shaped like a feature list, which is not a risk model. The useful sort is by what happens if the action is wrong, and specifically by how hard it is to undo.

• Reversibility is the primary axis. Can a person put it back, and how quickly?
• Visibility is the second. Does anyone outside the company see the mistake?
• Volume is the third. Does one bad decision touch one record or ten thousand?
• Capability is not on the list. What the model can do says nothing about what it should.

Class one: internal, reversible, invisible

Scoring a record, ranking a queue, drafting something into a field only staff will read, creating an internal task, adding a note. Wrong output here costs a small amount of attention and is corrected by editing. This class should be permitted broadly and early, because it is where the value shows up before the risk does.

• Permit by default; require no confirmation.
• Still log it — a score nobody can trace is a score nobody will trust.
• The failure mode is noise, so watch volume rather than correctness.

Class two: internal, reversible, but consequential to a person's work

Changing an owner, moving a stage, reassigning a queue, closing a task. Reversible, invisible externally, but it changes what a colleague sees and does. The cost of being wrong is measured in confusion rather than money, and confusion compounds quietly.

• Permit, but notify the person affected rather than only logging it.
• Make the reasoning visible on the record so the change can be argued with.
• Give the affected person a one-click revert, and count how often it is used.

Roles, permissions and audit activity

Class three: externally visible

Anything a customer or prospect sees — an email, a text message, a chat reply, a scheduled meeting, a published page. Technically reversible in the sense that you can send a correction, but not actually reversible: they read the first one. This is where most organizations should sit at prepare-and-confirm for a long time.

• Default to draft-and-confirm. Raising this is a deliberate decision, not a default.
• If it does send unattended, cap volume per run and per hour so one bad judgment cannot become a campaign.
• Never let a low-confidence input trigger a class-three action.
• Log the outbound content itself, not merely that a send occurred.

Class four: irreversible or high-consequence

Money movement, contract execution, bulk deletion, permission changes, anything that cannot be undone by a person with normal access. The right answer here is not a lower autonomy level. It is a hard requirement for explicit human confirmation in the interface, before execution, every time.

• Explicit confirmation in the interface, before it runs — not a notification afterwards.
• The confirmation must show what will happen, on how many records, and why.
• No debug flag, internal route, migration script or trusted-caller path may skip it.
• If the confirmation cannot be presented, the action does not proceed.

The test that sorts an action into a class

Four questions. Ask them in order and stop at the first that puts the action in a class — this takes about a minute per action and it is the single most useful hour a team can spend before deploying agents.

• Can it be undone by a person with normal access, within an hour? If no, class four.
• Will anyone outside the company see it? If yes, class three.
• Does it change what a colleague sees or is accountable for? If yes, class two.
• Otherwise class one.
• Then ask the volume question separately: how many records can one run touch? Cap it regardless of class.

Two rules that hold across every class

Independent of the sorting, and both are the kind of thing that seems excessive until the first incident, at which point they are the only reason the incident is explicable.

• Reasoning is not authorization. A model concluding an action is correct is not the action being permitted; a separate check decides that, and the model cannot influence it.
• Fail closed. If the check cannot be evaluated — missing, errored, unreachable, timed out — the answer is deny. Never proceed anyway.
• Both apply to every path, including internal service calls and anything labeled temporary.