Aplicação de limites de gastos de agentes no x402, no AP2 e no checkout delegado

Objetivo

Situação em 25 de outubro de 2026. Tornar cada pagamento atribuível a uma autorização limitada do usuário, incluindo compras sem supervisão e novas tentativas. Confira novamente o escopo do x402, os esquemas de restrições do AP2 e a versão datada do ACP escolhida antes de implementar este procedimento proposto. Os campos dos protocolos dão suporte aos controles; um componente independente de controle precisa efetivamente aplicá-los.

Pré-requisitos

Use um gateway de pagamento ou um componente de assinatura que aplique a política fora do modelo, um registro persistente de autorizações, interfaces de aprovação autenticadas e acesso aos registros de status de pagamento. Defina quem é responsável pelas transações não resolvidas. Registre a revisão do protocolo, a moeda ou o ativo, a representação do valor, os destinos permitidos e a validade de cada autorização antes de permitir gastos.

Passos

1. Defina um limite por transação. O Payment Mandate do AP2 define payment.amount_range. A permissão delegada do ACP fornece max_amount, moeda e validade. No x402, compare os requisitos de pagamento anunciados com a política local antes de assinar. Aplique o limite ao valor final autorizado, incluindo as cobranças que compõem o total do checkout.

2. Contabilize os gastos acumulados. O payment.budget do AP2, usado com payment.agent_recurrence, exige que a soma do valor solicitado com os valores dos mandatos fechados anteriores permaneça dentro do máximo; a aprovação acrescenta o valor ao total acumulado. Implemente a verificação e a reserva de forma atômica em armazenamento compartilhado. Como regra de contabilização proposta, mantenha os valores de tentativas não resolvidas comprometidos no orçamento até que seus resultados sejam conciliados. A especificação principal do x402 exclui a gestão de orçamento do lado do cliente.

3. Restrinja os destinos e os instrumentos. O AP2 oferece checkout.allowed_merchants, além de restrições ao beneficiário e ao instrumento de pagamento. O ACP vincula sua permissão a um comerciante e a uma sessão de checkout. No x402, mantenha uma lista externa de permissões que cubra a origem do recurso, o destinatário do pagamento, o ativo e a rede. Não trate o texto descritivo de um comerciante como uma identidade verificada.

4. Vincule a aprovação humana a condições concretas. Mostre ao comprador o destino, os itens, o valor integral, o instrumento de pagamento e a validade. No caso de delegação prévia, mostre os limites permitidos. O modelo de autorização do AP2 exige a avaliação das restrições e trata restrições desconhecidas como falhas. Sua resposta unresolved_constraint pode desencadear a aprovação direta. Como política local, exija nova aprovação para alterações fora do escopo aprovado, mesmo que uma credencial de pagamento continue tecnicamente utilizável.

5. Vincule as evidências sem vazar credenciais. Registre as referências de aprovação e de mandato, a decisão da política, o valor reservado, o identificador do checkout ou recurso, o identificador do pagamento e o resultado final. Os Payment Receipts do AP2 se vinculam ao mandato fechado e contêm o status do pagamento. Mantenha credenciais assinadas sensíveis em um repositório de evidências com acesso restrito; os logs de auditoria rotineiros devem conter referências, em vez de material de pagamento reutilizável. Concilie pagamento e entrega separadamente.

6. Teste os caminhos de recusa antes do lançamento. Em um ambiente fora de produção, teste uma aprovação vencida, um comerciante não permitido, uma moeda alterada, um valor acima do limite, compras simultâneas e uma resposta interrompida. Verifique se as tentativas rejeitadas não criam novas autorizações e se as tentativas não resolvidas não restabelecem silenciosamente a capacidade de gasto. Estas são verificações de aceitação propostas, e não resultados de testes realizados.

Resultado esperado

Cada tentativa permitida tem uma aprovação rastreável, uma reserva de orçamento e, posteriormente, um resultado conciliado. As solicitações rejeitadas continuam explicáveis sem conceder ao modelo autoridade para anular a decisão. Quem faz a revisão consegue distinguir os gastos solicitados, autorizados e concluídos.

Limites e base de verificação

Este procedimento não foi testado com provedores de pagamento. Orçamentos que abrangem vários provedores exigem contabilização compartilhada além dos objetos individuais de cada protocolo. A tabela de intervalos de valores do AP2 especifica unidades monetárias mínimas inteiras, enquanto um exemplo usa decimais; resolva essa inconsistência no contrato de implementação antes de aceitar valores. Nenhuma conversão é presumida aqui. Recibos assinados documentam os resultados do protocolo; não comprovam a entrega física.