Como um agente de IA paga: protocolos e riscos

A pergunta que trava toda conversa sobre agent commerce é a mesma: como o agente paga?

Vale começar separando o que é mecanismo do que é aposta. O mecanismo é razoavelmente claro e não depende de nenhum padrão vencer. A aposta é o formato — e aí o cenário é de disputa aberta, com propostas circulando de bandeiras de cartão, de provedores de pagamento e de fabricantes de modelos. Nenhuma delas é padrão de mercado hoje, e tratar qualquer uma como tal é o jeito mais rápido de comprar retrabalho.

Este texto fica no mecanismo.

O problema de fundo é delegação, não pagamento

Pagar é o último passo. O passo difícil é o anterior: uma pessoa precisa transferir a um programa parte da sua autoridade de gastar, e essa transferência precisa ser limitada, verificável e revogável.

É uma família de problemas velha em computação — procuração, escopo, mandato — que a indústria já resolveu em outros contextos. O que é novo é o agente decidir sozinho o que comprar dentro do escopo, não só executar uma ordem exata.

Toda a discussão cabe em quatro perguntas, e um desenho ruim é sempre um desenho que deixa uma delas sem resposta:

1. Quem autorizou? Qual pessoa, autenticada como, quando.
2. O quê, exatamente? Este item, esta categoria, este comerciante, qualquer coisa.
3. Dentro de que limites? Teto por transação, teto acumulado, validade, frequência.
4. Como se prova depois? O que fica registrado, de forma que sobreviva a uma contestação.

Os modelos de delegação que já existem

Não é preciso inventar do zero. Vale olhar o que o mundo já usa, porque as propostas novas são recombinações disso.

Cartão salvo. O modelo mais comum e o mais frouxo: a credencial fica guardada e é usada de novo. Não tem escopo, não tem teto próprio, não tem validade além da do cartão. Entregar isso a um agente é o equivalente digital de deixar a carteira em cima da mesa.

Token de rede. Em vez da credencial real, circula um substituto, que pode ser restrito a um comerciante e revogado sem trocar o cartão. É um avanço grande de contenção — e a base sobre a qual boa parte das propostas de pagamento agêntico se apoia.

Mandato de débito. A lógica de débito automático e de autorizações recorrentes: o titular concorda antes com regras — quem pode cobrar, até quanto, com que frequência — e as cobranças seguintes acontecem sem ele presente. No Brasil, o arranjo de pagamentos instantâneos do Banco Central inclui a modalidade de autorização prévia para débitos recorrentes, que é conceitualmente muito próxima do que um agente precisa.

Autorização por escopo. O padrão de delegação da web: uma aplicação recebe permissão limitada para agir em nome de alguém, com escopo e expiração, sem nunca ver a senha. O OAuth 2.0 é a base; extensões como requisições de autorização detalhada permitem descrever a permissão com granularidade — não “pode pagar”, mas “pode pagar até este valor, neste comerciante, até esta data”.

Nenhum desses modelos foi desenhado para agente autônomo. Mas juntos eles descrevem bem o formato da solução: credencial substituta, com escopo declarado, teto, validade e revogação.

Autenticação: o agente não é o humano

Um erro conceitual comum é tentar fazer o agente se passar pelo titular. Isso é péssimo por dois motivos: quebra qualquer possibilidade de auditoria e joga fora a distinção que torna o risco administrável.

O desenho correto tem duas identidades:

• a do humano, verificada com força no momento da delegação — é aqui que entram autenticação forte, chave de acesso vinculada ao dispositivo, verificação do emissor;
• a do agente, que age depois apresentando a credencial delegada e a própria identidade.

A consequência prática é importante: a verificação do humano acontece na autorização, não na execução. É por isso que o código por SMS no meio do checkout não se sustenta — ele pede presença justamente quando ela foi delegada. O que precisa viajar até a loja não é o humano, é a prova de que ele autorizou. O impacto disso no fluxo de compra está em checkout para agentes.

Prova de intenção: o que precisa ficar registrado

Chamo de prova de intenção o pacote que acompanha a transação e permite responder, meses depois, o que foi combinado. Independentemente de formato, ele precisa carregar:

• identificação do titular e do agente;
• escopo: comerciante, categoria, item específico quando houver;
• limite: valor máximo por transação e acumulado;
• validade: início e fim;
• momento e força da autenticação do humano;
• instrução original, ou um resumo verificável dela;
• proteção contra adulteração e contra reuso.

