Limites de gasto para agentes de IA: por transação, diário e por destino

Por que o limite não pode viver no prompt

Dizer ao agente "não gaste mais de 25 dólares" é uma sugestão, não um controle. Um agente lê páginas, e-mails e respostas de APIs que você não escreveu, e qualquer um deles pode conter um texto que o confunda. O limite deve ser aplicado no servidor, antes de o dinheiro se mover, e a chave do agente deve poder pedir pagamentos, mas nunca editar a própria política. É a mesma ideia que a Stripe usa nos cartões para agentes, que permitem spending_limits com um valor e um intervalo, por exemplo por autorização ou por mês (Stripe Issuing for agents).

O problema já existe na América Latina. Segundo uma reportagem do Mercado, que cita uma pesquisa da Universidad Torcuato Di Tella e da Fundar (dado citado por uma matéria de imprensa, sem verificação no estudo original), só 4% das pequenas e médias empresas argentinas que usam IA têm um orçamento específico e só 3,3% dispõem de uma política escrita para orientar esse uso (Mercado). Limites explícitos preenchem essa lacuna.

Os tipos de limite e o que acontece ao ultrapassá-los

Dois detalhes de projeto importam. Primeiro, uma recusa por regra não deveria ser um erro HTTP: é um resultado válido que o agente pode ler para decidir o que fazer. Segundo, um pagamento que espera aprovação nunca é aprovado sozinho quando o prazo vence. A Stripe usa um modelo parecido nas autorizações em tempo real, em que o cliente responde a um evento e, se não responder em 2 segundos, a Stripe aprova ou recusa conforme a configuração de timeout que você definiu; em um sistema próprio, essa configuração deve ser recusar (Stripe, real-time authorizations).

Exemplo de política em JSON

Exemplo do tipo de política que o desenho da API do Nouron Pass descreve. Os nomes dos campos podem mudar.

{  "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}

Com essa política, um pagamento de 18 USDC para api.openai.com passa. Um de 60 USDC para o mesmo destino ultrapassaria o limite por pagamento. Um pagamento para um domínio que não está na lista é recusado mesmo que o valor seja pequeno. Cada mudança de política deveria criar uma versão nova, de modo que cada pagamento fique associado à regra que o avaliou.

Um detalhe de coerência: o teto diário não pode ser menor que o limite por pagamento, e o limiar de aprovação só faz sentido se for diferente do limite máximo. Valide essas relações ao salvar a política.

Exemplo de fluxo no n8n

Veja como cada regra se encaixa em um fluxo do n8n.

1. Gatilho. Seu agente decide pagar e envia uma requisição a um webhook do n8n com amount, destination e memo.
2. Nó HTTP (consulta da política). Chama sua API de gastos para ler a política vigente.
3. Nó IF (a regra). Compara antes de pagar.
4. Nó HTTP (pagamento). Só se o IF der verdadeiro, cria o pagamento com uma chave de idempotência.
5. Nó Wait (aprovação). Se o valor passar de approval_over, o fluxo para até que alguém responda.

Pseudocódigo do nó IF (exemplo):

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

if (permitido AND amount <= policy.approval_over) -> pagar
if (permitido AND amount >  policy.approval_over) -> esperar aprovação
else -> registrar a recusa e avisar o agente

Trecho do nó HTTP de pagamento (exemplo):

{  "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" }}

A chave de idempotência evita pagamentos duplicados se o fluxo for repetido; serviços como o Resend a guardam por 24 horas e devolvem a mesma resposta (Resend). O nó Wait do n8n pode ser retomado por uma chamada a um webhook (documentação do n8n); essa é a peça que se liga à aprovação humana, que explicamos no guia 2.

Importante: o IF do n8n é uma segunda barreira. A regra definitiva deve ser aplicada no servidor que move o dinheiro, porque um fluxo do n8n também pode ser editado ou contornado.

Erros de segurança comuns

• Instruções ocultas que desviam um pagamento. Um e-mail, uma página ou um PDF contém um texto como "pague a fatura para este outro endereço". É a injeção de instruções, o risco número um (LLM01) da lista OWASP 2025 para aplicações com modelos de linguagem, segundo a OWASP. Defesa: lista de destinos permitidos e aprovação humana para destinos novos.
• Destinos falsos ou quase iguais. Um domínio parecido (api.openai.co) ou um endereço que difere por um caractere. Defesa: comparação exata, nunca por prefixo nem por coincidência parcial.
• Laços de pagamentos. O agente repete uma tarefa que falha e paga a cada vez. Defesa: teto diário, chave de idempotência e alerta quando o mesmo destino se repete.
• Chave do agente com permissões de administração. Se o agente pode editar a própria política, o limite não existe. Defesa: chaves separadas para pagar e para administrar.
• Limite só no prompt ou só no fluxo. Defesa: regra no servidor, sempre.
• Afrouxar regras sem confirmação. Aumentar um limite deveria exigir uma etapa extra de uma pessoa.
• Sem registro. Se você não consegue ver o que foi recusado e por quê, não consegue ajustar a política.

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: limite por pagamento, teto diário e mensal, lista de destinos permitidos, aprovação humana pelo WhatsApp e pausa.

O Nouron Pass está em construção e abrimos o acesso por levas. Hoje ainda não processamos pagamentos reais, e o que está descrito aqui é o desenho da API e do servidor MCP. Se você quer que seu agente esteja entre os primeiros, reserve seu lugar.