AgentCore Payments: AWS gestiona el lado buyer de x402

El 18 de agosto de 2026 AWS puso AgentCore payments en disponibilidad general. La mitad buyer de x402 ya es un primitivo gestionado de cloud, y el cliente gestionado es mas estricto que el protocolo que implementa.

Casi todo el trabajo de pagos de agentes que auditamos en los ultimos meses vive del lado seller: como devolver un 402, como un facilitator verifica y liquida, como un scheme codifica el precio. El lado buyer seguia siendo codigo de libreria. Instalabas un SDK, le entregabas una clave privada y esperabas que tu limite de gasto fuera algo mas que una variable en un prompt.

Amazon Bedrock AgentCore payments mueve esa mitad al control plane de un hyperscaler. AWS anuncio el preview el 7 de mayo de 2026 en cuatro regiones: US East (N. Virginia), US West (Oregon), Europe (Frankfurt) y Asia Pacific (Sydney). El anuncio de GA lleva fecha 18 de agosto de 2026, y la matriz de regiones ya marca AgentCore payments como disponible en doce: N. Virginia, Ohio, Oregon, Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Singapore y Sydney.

Este post es una lectura de la documentacion, no un resumen de prensa. Que acepta el servicio de verdad, que rechaza, donde se desvia de las specs y cuanto cuesta una llamada.

Cinco recursos antes de un solo pago

El servicio no expone "una wallet". Expone un arbol de recursos repartido en dos superficies de API: bedrock-agentcore-control para configuracion y bedrock-agentcore para el data plane.

La pagina de funcionamiento los define con precision. Un PaymentCredentialProvider guarda los secretos del proveedor en AWS Secrets Manager a traves de AgentCore Identity. Un PaymentManager es el recurso de nivel superior y la frontera de autorizacion: toma un authorizer type AWS_IAM o CUSTOM_JWT mas un rol de IAM, y el servicio le provisiona una workload identity. Un PaymentConnector une ese manager a un proveedor: CoinbaseCDP o StripePrivy. Un PaymentInstrument es la wallet embebida del usuario final. Una PaymentSession es un presupuesto acotado en el tiempo.

Recien entonces un agente puede llamar a ProcessPayment.

# Data plane: contexto de presupuesto para una interaccion
session = manager.create_payment_session(
    user_id="test-user-123",
    limits={"maxSpendAmount": {"value": "5.00", "currency": "USD"}},
    expiry_time_in_minutes=60
)

Los estados del ciclo de vida importan porque filtran la arquitectura. Managers y connectors pasan por CREATING, READY, UPDATING, CREATE_FAILED, UPDATE_FAILED. Los connectors de Coinbase creados con Quick create suman cuatro mas: PENDING_AUTHENTICATION, PROVISIONING, AUTHENTICATION_EXPIRED y AUTHENTICATION_FAILED. Quick create es un consentimiento OAuth contra Coinbase que provisiona por ti la API key de CDP y el wallet secret; el authorizationUrl que devuelve esta documentado como valido unos diez minutos, tras los cuales el connector expira y hay que recrearlo. Stripe (Privy) solo admite provisioning manual: pegas App ID, App Secret, Authorization ID y una clave privada P-256 de autorizacion.

Los instruments llevan un enum de red. La pagina de creacion de instrument indica que ETHEREUM "cubre Ethereum mainnet y todas las redes Layer 2 compatibles con EVM soportadas (Base, Arbitrum y otras)", y que las cadenas compatibles con Solana usan el enum SOLANA. El estado del instrument es INITIATED, ACTIVE, FAILED o DELETED.

El flujo, header por header

El camino en runtime es el loop x402 que ya describimos, con el paso de firma reubicado en una API de AWS. La secuencia documentada: el agente llama a un endpoint pago; el merchant responde 402 Payment Required con un payload que nombra monto, destinatario, asset y red; AgentCore payments verifica el limite de la sesion; recupera las credenciales de wallet desde AgentCore Identity y firma; el agente reintenta con la prueba en el header X-PAYMENT; el merchant verifica y liquida on-chain; el servicio confirma la transaccion y actualiza el ledger de gasto de la sesion.

La ultima linea de esa secuencia es la que hay que subrayar: "si cualquier paso falla, la reserva del limite de pago se libera y la transaccion se registra como FAILED". El presupuesto se reserva y despues se confirma o se libera. Es un modelo contable en dos fases dentro del buyer, justo la disciplina que el protocolo por si solo no te da.

Llamarlo directo se ve asi, con el payload del merchant copiado literal en paymentInput.cryptoX402:

