AWS e Anchor Browser documentaram uma integração que permite a um agente de navegador pagar por 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 do Amazon Bedrock AgentCore payments e tentar a solicitação novamente. Para o desenvolvedor, a mudança importante é onde isso acontece: o navegador lida com o desafio e a nova tentativa, enquanto um serviço de pagamento configurado separadamente verifica a autorização para gastar.

A grande mudança

  • O que mudou:Uma solicitação web paga pode ser concluída na sessão de navegador do agente após um desafio x402, sem colocar uma chave de carteira ou um cabeçalho de pagamento no código de automação. O desenvolvedor precisa habilitar explicitamente os pagamentos nessa sessão.
  • Por que isso importa:Agentes que usam dados ou conteúdo cobrados por solicitação podem continuar o mesmo fluxo de trabalho, enquanto o instrumento de pagamento, as permissões de identidade e o limite de gastos ficam fora da página e do ambiente de execução do agente. Isso transfere a decisão real de compra para uma infraestrutura que o operador precisa configurar e monitorar.
  • 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 automação; os desenvolvedores ainda precisam lidar com essa resposta.

O que o navegador faz em uma página paga

O tutorial da AWS e do Anchor descreve o fluxo de navegação de documentos, fetch ou XMLHttpRequest em uma sessão do Anchor Browser. O comerciante retorna HTTP 402 Payment Required com um desafio de pagamento. O Anchor lê os termos e procura um método compatível com o instrumento de pagamento vinculado à sessão. O AgentCore verifica o orçamento restante da sessão e usa o provedor de carteira configurado para assinar uma prova. O navegador adiciona essa prova à solicitação original e a tenta novamente uma vez, usando 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 com um endpoint pago. Segundo a AWS, o navegador mantém o contexto da sessão durante o pagamento e a nova tentativa. Fluxos existentes de Playwright, Puppeteer e Chrome DevTools Protocol podem continuar navegando ou chamando APIs pelo navegador sem construir os cabeçalhos de pagamento. Um pagamento bem-sucedido também não torna todo paywall acessível: o site precisa apresentar um desafio x402 compatível, e o comerciante continua decidindo se aceita a prova e entrega a resposta.

O que o desenvolvedor precisa habilitar

A chave do navegador é explícita. Em a solicitação de sessão do tutorial, session.x402 tem como padrão false; defini-la como true autoriza pagamentos reais pelo instrumento configurado. Uma chave de API do Anchor também é necessária para criar a sessão do navegador. A opção é a última conexão com a autoridade de pagamento, não um substituto para configurá-la.

O guia de pagamentos do AgentCore da AWS descreve os recursos subjacentes. Payment Manager define a configuração de pagamento da conta AWS e usa uma função IAM e um autorizador. Payment Connector se conecta à Coinbase Developer Platform ou à Stripe Privy. Payment Credential Provider mantém as credenciais do provedor por meio do AgentCore Identity. Payment Instrument identifica a carteira e a rede usadas na compra. A sessão do navegador é vinculada a um AgentCore Payment Session com limite de gastos e expiração. O guia de início rápido da AWS também exige que o instrumento tenha fundos e que o usuário conceda ao agente permissão delegada de assinatura antes de ele pagar.

Esses são controles distintos. IAM governa o acesso ao serviço; a concessão da carteira do usuário permite assinar; o instrumento determina a origem dos fundos e a rede; e o limite da sessão restringe os gastos ao longo do tempo. A AWS diz que o AgentCore nega novos pagamentos 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 provedor fora do navegador e do ambiente de execução do agente, mas o operador ainda precisa escolher o instrumento e o limite adequados ao trabalho.

Onde o fluxo automatizado para

O comportamento de falha documentado pelo Anchor é específico: se o desafio 402 estiver malformado, nenhuma rede compatível for oferecida, o orçamento acabar ou o AgentCore recusar o pagamento, o navegador devolve a resposta 402 original à página sem alterações. Portanto, a automação deve considerar um 402 como possível mesmo numa sessão habilitada. O guia de solução de problemas da AWS identifica outras falhas de configuração, incluindo permissão IAM ausente, concessão delegada de assinatura inativa, credenciais inválidas do provedor e, para Coinbase, ausência de assinatura do Marketplace.

A chave session.x402 aplica-se a pagamentos de recursos de terceiros. A AWS diz que ela não paga a sessão do Anchor Browser nem substitui créditos Anchor. O tutorial menciona limites de gastos e de tempo da sessão, mas aponta 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 solicitação de terceiros depende do desafio do comerciante e da liquidação real. Não verificamos uma fatura ou transação de ponta a ponta, então o artigo não pode informar um preço universal para uma sessão habilitada.

Para os desenvolvedores, a decisão prática vem antes de o agente chegar a uma URL paga: conectar um instrumento financiado e autorizado, definir um orçamento para a sessão do navegador e habilitar x402 somente quando houver intenção de compra. O navegador pode retirar o código do protocolo de pagamento do caminho de navegação. Isso não elimina a responsabilidade do operador pela autoridade de gastos, pelas solicitações com falha ou pela conferência do valor realmente cobrado pelo comerciante. Essa questão de autoridade também atravessa nossa análise mais ampla das opções de pagamento para agentes de IA.

Fontes e leituras adicionais

  • 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 opção de ativação no navegador, o desafio x402, os cabeçalhos de pagamento específicos de cada versão e o retorno do 402 original em caso de falha. Ele descreve o fluxo pretendido; não testamos uma sessão paga.
  • AWS, “How AgentCore payments works” (guia para desenvolvedores, acessado em 14 de outubro de 2026). Explica Payment Manager, conectores de provedores, credenciais de identidade, instrumentos, sessões de gastos e observabilidade. É o desenho geral do serviço, junto do tutorial específico para navegador.
  • AWS, “AgentCore payments quick start” (guia para desenvolvedores, acessado em 14 de outubro de 2026). Apresenta as etapas para configurar credenciais do provedor, instrumento financiado e autorizado e sessão de pagamento. Orçamentos e durações de exemplo são ilustrativos, não padrões verificados do Anchor.
  • AWS, “Troubleshooting AgentCore payments” (guia para desenvolvedores, acessado em 14 de outubro de 2026). Lista erros de IAM, provedor, concessão da carteira, assinatura e payload x402 que podem impedir o pagamento. Não reproduzimos esses erros.