Edição em Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Pagamentos do Anchor Browser e do AgentCore: como um agente atravessa um paywall x402

> O Anchor Browser pode tentar novamente uma página ou chamada de API cobrada via x402 por meio do AgentCore payments quando o desenvolvedor habilita a sessão e configura um instrumento de pagamento autorizado e com orçamento definido.

By BIG CHANGE Editorial

Published: 2026-10-14T05:55:23.177Z
Updated: 2026-10-14T05:55:23.177Z
Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments

![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product.

AWS e Anchor Browser [documentaram uma integração](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) 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](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) 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](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/), `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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) 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](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits).

## Fontes e leituras adicionais

- [AWS e Anchor Browser, “Building agents that transact with Anchor Browser and AgentCore payments”](https://aws.amazon.com/blogs/machine-learning/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”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) (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”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) (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”](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) (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.

## Sources

- [AWS Machine Learning Blog, Building agents that transact with Anchor Browser and AgentCore payments](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — Tutorial principal de integração. Documenta o padrão de session.x402 e a habilitação de pagamentos reais, a sequência navegador/AgentCore, uma única nova tentativa e o retorno inalterado do 402 original nas falhas listadas. Esse é o comportamento descrito pelo fornecedor; a BIG CHANGE não executou uma sessão paga. A alegação separada sobre créditos/faturamento consolidados do Anchor não foi comparada de forma independente com a documentação de financiamento de carteira do AgentCore e não é repetida como modelo universal de cobrança.
- [AWS, How AgentCore payments works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — Referência mantida sobre arquitetura e controles do serviço. Define Payment Manager, connector, identity credential provider, instrumento, limites e expiração da sessão, concessão da carteira do usuário, fluxo de pagamento e observabilidade. O fluxo x402 geral usa X-PAYMENT; o tutorial específico do Anchor distingue o cabeçalho PAYMENT-SIGNATURE do x402 v2.
- [AWS, AgentCore payments quick start](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — Caminho de configuração e pré-requisitos, incluindo conexão com Coinbase ou Stripe Privy, instrumento financiado, autorização delegada de assinatura e sessão de pagamento com prazo. Valores e durações de exemplo não são padrões nem limites do Anchor.
- [AWS, Troubleshooting AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — Documenta problemas de permissão, assinatura, concessão da carteira, credenciais e payload x402. Erros do serviço complementam o comportamento de retorno do 402 original no tutorial do Anchor Browser; nenhuma rota de falha foi testada aqui.