payment = dp_client.process_payment(
    userId="test-user-123",
    paymentManagerArn=PAYMENT_MANAGER_ARN,
    paymentSessionId=SESSION_ID,
    paymentInstrumentId=INSTRUMENT_ID,
    paymentType="CRYPTO_X402",
    paymentInput={
        "cryptoX402": {
            "version": "2",
            "payload": {
                "scheme": "exact",
                "network": "eip155:84532",
                "amount": "100000",
                "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
                "payTo": "0x99935f281d3ED1E804bF1413b76E0B03e1fed4F9",
                "maxTimeoutSeconds": 300,
                "extra": {"name": "USDC", "version": "2"},
            },
        }
    },
    clientToken=str(uuid.uuid4()),
)

La respuesta trae "status": "PROOF_GENERATED" y la prueba firmada en paymentOutput.cryptoX402.payload. Nada se liquida dentro de AWS. El servicio es un firmante con ledger; el settlement queda en el facilitator del merchant. Esa distincion importa cuando razonas sobre fallas: una respuesta PROOF_GENERATED no es una factura pagada, es una autorizacion firmada que el merchant todavia puede no llegar a difundir.

MPP viaja sobre la misma operacion con otro sobre. Pones paymentType en MPP, reenvias literal el header WWW-Authenticate: Payment del merchant en paymentInput.mpp.wwwAuthenticateHeaders, y la respuesta devuelve paymentCredential con la forma Payment <base64url-token> para adjuntar como header Authorization. La documentacion es tajante sobre no tocarlo: "no decodifiques ni modifiques paymentCredential. Incorpora el challenge original y el payload firmado, y el HMAC del merchant se liga a esos bytes exactos".

Dos protocolos, una API, distinguidos por un enum. Auditamos MPP cuando Stripe y Tempo lo lanzaron; verlo llegar como par de x402 dentro de una operacion del data plane de AWS es la senal mas clara hasta ahora de que se espera que el buyer hable ambos.

El presupuesto es infraestructura, no un prompt

La decision de diseno mas util aca es que el tope de gasto no vive en el agente. Es un objeto del lado del servidor con dos campos — maxSpendAmount (valor mas moneda) y una expiracion — verificado antes de que se le pida firmar a la wallet. La pagina principal de payments lo dice sin rodeos: "cuando la sesion expira o se alcanza el presupuesto, las siguientes solicitudes de pago se deniegan. Si la firma de un pago falla despues de descontar el presupuesto, el presupuesto no descuenta el pago fallido".

La pagina de troubleshooting afina el orden. Para ambos protocolos, la validacion ocurre "antes de retener presupuesto o firmar", y las entradas malformadas o expiradas devuelven una ValidationException que "no consume presupuesto". El challenge MPP expirado esta explicito: no consume presupuesto, pide un challenge fresco y reintenta.

Compara eso con lo que dan los SDKs abiertos. Cuando medimos los spend controls de x402 en los tres SDKs oficiales, el tope era un chequeo del lado cliente del que se podia convencer al proceso del agente. Aca el chequeo vive detras de IAM, sobre un recurso que el agente no puede mutar, con una reserva que se libera al fallar. Ese es el lugar correcto. Es tambien la misma garantia que dan las spend permissions onchain en la capa de wallet, movida a la capa de API, con el intercambio de que ahora confias en un servicio de AWS en vez de en un contrato.

Donde el cliente gestionado recorta la spec

Este es el hallazgo central de la auditoria. AgentCore payments no implementa x402: implementa un subconjunto, y el subconjunto se aplica con errores con nombre propio.

Solo USDC canonico. La tabla de validacion incluye Payment asset is not a supported USDC token address for network '{network}', con la resolucion "usa un endpoint de merchant que pida USDC canonico". x402 es agnostico al asset: el scheme lleva una direccion de token arbitraria. El buyer gestionado rechaza cualquier cosa que no sea el USDC canonico de la red. Toda lista de precios en otro token es invisible para un agente de AgentCore. Del lado MPP es identico: "MPP EVM/Tempo charge solo soporta el token USDC canonico en la red".

Dos schemes. Payment scheme not supported. Supported scheme: {scheme}, con exact y upto como conjunto aceptado. Los schemes batch-settlement y auth-capture que auditamos este ano no son direccionables hoy desde este cliente.

upto trae un costo on-chain que hay que planificar. La pagina de process-payment documenta que upto liquida a traves de Permit2 y por lo tanto necesita un allowance ERC-20. Lo otorgas pasando permit2AllowanceLimit en la denominacion mas chica del asset (1000000 es 1 USDC a seis decimales, o el maximo uint256 para allowance ilimitado). Cuando lo pones, "AgentCore payments envia una transaccion approve on-chain antes de firmar. Esa transaccion incurre en fees de red (gas) pagados del balance de token nativo de la wallet". Y como approve fija en vez de sumar, la documentacion te dice que envies el campo solo en el primer pago upto de esa wallet. Usarlo con exact es una ValidationException. Ademas esta acotado por version y por cadena: upto exige x402 version 2 y solo redes EVM. Nuestro deep dive del scheme upto senalaba la aprobacion de Permit2 como el prerequisito escondido del scheme; aca aparece como campo de request con nota al pie de gas.

