Automate with human approval and stay in control

Preparing versus acting

Preparing means producing something a person can still review: sorting an email, pulling amounts from an invoice, writing a draft. Acting means changing something outside the workflow: sending, updating a record, paying, deleting. An automation that only prepares can already save time without exposing anything.

• Prepare: read an invoice and extract supplier, number and total.
• Prepare: compare the invoice with the purchase order and flag differences.
• Act: email the supplier.
• Act: change the invoice status in the accounting software.
• Act: trigger a payment.

OWASP, a well-known application security reference, describes a risk it calls Excessive Agency: a system with too much functionality, too many permissions or too much autonomy. Its recommendations include keeping functions and permissions to the minimum necessary, and having a human approve high-impact actions before they are taken. That advice targets AI applications, but in our view the same logic applies to rule-based automation.

Classify every action

Two questions are enough to place an action. What is the impact if it is wrong? Can it be undone easily? The table suggests a starting control that you can adjust to your business.

What an approval must show

An “Approve” button under a summary is not enough to make a decision. The person needs to see, in one place, what triggered the request, what the system proposes, what it is unsure about and exactly what will happen after they approve. If they have to open three apps to understand it, the risk is that they approve without looking.

• Source: the original document or message, or a direct link to it.
• Proposal: the full text, the amount or the exact value.
• Uncertainties: differences, missing fields, items marked “to confirm”.
• The recipient or the record affected.
• Exact effect: “If you approve, this email goes to this address.”
• Choices: approve this version, edit, reject, ask for more information.

Some tools build this in. In n8n, a tool used by an AI agent can require human review: the workflow pauses, the reviewer sees which tool the AI wants to use and with what parameters, then approves or denies. If denied, the action is cancelled and the AI is told. Still check that what the reviewer sees is enough to decide, because technical parameters are no substitute for a readable summary.

Silence, changes and exceptions

No answer means the action stays pending, never an implied approval after a delay. Watch your settings. In n8n, the Limit Wait Time option on a send-and-wait step makes the workflow resume automatically after a set time. If you turn it on, test what happens at expiry and make sure that path marks the request as expired instead of carrying out the action.

If the content changes after approval, the approval no longer counts. A corrected amount, an added recipient or rewritten text all need a fresh approval. A simple way to enforce this: approval applies to a numbered version, and execution checks that this exact version is the one going out.

An exception should reach a named person with the reason in plain language, rather than vanishing into a workflow that fails silently. Plan a backup person for absences too. In n8n, for example, an error workflow can run when an execution fails and send an alert by email or Slack.

Log and test

Logging should match the risk. For a draft, the date and the result are enough. For a customer message, a record change or a payment, keep who approved, when, which version and what the connected service replied. OWASP also recommends monitoring activity and rate-limiting actions to reduce the damage if something goes wrong.

Before going live, test the awkward cases, not just the one that works, using fictional or authorized data. In n8n, the Stop And Error node lets you force a failure to check that your error workflow responds.

1. Rejection: the action is cancelled and nothing goes out.
2. Expiry: the request moves to “expired” and the owner is notified.
3. Duplicate: the same invoice received twice creates neither two requests nor two payments.
4. Change: content edited after approval asks for approval again.
5. Connected service outage: the error is visible and the action is not marked as done.

An example, end to end

Notice what the automation did not do: it did not pay, dispute or choose on Chantal’s behalf. It did the looking up and the comparing, then presented a decision ready to be made.

APPROVAL REQUEST [ID], version [n]

TRIGGER: [e.g. invoice 2318 received on MM-DD]
SOURCE: [link to the original document]

PROPOSAL: [full text, amount or exact value]
RECIPIENT OR RECORD AFFECTED: [address, record, account]

UNCERTAINTIES:
- [difference found]
- [missing field or “to confirm”]

IF YOU APPROVE: [exact effect, e.g. this email goes to this address]
WHAT WILL NOT HAPPEN: [e.g. no payment]

CHOICES: Approve this version | Edit | Reject | Ask for more information
NO ANSWER BY [date]: stays pending, [backup person] is notified
IF THE CONTENT CHANGES: new approval required