A AWS e o Anchor Browser documentaram uma integração que permite a um agente de navegador pagar uma página ou API protegida por x402 durante a sessão existente. O navegador pode responder a um desafio de pagamento HTTP 402, obter uma prova de pagamento assinada pelo Amazon Bedrock AgentCore payments e repetir o pedido. Para o programador, a mudança importante é o local onde esse trabalho decorre: o navegador trata do desafio e da repetição, enquanto um serviço de pagamento configurado separadamente verifica a autorização para gastar.

A grande mudança

  • O que mudou:Um pedido Web pago pode ser concluído na sessão de navegador do agente após um desafio x402, sem incluir uma chave de carteira ou um cabeçalho de pagamento no código de automatização. O programador tem de ativar explicitamente os pagamentos para essa sessão.
  • Porque é importante:Os agentes que utilizam dados ou conteúdos com pagamento por pedido podem continuar o mesmo fluxo de trabalho, enquanto o instrumento de pagamento, as permissões de identidade e o limite de despesa ficam fora da página e do ambiente de execução do agente. A decisão de compra efetiva passa para uma infraestrutura que o operador tem de configurar e monitorizar.
  • O que observar:O limite relevante é a resposta 402 original. Um desafio malformado, uma rede de pagamento incompatível, um orçamento esgotado ou um pagamento recusado deixam o recurso indisponível para a automatização; os programadores continuam a ter de tratar essa resposta.

O que o navegador faz numa página paga

O tutorial da AWS e do Anchor descreve o fluxo para uma navegação de documento, fetch ou XMLHttpRequest numa sessão do Anchor Browser. O comerciante devolve HTTP 402 Payment Required com um desafio de pagamento. O Anchor lê as condições e procura um método compatível com o instrumento de pagamento associado à sessão. O AgentCore verifica o orçamento restante e utiliza o fornecedor de carteira configurado para assinar uma prova. O navegador acrescenta essa prova ao pedido original e repete-o uma vez, utilizando PAYMENT-SIGNATURE para x402 v2 ou X-PAYMENT para v1. O comerciante verifica e liquida o pagamento antes de devolver o recurso.

Esta é uma sequência documentada, não um teste da BIG CHANGE a um ponto de acesso pago. A AWS afirma que o navegador mantém o contexto da sessão durante o pagamento e a repetição. Os fluxos de trabalho existentes de Playwright, Puppeteer e Chrome DevTools Protocol podem continuar a navegar ou a chamar APIs através do navegador sem construir os cabeçalhos de pagamento. Um pagamento bem-sucedido também não torna todas as barreiras pagas legíveis: o site tem de apresentar um desafio x402 suportado e o comerciante continua a decidir se aceita a prova e entrega a resposta.

O que o programador tem de ativar

O interruptor do navegador é explícito. No pedido de sessão do tutorial, session.x402 tem o valor predefinido false; defini-lo como true autoriza pagamentos reais a partir do instrumento configurado. Também é necessária uma chave de API do Anchor para criar a sessão do navegador. A opção é a ligação final à autoridade de pagamento, não um substituto para a configurar.

O guia de pagamentos do AgentCore da AWS descreve os recursos subjacentes. O Payment Manager define a configuração de pagamento da conta AWS e utiliza uma função IAM e um autorizador. O Payment Connector liga-se à Coinbase Developer Platform ou à Stripe Privy. O Payment Credential Provider guarda as credenciais do fornecedor através do AgentCore Identity. O Payment Instrument identifica a carteira e a rede utilizadas na compra. A sessão do navegador está associada a um AgentCore Payment Session com limite de despesa e prazo de validade. O início rápido da AWS também exige que o instrumento tenha fundos e que o utilizador conceda ao agente autorização delegada para assinar antes de este poder pagar.

São controlos distintos. O IAM gere o acesso ao serviço; a autorização da carteira do utilizador permite assinar; o instrumento determina a origem dos fundos e a rede; e o limite da sessão restringe a despesa ao longo do tempo. A AWS afirma que o AgentCore recusa pagamentos adicionais quando a sessão expira ou atinge o limite. O serviço de observabilidade expõe tentativas e resultados de pagamento no CloudWatch. A integração mantém os segredos do fornecedor fora do navegador e do ambiente de execução do agente, mas o operador continua a ter de escolher o instrumento e o limite adequados ao trabalho.

Onde o fluxo automatizado termina

O comportamento de falha documentado pelo Anchor é específico: se o desafio 402 estiver malformado, não for oferecida uma rede compatível, o orçamento se esgotar ou o AgentCore recusar o pagamento, o navegador devolve a resposta 402 original à página sem alterações. A automatização deve, por isso, considerar a possibilidade de uma resposta 402 mesmo numa sessão ativada. O guia de resolução de problemas da AWS identifica outras falhas de configuração, incluindo permissões IAM em falta, autorização delegada de assinatura inativa, credenciais inválidas do fornecedor e, para a Coinbase, uma subscrição Marketplace em falta.

O interruptor session.x402 aplica-se a pagamentos de recursos de terceiros. A AWS afirma que não paga a sessão do Anchor Browser nem substitui os créditos Anchor. O tutorial refere limites de despesa e de tempo da sessão, mas remete para a documentação técnica do Anchor quanto aos limites específicos; esses detalhes não estavam disponíveis para este artigo. O custo de cada pedido a terceiros depende do desafio do comerciante e da liquidação efetiva. Não verificámos uma fatura nem uma transação de ponta a ponta, pelo que o artigo não pode apresentar um preço universal para uma sessão ativada.

Para os programadores, a decisão prática surge antes de o agente chegar a um URL pago: ligar um instrumento financiado e autorizado, definir um orçamento para a sessão do navegador e ativar x402 apenas quando se pretendem compras. O navegador pode retirar o código do protocolo de pagamento do percurso de navegação. Não elimina a responsabilidade do operador pela autorização de despesa, pelos pedidos falhados ou pela verificação do valor efetivamente cobrado pelo comerciante. Essa questão da autoridade também atravessa a nossa análise mais ampla das opções de pagamento para agentes de IA.

Fontes e leitura adicional

  • AWS e Anchor Browser, “Building agents that transact with Anchor Browser and AgentCore payments” (13 de outubro de 2026). O tutorial de integração documenta a ativação opcional do navegador, o desafio x402, os cabeçalhos de pagamento específicos de cada versão e a devolução da resposta 402 original nos casos de falha. Descreve o fluxo previsto; não testámos uma sessão paga.
  • AWS, “How AgentCore payments works” (guia para programadores, consultado a 14 de outubro de 2026). Explica o Payment Manager, os conectores de fornecedores, as credenciais de identidade, os instrumentos, as sessões de despesa e a observabilidade. É a conceção geral do serviço, em conjunto com o tutorial específico do navegador.
  • AWS, “AgentCore payments quick start” (guia para programadores, consultado a 14 de outubro de 2026). Apresenta a configuração das credenciais do fornecedor, do instrumento financiado e autorizado e da sessão de pagamento. Os orçamentos e durações de exemplo são ilustrativos, não valores predefinidos verificados do Anchor.
  • AWS, “Troubleshooting AgentCore payments” (guia para programadores, consultado a 14 de outubro de 2026). Enumera erros de IAM, fornecedor, autorização de carteira, subscrição e payload x402 que podem impedir o pagamento. Não reproduzimos estes erros.