Passa al contenuto principale

Pagamenti degli agenti: x402, MPP e AgentCore GA

Avanzato

Per due anni gli agenti sono stati bravissimi a decidere di comprare qualcosa e pessimi nel pagarla davvero. Il workaround era sempre lo stesso: pre-provisionare una API key, dare all'agente una carta di credito condivisa e sperare che non accumuli un conto che non puoi annullare. Nel 2026 quel divario si è chiuso. È emerso un piccolo stack attorno a una grande idea, usare HTTP 402 nel modo in cui era sempre stato pensato, e un servizio AWS reale e generalmente disponibile ora lo avvolge nei guardrail di cui un'azienda vera ha bisogno. Questa pagina è una guida pratica a quello stack: come funziona x402 sul filo, perché lo schema upto è quello interessante, cosa ti dà davvero AgentCore Payments alla GA, e dove sono gli spigoli.

What you'll learn
  • Leggere una challenge x402 grezza e capire i tre header, le due chiamate al facilitator e i tre schemi di pagamento
  • Distinguere exact da upto e sapere quale dovrebbe pubblicizzare il tuo endpoint
  • Impostare il tetto di spesa e la scadenza di una payment session così che un agente non possa svuotare il tuo wallet su un prompt sbagliato
  • Scegliere tra Coinbase Privy (binari crypto) e Stripe Privy (binari carta) dentro AgentCore Payments
  • Riconoscere le tre minacce reali: prompt-injection-to-buy, comportamento scorretto del facilitator e over-settlement di 'upto'

Perché "l'agente paga e basta" è più difficile di quanto sembri​

Nel momento in cui un agente ha vera autorità di spesa, quattro cose si rompono insieme:

  • Il modello ad API key era un workaround. Ogni API "agent-friendly" di oggi ti chiede di creare una chiave, ricaricare un saldo e passare la stringa all'agente. È l'umano che fa la contabilità; l'agente è solo un client. Qualsiasi cosa l'agente compri consuma il pool pre-impegnato dall'umano.
  • Le carte sono state progettate per un compratore per sessione. Le carte presumono che ci sia una persona che clicca "Paga". Gli agenti vogliono fare fan-out, comprare 200 piccole cose su 30 siti in un'ora, e ogni acquisto dovrebbe essere atomico, economico e reversibile.
  • Non c'è discovery. Un compratore umano può leggere una pagina dei prezzi. Un agente ha bisogno di un "ecco quanto costa e come pagarlo" leggibile dalla macchina inline nella risposta.
  • I guardrail devono essere applicati da qualche parte che non sia l'agente. Se l'unico limite è un prompt che dice "spendi meno di 10 $", prima o poi l'agente lo disobbedirà. Il limite deve vivere in un'infrastruttura con cui il modello non può discutere.

x402 attacca il problema della discovery. AgentCore Payments attacca il problema dei guardrail. Sono complementari, non concorrenti.

x402 sul filo: l'intero protocollo in un solo flusso​

x402 è un protocollo aperto mantenuto dall'organizzazione x402-foundation/x402 su GitHub (Apache-2.0, ~6,5k stelle al momento della scrittura). Tutto il suo trucco è dare al codice di stato HTTP 402 Payment Required la semantica che tutti hanno sempre dato per scontata.

Il flusso completo è esattamente sei mosse. Nessuna sessione, nessun login, nessuna chiave.

Guided walkthrough1 of 6
  1. L'agente fa una normale richiesta HTTP a un endpoint a pagamento. Nessun header di auth, nessun wallet.

Due punti di design meritano una pausa. Primo, è il server, non il client, a decidere quando regolare. Se la richiesta fallisce dopo il passo 4, il server non chiama mai /settle, quindi l'agente non viene addebitato; la firma era un'autorizzazione con scadenza breve e semplicemente scade. È la proprietà che rende x402 utilizzabile per gli agenti: un download fallito è un download gratis. Secondo, il facilitator non ha mai la custodia dei fondi del client; l'invariante dichiarato del protocollo è "tutti gli schemi di pagamento non devono permettere ai facilitator di muovere fondi al di fuori delle intenzioni del client". Un facilitator malevolo può rifiutarsi di regolare; non può regolare in eccesso.

I tre schemi, e perché upto è quello interessante​

