Human approval over WhatsApp for an AI agent: step-by-step flow

When to ask for approval

Asking permission for everything makes the agent useless; never asking makes it dangerous. The practical rule is to ask for approval when a payment goes over a threshold, when the destination is new, or when something breaks the usual pattern.

In Latin America this "supervised autonomy" model already applies on some rails. Iniciador, for example, offers agentic payments over Pix with biometric approval of each payment and says the agent never moves money on its own (Iniciador). Stripe applies a similar idea: its real-time authorizations let you approve or decline by responding to an event (Stripe).

The flow, step by step

1. The agent requests a payment (amount, destination, memo).
2. The server evaluates the policy. If it goes over the approval threshold, the payment stays in the pending_approval state and nothing is paid.
3. An approval.requested event is emitted and a message is sent to the approver.
4. The person replies Approve or Decline.
5. If they approve, the payment runs; the approval is valid only for that payment and that amount.
6. If they decline, or if the time limit expires, the payment is declined. It is never approved just because nobody answered.
7. Everything is kept in a log: who decided, when, and on which payment.

Details that matter: the time limit should be short and visible (for example 10 minutes), an approval must not be reused for a different amount, and there should be an emergency word (for example "PAUSE") to stop the agent from the same chat.

Example message and policy

Example of the message described by the Nouron Pass design:

Nouron Pass: compras-sdr wants to pay 80 USDC to api.openai.com
(over your approval limit of 50). Expires in 10 min.
[Approve] [Decline]    (type PAUSE to stop the agent)

And the part of the policy that triggers it (example):

{  "approval_over": "50.00",  "approval_timeout_minutes": 10,  "on_timeout": "decline",  "approvers": ["+55 11 90000-0000"]}

Setting on_timeout to decline is the central security decision. The phone number is a sample.

Example flow in n8n

Here is how the flow is built:

1. Incoming webhook. Receives the payment request from the agent.
2. HTTP node (evaluate). Calls your spending service, which answers approved, declined or pending_approval.
3. IF node. If the status is pending_approval, it follows the approval branch; if approved, it goes straight to payment; if declined, it tells the agent.
4. Message node. Sends the approver the text with the amount, the destination and the time limit, with a single-use decision link.
5. Wait node. Pauses the flow until a resume URL is called or the time runs out. The n8n Wait node can be resumed with a webhook call (n8n documentation).
6. IF node (decision). If the answer is "approve" and it arrived in time, it runs the payment; in any other case, it declines.

Pseudocode for step 6 (example):

if (decision == "approve" AND now <= expires_at AND token_valid AND amount == requested_amount)
    run_payment(idempotency_key = request_id)
else
    log_decline(reason = "not_approved_in_time_or_different")

Resume snippet (example):

{  "method": "POST",  "url": "https://your-n8n.example.test/webhook-waiting/abc123",  "body": { "decision": "approve", "approval_id": "apr_55", "amount": "80.00" }}

Comparing amount == requested_amount prevents an approval for 80 from being used to pay 800. The idempotency key prevents a double tap on "Approve" from charging twice.

Common security mistakes

• Approving by default when the time limit expires. This is the worst mistake. Silence must mean "no".
• A message that hides the real destination. If the text says "payment to vendor" and does not show the exact destination, the person approves blind. Always show amount, destination and reason.
• Hidden instructions that divert a payment. Malicious text inside an email or a web page can push the agent into requesting a payment that looks legitimate. The approver is the last barrier, which is why the message must be clear. This is the prompt injection described by OWASP.
• Reusable decision links. Each link should be valid for a single payment and expire.
• Unverified approver. Only the linked, confirmed number may answer; ignore messages from unknown numbers.
• Approval fatigue. If dozens of requests arrive, the person approves by reflex. Raise the threshold or use more automatic limits.
• Payment loops. An agent that retries can flood you with requests. Cap the pending requests per agent.
• Fake destinations. A near-identical domain. Compare exactly and mark new destinations visibly.

What Nouron Pass does with this

Nouron Pass is designed as an API and an MCP server so that a person or company in Latin America can deposit in their local currency, have it converted to USDC, and let an AI agent pay and receive payments under rules, including human approval over WhatsApp.

Nouron Pass is under construction and we are opening access in batches. Today we do not process real payments yet: in the current design the approval is simulated inside the dashboard, and actual WhatsApp delivery requires a provider and approved message templates. Pricing is still undefined. If you want your agent to be among the first, reserve your spot. For the limits that apply before asking for approval, read guide 1.