MPP esta cercado de cuatro formas. Solo el intent charge. Solo modo pull. Exactamente un challenge por llamada a ProcessPayment. Y metodos limitados a evm, tempo y solana, con una matriz por proveedor: Solana funciona en Stripe (Privy) y esta explicitamente rechazado para instruments gestionados por Coinbase. Hay ademas una compuerta a nivel de cuenta: Access to MPP (Machine Payments Protocol) payment processing is not enabled for this account. Contact AWS Support for access. MPP salio en GA, pero no para todos por defecto.

El consentimiento de gas es un flag explicito. En MPP, el challenge anuncia quien paga los fees de red mediante methodDetails.feePayer. Si el seller no los patrocina, el servicio se niega a firmar salvo que pases buyerPaysGasFees=true, porque "ese costo no es visible en el monto del challenge". El metodo evm no necesita consentimiento porque el facilitator difunde y paga el gas; solana solo admite fees patrocinados por el servidor. Es una pieza chica y genuinamente buena de diseno: un costo invisible convertido en un parametro afirmativo obligatorio.

La delegacion es un permiso que el usuario puede revocar

Un instrument nace vacio e inerte. La documentacion afirma que un payment instrument "comienza con 0 USDC" y que "el agente no tiene permisos para transaccionar mediante el instrument salvo que el cliente se los otorgue explicitamente". El usuario final abre paymentInstrumentDetails.redirectUrl, aterriza en el wallet hub del proveedor, recarga por transferencia cripto o tarjeta, Apple Pay, Google Pay o ACH, y le concede al agente permiso de firma. Solo entonces el instrument pasa a ACTIVE.

Dos modos de falla tienen su propio string de error, lo que dice bastante sobre su frecuencia: Delegated signing grant is not active for the end user wallet (el usuario nunca otorgo, o revoco) y Delegated signing is not enabled for your Coinbase project (el toggle de politica del proyecto CDP esta apagado). La revocacion es una accion de primera clase en el mismo wallet hub. La autoridad de gasto del agente es una delegacion, en manos del usuario, revocable sin tocar AWS: la misma forma que los rails de delegacion que venimos siguiendo on-chain.

La economia: pagas por operacion de wallet

La pagina de precios de AgentCore dice que no hay cargos adicionales de AWS por las invocaciones de la API de payments mas alla de las tarifas por operacion de wallet del proveedor elegido. El mapeo es uno a uno: en Coinbase CDP, un CreatePaymentInstrument es una operacion de wallet y un ProcessPayment es una operacion de wallet; en Stripe Privy, crear el instrument no tiene cargo y cada ProcessPayment es una operacion de wallet. El ejemplo trabajado de la pagina valua la operacion de wallet de Coinbase CDP en 0,005 dolares.

Sosten ese numero contra el encuadre del propio servicio. La pagina de payments describe las transacciones objetivo como "a menudo por debajo de 1 dolar o fracciones de centavo". Medio centavo de fee por firma es invisible en una llamada de 1 dolar, es la mitad del valor de una llamada de un centavo y domina cualquier cosa por debajo. El pricing medido tampoco lo arregla: upto reduce la cantidad de firmas solo si el seller te deja liquidar el uso de toda una sesion en una sola autorizacion.

La consecuencia practica es que el pago por request en tamanos de nanopago sigue pidiendo batching o una sesion en escrow, no una firma por llamada. Es la misma conclusion a la que llegamos auditando el settlement por lotes, y sobrevive a la mudanza a un buyer gestionado. Hay un costo mas que no es una tarifa: usar Coinbase exige una suscripcion activa en AWS Marketplace al listing "Coinbase Wallets for AgentCore Payments", y su ausencia devuelve SubscriptionRequiredException con HTTP 403 tanto al crear el connector como al momento de pagar.

El discovery viene incluido

La pieza que convierte esto en algo mas que un SDK es la distribucion. AgentCore Gateway trae un target de Coinbase x402 Bazaar — server URL https://api.cdp.coinbase.com/platform/v2/x402/discovery/mcp, outbound auth "No Authorization" — descrito como exponiendo "mas de 10.000 herramientas MCP pagas existentes que soportan microtransacciones x402". Agregas el target, enchufas el plugin de payments y un agente puede buscar endpoints pagos y pagarlos sin una linea de codigo de pagos.

