AID-Guard fecha a janela entre autorização e efeito real de agentes de IA que interagem com Stripe e outras APIs de pagamento

Agentes de IA que executam tarefas delegadas cada vez mais produzem 'efeitos' reais junto a provedores externos — cobrar um cartão via Stripe, enviar um e-mail via Resend — mas a maioria dos esquemas de autorização de agentes hoje só checa permissão no momento da admissão do pedido e depois perde o rastro: se a requisição muda de estado, a resposta se perde na rede, ou uma retentativa é disparada após timeout, uma única aprovação original pode acabar gerando dois efeitos reais no mundo (por exemplo, cobrança duplicada), porque autorização e execução ficaram dessincronizadas ao longo do tempo.

AID-Guard resolve isso tratando autorização como um protocolo com estado que acompanha toda a vida do efeito, não um selo aplicado uma vez. Na prática, o sistema revalida a requisição aprovada e o estado atual do provedor no momento do commit (não apenas na admissão), mantém uma única reserva sob condições de ambiguidade (por exemplo, resposta perdida) em vez de permitir múltiplas tentativas concorrentes, e só libera a reserva ou permite um sucessor depois de um resultado terminal confirmado ou de uma certificação de 'nenhum efeito ocorreu' com uma cerca de entrega (delivery fence) que impede duplicação.

A validação combina um protótipo em Python/SQLite testado num domínio MCP loopback (13 mutações reais sem efeitos não autorizados, três históricos concorrentes linearizáveis, evidências verificáveis publicamente) com testes reais de integração: todos os 210 testes de contrato com a API da Stripe bateram com o resultado predeclarado, e 40 cronogramas de sucessor terminal, 30 corridas concorrentes sobrepostas e 10 cronogramas de recuperação de falha em Stripe e Resend completaram sem efeito duplicado. Sob comprometimento total do lado que propõe as ações (o pior caso, onde o atacante controla completamente as propostas), o protocolo bloqueou 44 de 44 ataques e ainda assim admitiu 44 de 44 propostas legítimas equivalentes — mostrando que a defesa distingue corretamente entre ataque e uso legítimo mesmo sob adversário forte.

O trade-off relevante para quem for adotar esse tipo de controle é que o perfil mais estrito de aplicação (exigir manifesto exato) reduziu utilidade benigna entre 35,4 e 43,8 pontos percentuais em relação ao baseline sem essa restrição — um custo real de fricção operacional. Os autores propõem um perfil intermediário ('typed frontier') que recupera boa parte dessa utilidade perdida sem reintroduzir efeitos inseguros observados, sugerindo que produtos reais provavelmente vão precisar escolher um ponto nessa curva de segurança-vs-utilidade em vez do extremo mais rígido.