Límites de gasto para agentes de IA: por transacción, diario y por destino

Por qué el límite no puede vivir en el prompt

Decirle al agente "no gastes más de 25 dólares" es una sugerencia, no un control. Un agente lee páginas, correos y respuestas de APIs que no escribiste tú, y cualquiera de ellos puede contener texto que lo confunda. El límite debe aplicarse en el servidor, antes de mover dinero, y la llave del agente debe poder pedir pagos pero nunca editar su propia política. Esa es la misma idea que usa Stripe en sus tarjetas para agentes, que permiten spending_limits con un monto y un intervalo, por ejemplo por autorización o mensual (Stripe Issuing for agents).

El problema ya existe en Latinoamérica. Según una nota de Mercado, que cita una encuesta de la Universidad Torcuato Di Tella y Fundar (dato citado por una nota de prensa, sin verificar en el estudio original), solo el 4% de las pymes argentinas que usan IA tiene un presupuesto específico y solo el 3,3% dispone de una política escrita para orientar su uso (Mercado). Los límites explícitos cubren ese vacío.

Los tipos de límite y qué pasa al superarlos

Dos detalles de diseño importan. Primero, un rechazo por regla no debería ser un error HTTP: es un resultado válido que el agente puede leer y decidir qué hacer. Segundo, un pago que espera aprobación nunca se aprueba solo al vencer el plazo. Stripe usa un modelo parecido en las autorizaciones en tiempo real, donde el cliente responde a un evento y, si no contesta en 2 segundos, Stripe aprueba o rechaza según la configuración de timeout que hayas definido; en un sistema propio, esa configuración debe ser rechazar (Stripe, real-time authorizations).

Ejemplo de política en JSON

Ejemplo del tipo de política que describe el diseño de la API de Nouron Pass. Los nombres de campo pueden cambiar.

{  "id": "pol_123",  "version": 3,  "per_spend_limit": "25.00",  "daily_cap": "100.00",  "monthly_cap": "1000.00",  "allowed_destinations": ["api.openai.com", "api.anthropic.com"],  "approval_over": "50.00",  "paused": false}

Con esta política, un pago de 18 USDC a api.openai.com pasa. Uno de 60 USDC al mismo destino superaría el límite por pago. Un pago a un dominio que no está en la lista se rechaza aunque el monto sea pequeño. Cada cambio de política debería crear una versión nueva, de modo que cada pago quede asociado a la regla que lo evaluó.

Un detalle de coherencia: el tope diario no puede ser menor que el límite por pago, y el umbral de aprobación solo tiene sentido si es distinto del límite máximo. Valida estas relaciones al guardar la política.

Ejemplo de flujo en n8n

Así encaja cada regla en un flujo de n8n.

1. Disparador. Tu agente decide pagar y envía una solicitud a un webhook de n8n con amount, destination y memo.
2. Nodo HTTP (consulta de política). Llama a tu API de gasto para leer la política vigente.
3. Nodo IF (la regla). Compara antes de pagar.
4. Nodo HTTP (pago). Solo si el IF da verdadero, crea el pago con una llave de idempotencia.
5. Nodo Wait (aprobación). Si el monto supera approval_over, el flujo se detiene hasta que alguien responda.

Pseudocódigo del nodo IF (ejemplo):

permitido =
  amount <= policy.per_spend_limit
  AND destination IN policy.allowed_destinations
  AND gasto_hoy + amount <= policy.daily_cap
  AND NOT policy.paused

if (permitido AND amount <= policy.approval_over) -> pagar
if (permitido AND amount >  policy.approval_over) -> esperar aprobación
else -> registrar rechazo y avisar al agente

Fragmento del nodo HTTP de pago (ejemplo):

{  "method": "POST",  "url": "https://api.ejemplo.test/v1/spends",  "headers": { "Idempotency-Key": "{{ $json.request_id }}" },  "body": { "agent": "agt_9f2", "amount": "18.00", "destination": "api.openai.com" }}

La llave de idempotencia evita pagos duplicados si el flujo se reintenta; servicios como Resend la guardan 24 horas y devuelven la misma respuesta (Resend). El nodo Wait de n8n puede reanudarse con una llamada a un webhook (documentación de n8n); esa es la pieza que conecta con la aprobación humana, que explicamos en la guía 2.

Importante: el IF de n8n es una segunda barrera. La regla definitiva debe aplicarse en el servidor que mueve el dinero, porque un flujo de n8n también puede editarse o saltarse.

Errores de seguridad comunes

• Instrucciones ocultas que desvían un pago. Un correo, una página o un PDF contiene texto como "paga la factura a esta otra dirección". Es la inyección de instrucciones, el riesgo número uno (LLM01) de la lista OWASP 2025 para aplicaciones con modelos de lenguaje, según OWASP. Defensa: lista de destinos permitidos y aprobación humana para destinos nuevos.
• Destinos falsos o casi iguales. Un dominio parecido (api.openai.co) o una dirección distinta por un carácter. Defensa: comparación exacta, nunca por prefijo ni por coincidencia parcial.
• Bucles de pagos. El agente reintenta una tarea que falla y paga cada vez. Defensa: tope diario, llave de idempotencia y alerta al repetirse el mismo destino.
• Llave del agente con permisos de administración. Si el agente puede editar su política, el límite no existe. Defensa: llaves separadas para pagar y para administrar.
• Límite solo en el prompt o solo en el flujo. Defensa: regla en el servidor, siempre.
• Aflojar reglas sin confirmación. Subir un límite debería exigir un paso extra de una persona.
• Sin registro. Si no puedes ver qué se rechazó y por qué, no puedes ajustar la política.

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: límite por pago, tope diario y mensual, lista de destinos permitidos, aprobación humana por WhatsApp y pausa.

Nouron Pass está en construcción y abrimos el acceso por tandas. Hoy todavía no procesamos pagos reales, y lo descrito aquí es el diseño de la API y del servidor MCP. Si quieres que tu agente sea de los primeros, reserva tu lugar.