x402 definisce gli schemi come il modo in cui l'importo viene concordato, non la valuta usata. L'insieme stabile attuale:

  • exact: il server pubblicizza un prezzo fisso e il client firma esattamente per quell'importo. Ideale per contenuti con un costo noto per lettura: "0,02 $ per questo articolo". Semplice, noioso, corretto.
  • upto: il server pubblicizza un tetto. Il client firma autorizzando fino a quel tetto; il server sceglie l'addebito effettivo al momento del settlement, fino al limite. È quello che sblocca l'economia interessante.
  • batch-settlement (EVM): per usi ad alta frequenza. Il client deposita un escrow una volta, poi accumula molti voucher off-chain che vengono riscattati in un unico settlement on-chain aggregato. Stesso modello di fiducia, gas per richiesta drasticamente inferiore.

upto è lo schema che rende possibili il pay-per-inference e il pricing dinamico. Se vendi inferenza a token, al momento della richiesta non sai quanti token userà il completamento; lo sai solo al momento della risposta. Con exact o addebiti troppo (arrotondi al tetto e rimborsi: serve una seconda mossa on-chain) o troppo poco (il client paga 4k token e tu ne generi 10k). Con upto il client firma "addebitami al massimo l'equivalente di 10k token", tu produci la risposta, poi regoli per l'uso effettivo. Il rilascio GA di AWS AgentCore Payments evidenzia proprio questo come il pattern che il loro lancio abilita: "lo schema upto dentro x402 permette a un agente di fissare un tetto di spesa invece di impegnarsi su un prezzo fisso".

Attenzione alla modalità di fallimento: se il server regola il tetto invece dell'uso effettivo, il client non ha alcun ricorso on-chain per la differenza, la firma la copriva. Il parametro importo della chiamata /settle è fidato. In pratica è per questo che vuoi un facilitator che gestisci tu o di cui ti fidi; ne parliamo più sotto.

Le chain e gli SDK che incontrerai davvero​

L'attuale monorepo x402 pubblica package SDK per EVM, SVM (Solana), AVM, Aptos, Stellar, TVM, Hedera e Keeta, ma il traffico oggi è fortemente concentrato su Base (l'L2 EVM di Coinbase) e Solana, entrambi con settlement in USDC. In TypeScript i package che importerai davvero sono @x402/core, uno dei moduli di chain (@x402/evm, @x402/svm, …) e un wrapper client: @x402/fetch come sostituto drop-in di fetch() che gestisce in modo trasparente il ciclo 402→firma→retry, oppure @x402/express / x402-hono lato server. Python ha un singolo package pip x402; Go ha github.com/x402-foundation/x402/go/v2.

Cloudflare offre una strada ancora più corta: il sottomodulo agents/x402 dentro il suo package Agents ti dà un client MCP con x402 integrato, e x402-hono è il middleware paywall per un Worker. Quindi un Worker Cloudflare che trasforma una route in un endpoint a pagamento è più o meno:

Trasformare una route Hono in un paywall x402

import { Hono } from "hono";
import { paymentMiddleware } from "x402-hono";

const app = new Hono();

app.use("/premium/*", paymentMiddleware({
network: "base",
facilitator: "https://facilitator.x402.org",
routes: {
  "/premium/summary": {
    price: { asset: "USDC", amount: "0.05" },
    scheme: "exact",
    recipient: "0xYourMerchantAddress",
  },
  "/premium/inference": {
    price: { asset: "USDC", maxAmount: "0.50" },
    scheme: "upto",
    recipient: "0xYourMerchantAddress",
  },
},
}));

app.get("/premium/summary", c => c.text("The paid content."));
app.get("/premium/inference", c => c.text("The paid inference result."));
export default app;

Un chiamante che usa @x402/fetch non ha bisogno di sapere nulla di tutto questo: il wrapper vede il 402, firma, riprova e restituisce l'eventuale risposta 200 come farebbe un normale fetch.

AgentCore Payments GA: cosa ha davvero rilasciato AWS il 2026-08-18​

x402 da solo è un protocollo. Ti dà il come un agente paga. Non ti dà il se dovrebbe. Quello è il problema che Amazon Bedrock AgentCore Payments, in GA dal 18 agosto 2026 dopo una preview a maggio, risolve davvero.

