Créer des agents qui effectuent des transactions avec Anchor Browser et AgentCore payments

Les agents d'IA ont de plus en plus besoin d'accéder à des ressources web facturées à la requête. Par exemple, des jeux de données premium facturent à la requête, des API de recherche comptent par appel, et des éditeurs à péage restreignent l'accès au contenu derrière un paiement. Lorsqu'un agent d'IA rencontre l'une de ces ressources, le serveur renvoie HTTP 402 Payment Required. L'agent ne dispose d'aucun mécanisme de paiement intégré, d'aucun budget associé à la session et d'aucun moyen programmatique de satisfaire la requête. La tâche se bloque et nécessite une intervention manuelle.

Anchor Browser avec Agentic Payments gère les flux de paiement de machine à machine pour le compte de l'agent. Développé en collaboration avec le AWS Generative AI Innovation Center Partner Agent Factory, il est désormais disponible sur AWS Marketplace. Cet article explique comment Anchor Browser s'intègre à Amazon Bedrock AgentCore payments afin que les agents d'IA puissent payer de manière autonome des pages et API protégées par x402. Le protocole x402 est une norme ouverte pour les paiements HTTP de machine à machine. Un serveur répond avec 402 Payment Required ainsi que le montant, les méthodes de paiement acceptées et l'adresse de paiement que l'agent utilise pour effectuer la transaction.

Anchor Browser est une solution d'automatisation de navigateur basée dans le cloud conçue spécifiquement pour les agents d'IA. Chaque session d'agent s'exécute dans un environnement de navigateur géré qui maintient l'état d'authentification, gère la navigation, capture les requêtes réseau et offre une vue en direct des interactions avec les pages.

Amazon Bedrock AgentCore fournit des capacités pour créer, connecter et optimiser des agents à grande échelle. Amazon Bedrock AgentCore payments est une capacité entièrement gérée au sein d'AgentCore que les agents d'IA peuvent utiliser pour découvrir, accéder et payer de manière autonome des API, des serveurs Model Context Protocol (MCP) et du contenu web. AgentCore payments gère la connectivité du portefeuille, applique des limites de dépenses configurables au niveau de l'infrastructure et traite les paiements via le protocole x402. Il fournit également une observabilité des tentatives de paiement, des approbations, des refus et des règlements via Amazon CloudWatch.

Lorsqu'un agent s'exécutant dans Anchor Browser rencontre une réponse 402, AgentCore payments autorise et finalise la transaction dans le budget configuré. Le flux de travail se poursuit sans interruption.

Défis

Lorsqu'un agent autonome rencontre une ressource protégée par x402, le flux de travail se bloque. L'agent effectue une requête, par exemple récupérer un rapport de recherche premium ou appeler une API d'enrichissement de données payante, et le serveur répond avec HTTP 402 Payment Required. Sans mécanisme de paiement, la tâche qui devait s'exécuter de manière autonome nécessite désormais une intervention humaine.

Aujourd'hui, les développeurs doivent construire toute la pile de paiement. Cet effort couvre quatre catégories de complexité :

Gestion du protocole de paiement

• Détecter et analyser le défi 402 dans la réponse HTTP, et distinguer les réponses exigeant un paiement des autres erreurs 4xx.
• Construire l'en-tête de paiement correct avec la preuve cryptographique dans le format exact attendu par le marchand.
• Prendre en charge plusieurs schémas de paiement (exact, upto et variantes de protocole) sans coder en dur une logique spécifique au fournisseur dans l'agent.
• Maintenir la compatibilité entre les implémentations marchandes x402 qui peuvent varier dans le format du défi, les stablecoins pris en charge ou le délai de règlement.

Sécurité et gestion des clés

• Stocker une clé privée pour signer les paiements, ce qui nécessite un stockage sécurisé des clés dans un environnement exposé à des entrées non fiables.
• Gérer les opérations du cycle de vie du portefeuille, y compris la rotation des clés, le renouvellement des identifiants et le basculement vers un autre fournisseur.

Résilience opérationnelle

• Soumettre à nouveau la requête originale avec l'en-tête de paiement tout en préservant l'état de session, les cookies et le contexte de la requête.
• Fournir l'idempotence, essentielle pour les opérations de portefeuille.
• Appliquer des limites de dépense par session et par transaction avec un suivi budgétaire en temps réel sur des exécutions d'agents concurrentes.

Observabilité et conformité

• Enregistrer chaque tentative de paiement, approbation, refus et règlement dans des journaux d'audit à des fins de conformité et de réconciliation.

Sans service de paiement géré, l'agent doit internaliser l'ensemble de la pile de paiement. À chaque appel protégé par x402 qui renvoie une réponse 402, l'agent doit orchestrer lui-même l'intégralité du flux de paiement, notamment :