Os dois últimos itens são os que separam um registro sério de um campo de texto. Adulteração se resolve com assinatura — a especificação de assinaturas de mensagem HTTP, por exemplo, descreve como assinar partes de uma requisição de modo verificável. Reuso se resolve com identificador único, validade curta e vínculo com o destinatário: um mandato emitido para uma loja não pode valer em outra.

E há um detalhe que costuma passar batido: a instrução original importa. “Compre a ração de 15 kg da marca X até 200 reais” e “compre ração” produzem transações com risco muito diferente. Guardar só o valor final apaga a diferença.

O elo mais fraco: quem responde quando dá errado

Aqui é onde a honestidade é obrigatória. As regras de contestação que existem hoje foram escritas para dois cenários: o titular reconhece a compra, ou a credencial foi usada por terceiro sem autorização.

O agent commerce cria um terceiro cenário que não se encaixa bem em nenhum dos dois: o agente estava autorizado e comprou errado. Interpretou mal a instrução, escolheu a variante errada, não entendeu que “até sexta” era condição e não preferência.

Isso não é fraude no sentido clássico, e também não é compra reconhecida. É defeito de execução por um mandatário automático. Quem absorve — titular, emissor, comerciante ou o operador do agente — não é uma pergunta técnica; é uma pergunta de regra, e ela está em aberto.

O que dá para fazer enquanto isso, dos dois lados:

Do lado de quem opera o agente: teto baixo por transação, confirmação humana para o que é irreversível ou caro, categoria em lista permitida, registro de toda chamada de ferramenta com identificador de rastreio. São os mesmos portões que um agente vertical bem desenhado já precisa ter para qualquer ação com efeito no mundo real — gastar dinheiro é só o caso mais óbvio.

Do lado da loja: guardar os campos de autorização junto ao pedido, mesmo que hoje ninguém os cobre. Quando a disputa acontecer, quem tem o registro discute com dado; quem não tem discute com versão.

Riscos específicos que o desenho precisa cobrir

• Instrução envenenada. O agente lê conteúdo da web para decidir. Página de produto com texto instruindo o agente a comprar outra coisa é um vetor real. A defesa está em separar dado lido de instrução confiável, e em nunca deixar que conteúdo de terceiro amplie o escopo já concedido.
• Laço de repetição. Falha de rede, reenvio, pedido duplicado. Idempotência não é conforto de engenharia, é contenção financeira.
• Escalada de escopo. Autorização concedida para uma compra sendo reaproveitada para outra. Resolve-se com validade curta e vínculo com o destinatário.
• Coleta indevida de dado. O agente não precisa do número do cartão para comprar; precisa de uma credencial substituta. Qualquer desenho que faça a credencial real transitar pelo agente está errado por construção.
• Bloqueio por antifraude cego. Recusar tudo que não parece humano é a forma mais silenciosa de perder venda legítima, e ela não aparece em relatório nenhum.

O que fazer hoje, sem apostar no vencedor

A recomendação prática é conservadora de propósito:

1. Não entregue credencial crua a agente. Se hoje o seu fluxo depende disso, trate como dívida.
2. Prefira mecanismos com escopo, teto e validade entre os que já existem, mesmo que imperfeitos.
3. Registre a autorização junto do pedido. Campos simples, desde já.
4. Aceite idempotência e devolva erro tipado. Vale para qualquer padrão futuro.
5. Não recuse tráfego automatizado por padrão. Identifique, meça e crie uma faixa de verificação reforçada.
6. Acompanhe as propostas sem casar com nenhuma. O custo de trocar de formato é pequeno quando os dados estão guardados; é enorme quando a regra está espalhada pelo código.

Esses seis itens aparecem, com outras palavras, no diagnóstico de prontidão da loja — e é de propósito. Preparação para pagamento agêntico é, em boa medida, a mesma higiene de integração que o resto da compra já exigia.

O que levar desta leitura

Pagamento por agente não é uma tecnologia de pagamento nova. É um problema de delegação de autoridade resolvido com peças que já existem: credencial substituta, escopo declarado, teto, validade, autenticação forte no momento certo e um registro assinado do que foi combinado.

O que ainda não existe é consenso de formato nem regra clara de responsabilidade. Por isso a postura correta agora é construir o que sobrevive a qualquer desfecho — e desconfiar de quem afirma que a compra por IA já tem padrão fechado. Não tem.