La primitiva da capire è la payment session. Ogni pagamento che un agente fa deve girare dentro una di esse, e una sessione ha esattamente due tetti:

  • Un importo massimo di spesa in una valuta specificata.
  • Un orario di scadenza.

Entrambi vengono controllati deterministicamente a livello di infrastruttura: fuori dal modello, fuori dal framework agentico, fuori da qualsiasi cosa da cui il modello possa convincersi a uscire. Una richiesta che porterebbe la spesa cumulativa oltre il tetto viene rifiutata prima ancora che il payload di pagamento sia firmato. Una richiesta dopo la scadenza viene rifiutata allo stesso modo. Quello è il guardrail. Il modello non ha bisogno di essere ben allineato perché regga; ha bisogno di essere ben vincolato, e il vincolo vive nella sessione.

Attorno a quella primitiva AgentCore ha portato in GA:

  • Integrazione wallet Coinbase e Stripe Privy. Le credenziali vivono in AgentCore Identity Secrets Manager; l'agente non le vede mai; un token derivato di breve durata è ciò che autorizza davvero le operazioni sul wallet. Gli utenti finali possono ricaricare con carta (Stripe) o con USDC (Coinbase).
  • Quick Create per Coinbase. Provisioni le credenziali Coinbase dalla console o dalla CLI di AgentCore senza lasciare la piattaforma.
  • Il Machine Payment Protocol (MPP): l'astrazione di pagamento sopra x402 che permette a un agente di pagare servizi compatibili MPP e endpoint x402 con la stessa sessione e lo stesso tetto di sessione. MPP è dove i pagamenti su binari carta e su binari stablecoin si incontrano.
  • Una directory curata di server MCP abilitati x402, "Coinbase Bazar", esposta all'agente tramite AgentCore Gateway. La scopribilità degli endpoint a pagamento è classificata su "prova sociale, ricchezza dei metadati, qualità della descrizione e disponibilità", che è un modo educato di dire che stanno cercando di non diventare un elenco di drainer di shitcoin.
  • Plugin per i framework. Un plugin Strands Agents e un middleware LangGraph arrivano alla GA, così il contesto della payment session viene infilato nel tuo loop agentico senza che tu scriva a mano un client HTTP per x402.

Il cablaggio Strands è volutamente piccolo: costruisci un AgentCorePaymentsPluginConfig con l'ARN del payment manager, l'ID utente, l'ID dello strumento di pagamento e l'ID di sessione, e aggiungi il plugin all'agente. L'enforcement della sessione avviene sotto il plugin.

AgentCore Payments — plugin Strands, forma minima

from agentcore_payments import AgentCorePaymentsPlugin, AgentCorePaymentsPluginConfig
import os

plugin = AgentCorePaymentsPlugin(
  config=AgentCorePaymentsPluginConfig(
      payment_manager_arn=os.environ["PAYMENT_MANAGER_ARN"],
      user_id="test-user-123",
      payment_instrument_id=os.environ["PAYMENT_INSTRUMENT_ID"],
      payment_session_id=os.environ["PAYMENT_SESSION_ID"],
  )
)
# Attach plugin to your Strands agent; the payment session caps
# (max spend + expiry) are set when you mint the payment session,
# NOT in the plugin config.

Ogni tentativo di pagamento emette una voce di log CloudWatch e uno span di AgentCore Observability; le dashboard integrate mostrano tassi di successo, valore medio della transazione e salute end-to-end per agente. È il pezzo di osservabilità che rende "l'agente ha comprato qualcosa di strano" davvero debuggabile una settimana dopo.

Non solo crypto: dove entra Stripe​

Una lettura sbagliata comune è che x402 e AgentCore Payments siano "crypto per agenti". Non lo sono. x402 è semplicemente arrivato prima sulle stablecoin perché il settlement on-chain è l'unico binario con vero settlement per richiesta nativo per le macchine e senza permessi. Ma l'astrazione MPP di AgentCore e l'integrazione Stripe Privy fanno sì che la sessione di un agente possa essere finanziata da una carta. Ciò che Stripe Privy fornisce in questo contesto è un wallet appoggiato a una carta con delega: l'utente umano concede all'agente un'autorità di spesa limitata e revocabile contro una carta, e la sessione AgentCore applica il tetto di spesa sopra. Per le aziende che non vogliono affatto custodia di stablecoin, questa è la strada.