• Signer la preuve.
• Joindre le bon en-tête.
• Réessayer la requête.
• Régler la transaction.
• Journaliser le résultat.

Chacune de ces étapes nécessite du code personnalisé que les développeurs doivent construire, sécuriser et maintenir. La figure 1 illustre cette architecture. L'agent contient huit composants étroitement couplés (Wallet, Private Keys, Budget Controls, Sign Proof, Attach Header, Retry Logic, Settle Payment et Logging). L'agent se connecte à une API x402 avec un défi 402 qui revient en retour et une nouvelle tentative qui part en avant.

Figure 1 : pile de paiement de l'agent

Les considérations de sécurité vont au-delà de l'effort d'ingénierie.

Dépenses incontrôlées. Sans limites de dépenses strictes appliquées au niveau de l'infrastructure, un bug, une boucle de réessai, une injection de prompt ou un accès involontaire peut déclencher des paiements non souhaités. Un agent qui réessaie un endpoint payant en boucle continue d'autoriser des paiements jusqu'à ce qu'une intervention manuelle ait lieu.

Exposition des clés. Lorsque les clés privées résident dans le runtime de l'agent, elles partagent un environnement d'exécution avec des pages web non fiables, des outils tiers et des dépendances externes. Ces vecteurs peuvent divulguer par inadvertance les identifiants qui contrôlent des fonds réels.

Exposition du flux de signature. Si l'infrastructure de signature est accessible depuis le runtime, un acteur malveillant peut tenter d'accéder à la clé ou de rediriger des paiements vers une adresse placée sous un contrôle non autorisé. Une atténuation efficace exige que la clé n'entre pas dans le runtime dès le départ.

Les agents basés sur un navigateur introduisent une contrainte supplémentaire : le paiement doit avoir lieu au sein de la même session de navigateur. Sinon, les enregistrements de session et la vue en direct ne correspondent plus à ce qui s'est réellement exécuté.

Solution

Anchor Browser et AgentCore payments traitent cette complexité en déplaçant l'intégralité de la pile de paiement vers une infrastructure gérée.

Contrairement à un appel d'outil sans état, Anchor Browser fournit un véritable navigateur cloud avec une identité persistante, des workflows répétables et déterministes, et le contexte de session nécessaire pour se connecter, naviguer et accomplir des tâches de manière fiable. L'authentification, la navigation, les requêtes réseau, les enregistrements et la vue en direct se déroulent au sein de la même session de navigateur. Lorsqu'un paiement est requis, la transaction a lieu dans cette session. L'enregistrement capture la séquence complète, de la requête au 402, en passant par le paiement jusqu'à la livraison du contenu. Les agents Anchor incluent un outil x402 intégré qui gère nativement les appels d'API payants dans le contexte du navigateur. Cet outil intégré ne nécessite aucune modification des workflows existants basés sur Playwright, Puppeteer ou Chrome DevTools Protocol.

AgentCore payments sert de couche de paiement. Au centre du service se trouve le Payment Manager, la ressource de premier niveau qui coordonne les opérations de paiement pour le compte AWS. La création d'un Payment Manager nécessite de spécifier un type d'autorisateur et un rôle IAM. AgentCore provisionne ensuite une identité de workload correspondante dans Amazon Bedrock AgentCore Identity.

Les composants restants connectent le Payment Manager à l'infrastructure de portefeuille externe :

• Un PaymentConnector intègre le Payment Manager à un fournisseur de portefeuille externe, soit Coinbase Developer Platform (Coinbase CDP), soit Stripe Privy.
• Un PaymentCredentialProvider stocke de manière sécurisée les identifiants du fournisseur de portefeuille dans AgentCore Identity.
• Un PaymentInstrument identifie l'adresse de portefeuille spécifique à partir de laquelle les fonds sont prélevés.

Anchor Browser configure les portefeuilles via AgentCore payments en utilisant un fournisseur de portefeuille pris en charge, sans placer de secrets de portefeuille ni de clés privées dans le runtime de l'agent. AgentCore payments gère les opérations de portefeuille par l'intermédiaire du fournisseur configuré. Pour la découverte d'endpoints, AgentCore fournit un serveur MCP Coinbase x402 Bazaar via Amazon Bedrock AgentCore Gateway, afin que les agents puissent découvrir par programmation les endpoints x402 payables à l'usage disponibles.

AgentCore payments restructure l'architecture de paiement. Les opérations sensibles sont déplacées hors du runtime de l'agent vers une couche de service gérée. L'Anchor Agent ne conserve que deux composants liés au paiement : une session budgétaire et l'outil x402. L'infrastructure, comprenant l'authentification, les secrets de portefeuille, les limites de paiement, l'observabilité et la signature de preuve de paiement, réside dans la couche AgentCore payments. La Figure 2 montre l'Anchor Agent se connectant à la couche gérée d'AgentCore payments, qui gère l'intégration du fournisseur de portefeuille avec Coinbase CDP ou Stripe Privy.