Las integraciones de cliente siguen la misma logica: un plugin para Strands Agents, middleware para LangGraph y un camino agentcore invoke --auto-session donde el interceptor x402 del agente desplegado captura el 402, llama a ProcessPayment y reintenta. AWS tambien publica un ejemplo del lado seller donde CloudFront mas Lambda@Edge aplican el 402 sobre contenido en S3 en Base Sepolia: el mismo patron de enforcement en el edge que analizamos cuando x402 entro en los CDNs.

Que significa para LLM4Agents

LLM4Agents es un seller. Devolvemos 402, cobramos inferencia por llamada y liquidamos en stablecoins sobre un gateway compatible con OpenAI. AgentCore payments es la contraparte: una poblacion grande y bien distribuida de buyers que habla nuestro protocolo sin que escribamos su cliente. Eso es ganancia neta, con tres implicancias concretas.

Primero, la pregunta del asset queda resuelta para este segmento. Si un agente de AgentCore no puede pagar en otra cosa que USDC canonico en la red de su instrument, entonces cualquier precio que cotizemos en otro token es impagable para ese buyer. Nuestras cotizaciones deben nombrar la direccion de USDC canonico de cada cadena soportada, y nuestras ofertas EVM tienen que ser alcanzables desde un instrument de clase ETHEREUM.

Segundo, el soporte de schemes ya es una decision de acceso al mercado, no una preferencia. Los sellers que solo anuncian exact son totalmente direccionables. Los que quieren inferencia medida deben anunciar upto con un extra.facilitatorAddress correcto y un techo en maxAmountRequired: el cliente gestionado valida la presencia de ese campo y rechaza el payload sin el. Para pay-per-inference, que es exactamente nuestra forma de facturacion, upto es el scheme que hace que estos agentes nos paguen.

Tercero, el buyer ahora tiene presupuesto real y trazabilidad real. Las sesiones deniegan las solicitudes por encima del tope antes de firmar, y cada llamada del data plane emite logs y spans. Los sellers que se portan mal en el two-phase gap — cobrar por trabajo que falla despues de la autorizacion — quedan visibles en el dashboard de CloudWatch de otro. Eso sube el valor de las garantias sobre las que escribimos en nuestra auditoria del two-phase gap: liquidar contra entrega, reembolsar limpio y hacer barato el camino de falla para el pagador.

La amenaza no es competitiva, es gravitacional. Un buyer gestionado empaquetado con discovery, identidad, observabilidad y una suscripcion de marketplace arrastra el camino de integracion por defecto hacia adentro de una sola cloud. Si la unica via sin friccion para llegar a la demanda agentica es estar listado donde apunta el target de discovery de esa cloud, el cuello de botella pasa a ser la capa de discovery, no el protocolo.

Como mantenerse en la frontera

Cuatro movimientos, en orden.

1. Ser pagable por el cliente mas estricto. Auditar cada 402 que emitimos contra la tabla de validacion de AgentCore: direccion de USDC canonico por red, un amount positivo, un payTo valido, un maxTimeoutSeconds dentro de rango y extra.name mas extra.version en EVM. Todo payload que falle esos chequeos es un pago que silenciosamente no recibimos. El cliente mas estricto conocido es el test de conformidad mas barato que vamos a conseguir.

2. Shipear upto en nuestros endpoints medidos. Anunciar el techo en maxAmountRequired, publicar la direccion del facilitator en extra.facilitatorAddress y documentar para los buyers que el primer pago desde una wallet necesita un allowance de Permit2 con su costo de gas. Pay-per-inference es nuestra historia central de facturacion; upto es como la expresa un buyer gestionado. Los detalles estan en nuestro deep dive del scheme upto.

3. Estar listados donde miran los buyers. El endpoint de discovery de Bazaar viene cableado en AgentCore Gateway por defecto y no requiere outbound auth. Estar presente en el discovery de x402 es ahora un canal de distribucion con un hyperscaler del otro lado. Bazaar indexa en el settle en vez de con un paso de registro, asi que la tarea operativa es confirmar que nuestros endpoints aparecen y que su metadata anunciada coincide con lo que cobramos.

4. Hablar MPP ademas de x402. El buyer gestionado elige protocolo con un enum, y el formato del challenge es la unica diferencia en el borde del seller: un header WWW-Authenticate: Payment en vez de un payload x402, y un header Authorization en vez de X-PAYMENT. Agregar un camino de challenge MPP junto a nuestro 402 es un trabajo acotado que duplica el conjunto de buyers gestionados que podemos aceptar, y cubre el escenario en que sea el cliente de la cloud, y no la fundacion del protocolo, quien decida que rail gana.

El lado buyer dejo de ser una libreria este trimestre. Los sellers que cobren el ano que viene son los que tengan un 402 que sobrevive al contacto con la tabla de validacion de otro.