Two-Person Approval for AI Agents: Which Actions Need It

A two-person approval rule for an AI agent means that a second named human must confirm certain actions before the agent carries them out. It applies to actions that spend money, reach people outside the company, delete data, or change access, and it should not apply to every step. The rule works when the high-risk list is short and written down, the agent cannot bypass it, and the second approver can respond within a stated time so the work does not stall.

Key takeaways

• Put a second human on actions that move money, message customers, delete or export data, or change permissions. Most other steps need one reviewer or none.
• The approver must see the exact parameters the agent will use, not a summary of what the agent intends to do.
• Enforce the rule in the tool layer so the agent cannot skip it by rephrasing the request.
• Route approvals to a named pool with a backup, and let unanswered actions expire instead of executing.
• Record who requested, what was proposed, who approved, and what happened, so every decision can be reviewed later.

Which agent actions justify a second approver?

Start from consequence, not from how confident the agent sounds. Ask three questions about each action. Can it be undone within a practical window? Does it reach someone outside the company or commit company money? Does it change access, retention or the agent's own permissions? A yes to any of these points toward a second approver.

Use the following guide as a starting point and adjust it to your operation:

• Money out: payments, refunds, purchase orders and credit notes above a limit that the finance owner sets.
• External first contact: a message to a customer, supplier or regulator that has not been sent before, or that uses new commitments or wording.
• Deletion or export: removing records, purging agent memory, or moving a data file outside its usual system.
• Permission changes: granting a new tool, widening a scope, or adding a person to an agent channel.
• Shared configuration: changing prompts, routing rules or integrations that affect many tasks at once.
• Commitments: changing dates, prices, availability or terms promised to a third party.

Actions that are read-only, produce reversible drafts, or write internal notes usually stay automatic or under single review. Keeping the list short is what makes the second approval credible, because approvers stop trusting a rule that asks them to confirm everything.

Why one approver is often not enough

A single approver is a weak control when that person is busy, relies on the agent's summary, or is the same person who asked for the task. Under volume, approvals become reflexive. A two-person rule changes the structure: the second person is independent of the requester and checks the specifics against the source record. This is the same separation of duties that finance teams already use for payments.

The agent's own explanation is also not evidence. A fluent justification can be wrong about a customer's account, a file version or a deadline. The approver should check the parameters against the systems of record, and the tool should hold the action until that check is recorded. The NIST AI Risk Management Framework treats clear assignment of accountability as part of managing AI risk, and a named second approver is one concrete way to assign it.

How do you set up the second approval step?

Setting up the routing is mostly a matter of writing decisions down and testing them before live use. The following sequence works for most small and mid-sized operations:

• Step 1: Write the high-risk list, with one business owner per action type and the reason each action is on the list.
• Step 2: Define independence. The second approver should not be the requester, should have authority over the action, and should be able to open the source record.
• Step 3: Build a pending state into the tool. The agent proposes an action with exact parameters, and the tool holds it until both approvals arrive.
• Step 4: Name at least two qualified approvers for each action type, plus a backup for absences, and state the response window.
• Step 5: Set an expiry. If no second approval arrives in the window, the action lapses and the agent reports that it did not run.
• Step 6: Test in a staging copy, including the case where the second approver rejects the request and the case where the request expires.

The pending state is the part most teams skip. Without it, the approval is a message in a chat thread that the agent may act on regardless, and the control exists only on paper.

How do you keep routine work fast?

A two-person rule only holds if people do not route around it. Use three tiers: automatic for reads and drafts, single review for moderate actions, and two-person approval for the short list. Pre-approve bounded patterns, such as refunds under a limit for a specific reason code, and enforce the limit in the tool rather than in the agent's instructions.

Batch low-stakes reviews at set times so approvers are not interrupted all day. Review the tiers each quarter, and move an action to a lower tier only when its record shows that approvals were routine and no errors reached customers. For a deeper treatment of how trust grows across tiers, see Superintelligent Agent Authorization: Growing Trust Tiers.

Illustrative scenario: credit notes after support tickets

Illustrative scenario: a services company uses an agent to draft credit notes after support tickets close. Under the rule, the agent drafts notes and writes ticket summaries automatically. Any credit note above the finance lead's limit, or any note to a customer who has never received a credit, goes to a pending queue. The queue item shows the customer, the reason code, the ticket link and the exact amount.

A finance approver and an account manager each confirm the item from the source record. If the account manager is away, the named backup receives the request. Anything not confirmed within the window expires, and the agent tells the support lead that the credit was not issued, so a person decides the next step. No one has to read every draft, and the items that matter get two independent looks.

What should an approval record contain?

An approval is only useful later if the record shows what was decided and why. Keep these elements for every high-risk action:

• The requester and the agent's proposed action, including exact parameters.
• The source records the agent relied on, referenced rather than copied.
• Each approver, their decision, the timestamp and any note they added.
• What executed, or why nothing executed, including expiry and rejection.

Store these records with access limits, and avoid placing unnecessary personal data inside them. When an action goes wrong, the record is what lets you separate a bad proposal, a bad check and a bad tool. For the related question of stopping an agent quickly when something fails, see AI Agent Kill Switch: Halt Actions Without Losing Logs or Queued Work.

How Be Human handles this in managed operations

In managed operations, Be Human starts with one useful role and maps its actions to the consequence tiers described above. The approval routing, pending states and expiry rules are built into the agent's tool layer, and the agent's permissions are set so it cannot execute held actions on its own. Monitoring tracks queue age, rejections and expired actions, and periodic permission reviews adjust the high-risk list when tools or teams change. If an approval path fails, the incident process pauses the affected action type while keeping the records intact. The service is delivered remotely, in English or Portuguese.

If you are unsure which of your agent's tasks deserves a second approver, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How many approvers does a high-risk AI agent action need? Two independent people is the usual pattern for actions that are costly or hard to reverse. The second approver should be able to see the source record and should not be the person who requested the action. For lower-risk actions, one reviewer is often enough.

Can the agent approve its own actions if a second model checks them? A model checking another model is not an independent human approval, and the two can share the same blind spots. Keep the final decision with a person for the high-risk list, and let any automated check add information rather than replace the approval.

What happens when the second approver is unavailable? Each action type should have a named backup and a stated response window. If neither approver responds in time, the action expires, the agent reports that it did not run, and the request can be resent or handled manually.

Does a two-person rule slow the team down? It slows only the short list you define. Routine reads, drafts and bounded patterns run without waiting, and the tiers should be reviewed as the approval record shows which decisions are always granted.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.