Figure 2 : Anchor Browser s'intègre à AgentCore payments

Fonctionnement du flux de paiement

Les étapes suivantes décrivent ce qui se passe de bout en bout, depuis le moment où une session de navigateur rencontre une ressource protégée par x402 jusqu'au moment où l'agent reçoit la réponse et poursuit la tâche.

1. Anchor Browser crée un AgentCore PaymentSession dédié pour la session de navigateur. Lorsque la session démarre avec x402 activé, Anchor Browser provisionne un PaymentSession via AgentCore payments, liant la session de navigateur à un instrument de paiement et à un budget configurés.
2. Le navigateur reçoit une réponse HTTP 402 Payment Required. L'agent navigue vers une URL ou effectue une requête fetch ou XMLHttpRequest (XHR). Le marchand répond par un défi 402 précisant le montant, les moyens de paiement acceptés et l'adresse de paiement.
3. Le navigateur sélectionne un moyen de paiement compatible. Anchor Browser lit la charge utile du défi 402 et fait correspondre le moyen de paiement demandé avec l'instrument lié à la PaymentSession.
4. AgentCore vérifie le budget de la session et génère la preuve de paiement cryptographique. AgentCore payments valide que le montant du paiement respecte la limite de dépense de la session. Le service signe ensuite la transaction à l'aide du fournisseur de portefeuille configuré (Coinbase CDP ou Stripe Privy) et renvoie la preuve cryptographique. Aucun matériel de clé n'entre dans le navigateur ou l'environnement d'exécution de l'agent.
5. Le navigateur réessaie la requête initiale avec l'en-tête de paiement. Le navigateur joint la preuve signée en tant que PAYMENT-SIGNATURE pour x402 v2 ou X-PAYMENT pour x402 v1, puis réessaie la requête initiale exactement une fois.
6. Le marchand vérifie et règle le paiement, puis renvoie la ressource protégée. Le marchand valide la preuve cryptographique, règle la transaction sur la blockchain et sert le contenu. L'agent poursuit sa tâche.

Les identifiants du wallet restent auprès d'AgentCore et du fournisseur de wallet configuré tout au long de ce flux.

Prérequis

Avant de commencer, assurez-vous de disposer d'une clé API Anchor Browser valide (ANCHOR_API_KEY). Pour en créer une, consultez le guide Quick Start d'Anchor Browser.

Configuration des paiements x402 automatiques

La configuration des paiements agentiques pour Anchor Browser nécessite une propriété de session. Définissez session.x402 sur true. La propriété est définie par défaut sur false. Lorsqu'elle est activée, la session du navigateur peut accéder automatiquement aux sites Web protégés par x402 avec des paiements signés par AgentCore payments et relancés au sein de la même session de navigateur. L'activation de session.x402 autorise le navigateur à effectuer de vrais paiements à partir de l'instrument de paiement configuré.

Les exemples suivants montrent comment créer une session avec paiements activés pour Anchor Browser à l'aide de cURL et de JavaScript :

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

Une fois connecté via le protocole Chrome DevTools, l'agent navigue normalement. Vous n'avez pas besoin d'inclure une clé de wallet ni un en-tête de paiement dans votre code d'automatisation. Le navigateur gère de manière transparente les défis 402, la signature des paiements et les nouvelles tentatives pour la navigation dans les documents, ainsi que pour les requêtes fetch et XHR.

Limites et comportement de la session de paiement

Anchor Browser applique les garde-fous suivants au niveau de la session grâce à l'intégration d'AgentCore payments. Chaque session de navigateur prête pour les paiements fonctionne dans le cadre de limites de dépenses et de temps configurées. Pour connaître les limites spécifiques, reportez-vous à la documentation technique d'Anchor Browser.

Si la réponse du marchand est mal formée, si aucun réseau compatible n'est proposé, si le budget est épuisé ou si AgentCore payments rejette le paiement, le navigateur renvoie la réponse 402 d'origine à la page sans modification. Votre code d'automatisation peut alors traiter le 402 comme une erreur HTTP standard.

La propriété de session x402 contrôle uniquement les paiements vers des ressources tierces. Cette propriété ne remplace pas les Anchor credits et ne paie pas la session de navigateur.

Code d'automatisation pour Anchor Browser

Votre code d'automatisation pour Anchor Browser reste inchangé. L'exemple suivant montre qu'aucun code spécifique au paiement n'est requis :

const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');

Aucune logique de wallet, aucune construction d'en-tête de paiement et aucun code de nouvelle tentative. L'agent navigue vers l'URL. Si le serveur renvoie un 402, Anchor Browser se coordonne avec AgentCore payments pour signer la preuve de paiement, relance la requête avec l'en-tête de paiement approprié et fournit le contenu à la page. Votre code d'automatisation reçoit la page finale rendue sans aucune indication qu'un paiement a eu lieu.

