How to name an approver for every action an agent takes

AI agent governance sounds abstract until you try to fill in one column of a spreadsheet: for this action, who approves? Most companies find they have a delegation-of-authority matrix that answers the question for people, and nothing at all for software. This guide is a practical way to close that gap.

Step 1: list the actions, not the agents

Start from what can change, not from which agent changes it. For each system an agent touches, list the actions it can propose: create a purchase bill, amend a credit limit, send a customer email, close a ticket, change a price. An agent is only as risky as the actions it can reach.

Step 2: give every action one of three outcomes

• Allow: routine actions inside a written limit, such as posting a matched purchase bill under a set value. The action runs and is recorded.
• Ask a person: actions above a limit, outside a pattern or touching something sensitive, such as an override, a deletion or a large refund. The action waits for the person you name.
• Refuse: actions the agent should never take, however the request arrives. A change to a supplier's bank details is the clearest example.

Anything you have not classified should be refused by default. In elan1 Govern, anything not clearly allowed is refused, and an error refuses too.

Step 3: choose the person

For each "ask a person" action, choose the individual closest to the consequence who already holds the authority. The credit manager for credit overrides. The finance head for journals above a threshold. The data protection lead for bulk exports of personal data. If your delegation-of-authority matrix already names them for people, use the same names for agents.

• Name a person, not a team. "Accounts" cannot answer for an action. Priya in accounts payable can.
• Name a deputy, and the hours each is responsible for.
• Keep separation of duties: the person who writes a rule should not be the only approver of changes to that rule.
• Never let an agent approve, including another agent's action.

Step 4: give the approver enough to say no

An approval is only as good as what the approver sees. Each request should show the action in plain words, the data it would change, the reason it was held and the agent's own stated confidence where there is one. If an approver routinely says yes without reading, the rule is sending them the wrong things, or too many of them.

Step 5: decide what silence means

Requests will go unanswered: people travel, fall ill or simply miss a notification. Decide in advance that silence means no. In elan1 Govern, an unanswered request expires after 24 hours and is refused, so nothing goes through because nobody replied.

Step 6: review the pattern every month

Once the agent is running, look at which rules send the most requests to people, which approvers are overloaded and which actions are refused most often. A rule that refuses almost everything needs a second look; so does an agent that keeps proposing actions your rules will never allow. On elan1 invoices, refusal rates appear beside cost, by agent and by rule, for exactly this reason.