Aprovação humana por WhatsApp para um agente de IA: fluxo passo a passo

Quando pedir aprovação

Pedir permissão para tudo torna o agente inútil; nunca pedir o torna perigoso. A regra prática é pedir aprovação quando o pagamento passa de um limite, quando o destino é novo ou quando algo foge do padrão.

Na América Latina esse modelo de "autonomia supervisionada" já vale em alguns trilhos. A Iniciador, por exemplo, oferece pagamentos agênticos por Pix com aprovação biométrica de cada pagamento e diz que o agente nunca movimenta dinheiro sozinho (Iniciador). A Stripe aplica uma ideia parecida: suas autorizações em tempo real permitem aprovar ou recusar respondendo a um evento (Stripe).

O fluxo, passo a passo

1. O agente pede um pagamento (amount, destination, memo).
2. O servidor avalia a política. Se passar do limite de aprovação, o pagamento fica no estado pending_approval e nada é movimentado.
3. Um evento approval.requested é emitido e uma mensagem é enviada à pessoa aprovadora.
4. A pessoa responde Aprovar ou Recusar.
5. Se aprovar, o pagamento é executado; a aprovação vale só para esse pagamento e esse valor.
6. Se recusar, ou se o prazo vencer, o pagamento é recusado. Nunca é aprovado só por falta de resposta.
7. Tudo fica em um registro: quem decidiu, quando e sobre qual pagamento.

Detalhes que importam: o prazo deve ser curto e visível (por exemplo, 10 minutos), a aprovação não pode ser reaproveitada para outro valor, e deve existir uma palavra de emergência (por exemplo, "PAUSA") para parar o agente pelo próprio chat.

Exemplo de mensagem e de política

Exemplo da mensagem que o desenho do Nouron Pass prevê:

Nouron Pass: compras-sdr quer pagar 80 USDC para api.openai.com
(passa do seu limite de aprovação de 50). Vence em 10 min.
[Aprovar] [Recusar]    (escreva PAUSA para parar o agente)

E a parte da política que dispara essa mensagem (exemplo):

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

O campo on_timeout em decline é a decisão de segurança central. O número de telefone é fictício.

Exemplo de fluxo no n8n

É assim que o fluxo se monta:

1. Webhook de entrada. Recebe a solicitação de pagamento do agente.
2. Nó HTTP (avaliar). Consulta o seu serviço de gasto, que responde approved, declined ou pending_approval.
3. Nó IF. Se o estado for pending_approval, segue pelo ramo de aprovação; se for approved, vai direto ao pagamento; se for declined, avisa o agente.
4. Nó de mensagem. Envia à pessoa aprovadora o texto com o valor, o destino e o prazo, com um link de decisão de uso único.
5. Nó Wait. Pausa o fluxo até que uma URL de retomada seja chamada ou o tempo acabe. O nó Wait do n8n pode ser retomado com uma chamada a um webhook (documentação do n8n).
6. Nó IF (decisão). Se a resposta for "aprovar" e chegou a tempo, executa o pagamento; em qualquer outro caso, recusa.

Pseudocódigo do passo 6 (exemplo):

if (decisao == "approve" AND agora <= vence_em AND token_valido AND valor == valor_solicitado)
    executar_pagamento(idempotency_key = request_id)
else
    registrar_recusa(motivo = "nao_aprovado_a_tempo_ou_diferente")

Trecho da retomada (exemplo):

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

A comparação de valor == valor_solicitado evita que uma aprovação de 80 seja usada para pagar 800. A chave de idempotência evita que um toque duplo em "Aprovar" cobre duas vezes.

Erros de segurança comuns

• Aprovar por padrão quando o prazo vence. É o erro mais grave. O silêncio deve significar "não".
• Mensagem que esconde o destino real. Se o texto diz "pagamento a fornecedor" e não mostra o destino exato, a pessoa aprova às cegas. Mostre sempre valor, destino e motivo.
• Instruções ocultas que desviam um pagamento. Um texto malicioso dentro de um e-mail ou de uma página pode levar o agente a pedir um pagamento aparentemente legítimo. A pessoa aprovadora é a última barreira; por isso a mensagem precisa ser clara. É a injeção de instruções descrita pela OWASP.
• Links de decisão reutilizáveis. Cada link deve valer para um único pagamento e expirar.
• Aprovador não verificado. Só responde o número vinculado e confirmado; ignore mensagens de números desconhecidos.
• Fadiga de aprovação. Se chegam dezenas de solicitações, a pessoa aprova por reflexo. Aumente o limite ou use mais limites automáticos.
• Laços de pagamentos. Um agente que tenta de novo pode inundar de solicitações. Limite as solicitações pendentes por agente.
• Destinos falsos. Um domínio quase idêntico. Compare de forma exata e marque os destinos novos de forma visível.

O que o Nouron Pass faz com isso

O Nouron Pass foi desenhado como uma API e um servidor MCP para que uma pessoa ou empresa da América Latina deposite em sua moeda local, converta para USDC e deixe um agente de IA pagar e receber sob regras, incluindo a aprovação humana por WhatsApp.

O Nouron Pass está em construção e abrimos o acesso por levas. Hoje ainda não processamos pagamentos reais: no desenho atual a aprovação é simulada dentro do painel, e o envio de fato por WhatsApp exige um provedor e modelos de mensagem aprovados. Os preços continuam indefinidos. Se quiser que o seu agente esteja entre os primeiros, reserve o seu lugar. Para os limites que valem antes de pedir aprovação, leia o guia 1.