Ce modèle s'applique uniformément au journalisme derrière paywall, aux données financières sous licence, à la documentation API restreinte, aux bases de données de recherche avec compteur et aux autres ressources qui limitent l'accès au contenu derrière un défi 402.

Utilisation de l'outil x402 intégré pour les appels API

Les ressources payantes ne se limitent pas aux pages Web. Beaucoup sont des API qui attendent des méthodes POST, PUT ou autres méthodes HTTP. Les exemples courants incluent les services d'enrichissement de données, les points de terminaison d'inférence premium et les API de contenu sous licence. Pour ces cas d'usage, les agents Anchor Browser incluent un outil x402 intégré que vous appelez comme une API HTTPS standard dans le contexte du navigateur.

Votre agent effectue l'appel API via fetch ou XHR. Si le serveur renvoie un défi 402, le navigateur coordonne la signature du paiement via AgentCore payments et relance la requête avec l'en-tête de paiement signé. Votre code reçoit la réponse comme si le point de terminaison était gratuit. L'outil n'est lié à aucun fournisseur, modèle ou framework spécifique. Le paiement fonctionne comme une capacité au niveau de la session, sous votre outillage existant, et aucune modification du code de l'agent n'est requise.

// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
  const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ company_domain: 'example.com' }),
  });
  return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);

Votre code d'automatisation ne reçoit pas les identifiants du wallet. Les paiements automatiques sont disponibles uniquement lorsque session.x402 est défini sur true et restent soumis aux limites de dépenses et d'expiration décrites dans la section précédente.

Avantages clés

Cette intégration déplace le paiement du code applicatif vers la couche d'infrastructure :

Aucune infrastructure de paiement à construire. Aucun SDK de portefeuille à intégrer, aucun analyseur de réponse 402 à écrire, aucune boucle de réessai à implémenter, aucune logique de construction d'en-têtes à maintenir, et aucune journalisation d'audit personnalisée à développer. AgentCore payments gère l'ensemble de la pile de paiement.

Aucune modification des outils existants. Les scripts Playwright, les automatisations Puppeteer, les commandes Chrome DevTools Protocol et les flux d'agents dans Anchor Browser continuent de fonctionner exactement comme avant. Le paiement est une capacité de session attachée au navigateur, et non une modification de la logique de l'agent, des invites ou des définitions d'outils.

Les clés privées n'entrent pas dans le runtime. La signature et le règlement s'effectuent à l'intérieur d'AgentCore payments. Le service communique avec Coinbase CDP ou Stripe Privy via un stockage sécurisé des identifiants dans AgentCore Identity. Le runtime de l'agent n'a pas accès au matériel de clé capable de déplacer des fonds.

Les budgets sont appliqués au niveau de l'infrastructure. Chaque session opère dans des limites de dépenses définies qu'AgentCore fait respecter avant d'autoriser un paiement. Amazon Bedrock AgentCore Observability fournit des pistes d'audit de paiement complètes via Amazon CloudWatch. Lorsqu'une session atteint la limite de dépenses, AgentCore payments refuse le paiement.

Les tâches payantes se terminent avec succès. Les pages GET payantes se chargent. Les appels API payants renvoient des réponses. L'agent termine le flux de travail au lieu de s'arrêter à une réponse 402 et de nécessiter une intervention manuelle.

La facturation est consolidée. Anchor Browser règle les frais tiers x402 en crédits sur la même facture que le temps de session de navigation. Il n'y a pas de garde cryptographique distincte à gérer, pas de solde USDC à surveiller, et pas de règlement on-chain à réconcilier pour l'équipe financière.

Conclusion

Anchor Browser, intégré aux paiements AgentCore, permet aux agents IA de relever de manière autonome les défis de paiement x402 pour les pages web à accès payant et les points de terminaison API payants. Les identifiants du portefeuille restent hors du code des agents, et aucune infrastructure de paiement personnalisée n'est requise.

À mesure que davantage du web adopte la tarification par requête, les agents dépourvus de mécanisme de paiement ne peuvent pas accomplir de tâches impliquant des ressources payantes. Cette intégration comble cette lacune : les agents exécutent des flux de travail payants de bout en bout, en respectant des budgets définis, avec une observabilité complète grâce à AgentCore Observability, et sans matériel cryptographique de clés dans l'environnement d'exécution.

Pour démarrer, explorez les ressources suivantes :

• Paiements x402 automatiques dans Anchor Browser
• Guide du développeur des paiements AgentCore
• Paiements AgentCore avec intégration du navigateur
• Anchor Browser sur AWS Marketplace

À propos des auteurs