Aprobación humana por WhatsApp para un agente de IA: flujo paso a paso

Cuándo pedir aprobación

Pedir permiso para todo vuelve inútil al agente; no pedirlo nunca vuelve peligroso al agente. La regla práctica es pedir aprobación cuando el pago supera un umbral, cuando el destino es nuevo o cuando algo se sale del patrón.

En Latinoamérica este modelo de "autonomía supervisada" ya es el vigente en algunos rieles. Iniciador, por ejemplo, ofrece pagos agénticos por Pix con aprobación biométrica de cada pago y dice que el agente nunca mueve dinero solo (Iniciador). Stripe aplica una idea parecida: sus autorizaciones en tiempo real permiten aprobar o rechazar respondiendo a un evento (Stripe).

El flujo, paso a paso

1. El agente pide un pago (amount, destination, memo).
2. El servidor evalúa la política. Si supera el umbral de aprobación, el pago queda en estado pending_approval y no se mueve dinero.
3. Se emite un evento approval.requested y se envía un mensaje a la persona aprobadora.
4. La persona responde Aprobar o Rechazar.
5. Si aprueba, el pago se ejecuta; la aprobación vale solo para ese pago y ese monto.
6. Si rechaza, o si el plazo vence, el pago se rechaza. Nunca se aprueba solo por falta de respuesta.
7. Todo queda en un registro: quién decidió, cuándo y sobre qué pago.

Detalles que importan: el plazo debe ser corto y visible (por ejemplo 10 minutos), la aprobación no debe reutilizarse para otro monto, y debe existir una palabra de emergencia (por ejemplo "PAUSA") para detener al agente desde el mismo chat.

Ejemplo de mensaje y de política

Ejemplo del mensaje que describe el diseño de Nouron Pass:

Nouron Pass: compras-sdr quiere pagar 80 USDC a api.openai.com
(supera tu límite de aprobación de 50). Vence en 10 min.
[Aprobar] [Rechazar]    (escribe PAUSA para detener al agente)

Y la parte de la política que lo dispara (ejemplo):

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

El campo on_timeout en decline es la decisión de seguridad central. El número de teléfono es de ejemplo.

Ejemplo de flujo en n8n

Así se arma el flujo:

1. Webhook de entrada. Recibe la solicitud de pago del agente.
2. Nodo HTTP (evaluar). Consulta tu servicio de gasto, que responde approved, declined o pending_approval.
3. Nodo IF. Si el estado es pending_approval, sigue por la rama de aprobación; si es approved, va directo al pago; si es declined, avisa al agente.
4. Nodo de mensaje. Envía a la persona aprobadora el texto con el monto, el destino y el plazo, con un enlace de decisión de un solo uso.
5. Nodo Wait. Pausa el flujo hasta que se llame a una URL de reanudación o venza el tiempo. El nodo Wait de n8n puede reanudarse con una llamada a un webhook (documentación de n8n).
6. Nodo IF (decisión). Si la respuesta es "aprobar" y llegó a tiempo, ejecuta el pago; en cualquier otro caso, rechaza.

Pseudocódigo del paso 6 (ejemplo):

if (decision == "approve" AND ahora <= vence_en AND token_valido AND monto == monto_solicitado)
    ejecutar_pago(idempotency_key = request_id)
else
    registrar_rechazo(motivo = "no_aprobado_a_tiempo_o_distinto")

Fragmento de la reanudación (ejemplo):

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

La comparación de monto == monto_solicitado evita que una aprobación para 80 se use para pagar 800. La llave de idempotencia evita que un doble toque en "Aprobar" cobre dos veces.

Errores de seguridad comunes

• Aprobar por defecto al vencer el plazo. Es el error más grave. El silencio debe significar "no".
• Mensaje que oculta el destino real. Si el texto dice "pago a proveedor" y no muestra el destino exacto, la persona aprueba a ciegas. Muestra siempre monto, destino y motivo.
• Instrucciones ocultas que desvían un pago. Un texto malicioso dentro de un correo o una página puede llevar al agente a pedir un pago legítimo en apariencia. La persona aprobadora es la última barrera; por eso el mensaje debe ser claro. Es la inyección de instrucciones descrita por OWASP.
• Enlaces de decisión reutilizables. Cada enlace debe valer para un solo pago y caducar.
• Aprobador sin verificar. Responde solo el número vinculado y confirmado; ignora mensajes de números desconocidos.
• Fatiga de aprobación. Si llegan decenas de solicitudes, la persona aprueba por reflejo. Sube el umbral o usa más límites automáticos.
• Bucles de pagos. Un agente que reintenta puede inundar de solicitudes. Limita las solicitudes pendientes por agente.
• Destinos falsos. Un dominio casi idéntico. Compara de forma exacta y marca los destinos nuevos de forma visible.

Qué hace Nouron Pass con esto

Nouron Pass está diseñado como una API y un servidor MCP para que una persona o empresa de Latinoamérica deposite en su moneda local, se convierta a USDC y deje que un agente de IA pague y cobre bajo reglas, incluida la aprobación humana por WhatsApp.

Nouron Pass está en construcción y abrimos el acceso por tandas. Hoy todavía no procesamos pagos reales: en el diseño actual la aprobación se simula dentro del panel, y el envío real por WhatsApp requiere un proveedor y plantillas aprobadas. Los precios siguen sin definir. Si quieres que tu agente sea de los primeros, reserva tu lugar. Para los límites que se aplican antes de pedir aprobación, lee la guía 1.