Come scegliere:

  • Coinbase / Privy (USDC su Base o Solana). Ideale quando ti serve vero settlement per richiesta sotto il centesimo; quando non vuoi chargeback; quando la controparte è un altro agente.
  • Stripe Privy (carta). Ideale quando il merchant è un'azienda normale senza binari on-chain, quando lo scontrino medio è abbastanza grande che le fee delle stablecoin non dominano, quando vuoi che il compratore abbia i diritti di contestazione del circuito carte.

Le tre minacce da prendere sul serio​

I pagamenti autonomi degli agenti aprono una superficie d'attacco piccola e specifica. Le tre contro cui progettare:

  • Prompt-injection-to-buy. Una pagina malevola nel contesto di un agente può istruirlo a comprare cose. La difesa non è "fai rifiutare il modello": è il tetto di sessione. Imposta il tetto di spesa più piccolo che completa il task legittimo, e la scadenza più breve. Se una prompt injection fa provare all'agente a spendere 10.000 $ e il tetto di sessione è 5 $, l'injection fallisce. È esattamente la stessa lezione di Iniezione crittografica di contesto: Grok: i confini di fiducia vivono fuori dal modello.
  • Comportamento scorretto del facilitator. La chiamata /verify è onesta per costruzione (un /verify malevolo può solo rifiutare), ma un facilitator compromesso o bizantino può rifiutarsi di fare /settle dopo che il server ha consegnato il contenuto, sovra-addebitare silenziosamente in modalità upto, o ritardare il settlement oltre la scadenza del payload così che la firma del client smetta di essere valida. Difesa: preferisci facilitator che gestisci tu per l'uso lato merchant; lato client usa il controllo di ricevuta integrato di @x402/fetch per fallire in modo rumoroso se PAYMENT-RESPONSE non coincide con ciò che hai firmato.
  • Over-settlement di upto. In upto, l'importo regolato è fornito dal server. Un server disonesto può regolare al tetto indipendentemente dall'uso effettivo. La mitigazione vive fuori dal protocollo: emetti una ricevuta d'uso firmata nel body della risposta (token generati, secondi in streaming, byte serviti) e rifiuta di fidarti di un importo regolato che non sia coerente con essa. Alcuni wrapper client rifiuteranno un settlement se fornisci una callback che restituisce il massimo atteso.

Queste sono anche la forma di ciò che WriteGuard di Cloudflare cerca di affrontare a livello MCP, trattando "costa denaro" come una scrittura con attribuzione e audit, ma il tetto di sessione di AgentCore è il controllo portante oggi. Combinare una policy di livello scrittura in stile WriteGuard a livello MCP e un tetto di payment session a livello wallet è la postura "cintura e bretelle" su cui la maggior parte dei deployment di produzione si assesterà.

Dove si colloca nel quadro più ampio degli agenti​

x402 dà a un agente un modo per transare. MCP gli dà un modo per raggiungere gli endpoint dove avvengono le transazioni. A2A gli dà un modo per delegare lavoro a un altro agente che a sua volta può essere pagato. In pratica vedrai tutti e tre composti: un hand-off A2A invoca un agente pari che usa MCP per raggiungere un tool prezzato in x402, e il chiamante paga tramite la sua sessione AgentCore. Quando si parla di "livello monetario per gli agenti" si intende questo: non un singolo prodotto, ma uno stack in cui discovery, capacità e settlement hanno ciascuno un protocollo e nessuno richiede umani nel loop.

Check yourself

0/6
  1. In uno scambio x402, cosa mette il server nell'header PAYMENT-REQUIRED?
  2. Perché lo schema `upto` è quello che abilita il pricing pay-per-inference?
  3. Quale invariante ti dà il protocollo x402 sul facilitator?
  4. In Amazon Bedrock AgentCore Payments, dove viene applicato il tetto di spesa di una sessione?
  5. Cosa porta l'header `PAYMENT-RESPONSE` in una risposta x402 200 riuscita?
  6. Vuoi proteggere un agente autonomo da un attacco prompt-injection-to-buy tramite una pagina web malevola nel suo contesto. Quale controllo fa davvero il lavoro?

Termini da memorizzare​

Nessuna carta — aggiungine qualcuna per iniziare a studiare. 🃏

Fonti e approfondimenti​

Prossimi passi​