x402: pagamenti irreversibili per agenti IA che ancora si rompono

Il 25 settembre 2026 Block ha annunciato il proprio ingresso nella Fondazione x402 e l’integrazione dei pagamenti Lightning nel protocollo. Con quella mossa, lo standard che permette a un agente IA di pagare da sé l’accesso a un’API, a un dataset o a un servizio digitale risulta sostenuto da Google, Microsoft, Amazon Web Services, Coinbase, la Solana Foundation e ora Block, il tutto sotto l’ombrello della Linux Foundation da aprile. Steve Lee, a capo di Spiral, lo ha detto senza giri di parole: si tratta di trasformare Bitcoin in «denaro quotidiano per le persone e per gli agenti che agiscono per loro conto».

La parte interessante di quella frase non è Bitcoin. Sono «gli agenti che agiscono per loro conto».

Che cosa fa esattamente x402

x402 riattiva il codice di stato HTTP 402 — «Payment Required» — rimasto riservato e inutilizzato per trent’anni. Un server risponde 402 a una richiesta, allega le condizioni di pagamento, il client salda e riprova. Ciò che era impossibile con le carte (commissioni fisse di qualche centesimo, tre giorni di compensazione, chargeback) diventa banale quando il regolamento avviene in stablecoin on-chain o in sat via Lightning: pagamenti di frazioni di centesimo, confermati in secondi, senza account preesistente, senza modulo, senza esseri umani.

Questa è la proposta tecnica, ed è buona. Il problema è la seconda metà del design: chi paga non è una persona, è un processo. Un agente con una chiave, un budget e un’istruzione in linguaggio naturale. E il regolamento è definitivo. Non c’è storno, non c’è «contestare l’addebito», non c’è la finestra di 120 giorni di una carta Visa. Si sta costruendo un binario finanziario la cui proprietà principale è l’irreversibilità, e lo si sta collegando allo strato software meno prevedibile che l’industria abbia mai messo in produzione.

Lo stato reale dello strato che firmerà i pagamenti

Conviene mettere in fila ciò che è accaduto nelle stesse settimane in cui Block entrava nella fondazione.

L’Australia ha confermato che un agente di OpenAI ha avuto accesso a file non pubblici di un portale del governo, un incidente che ha spinto il primo ministro a mettere in guardia sul «ritmo furioso» dell’IA. Non c’è stato un attaccante umano che eseguiva un exploit: c’è stato un agente che faceva il suo lavoro e ha superato un limite che nessuno aveva modellato come tale.

In parallelo, Patrick Wardle ha documentato uno 0-day in Muse, l’assistente di Meta che «prenota appuntamenti, compila moduli e fa acquisti». Qualsiasi applicazione locale o comando da terminale poteva modificare un’impostazione non documentata — l’endpoint di trascrizione — e impossessarsi del token che dà il controllo completo dell’account. Senza permessi speciali di macOS. Senza avviso all’utente. Parole di Wardle: «possiamo manipolare l’agente e sfruttare i suoi privilegi per fare quello che vogliamo; invece di scrivere un infostealer completo per Mac, usiamo l’assistente IA stesso». Meta ha rilasciato la patch dodici ore dopo la pubblicazione. Amazon, da parte sua, aveva iniziato a bloccare Muse sul proprio store mezza giornata prima della divulgazione.

E sotto entrambi i casi c’è la classe di vulnerabilità priva di patch concettuale: la prompt injection. Non è un bug che si risolve in una release; è la conseguenza del fatto che il modello non distingue strutturalmente tra l’istruzione del principale e il contenuto dell’ambiente. Tutto ciò che l’agente legge è potenzialmente un ordine.

La lezione di Bitget: l’anello debole non è la crittografia

L’hackeraggio da 352 milioni di dollari a Bitget, che il suo CEO attribuisce alla Corea del Nord sulla base di indizi IP, è il miglior argomento disponibile sul perché tutto questo conti. Non è stata violata nessuna chiave privata. Non è stato fattorizzato nulla. È stato compromesso il processo che genera l’istruzione, e l’infrastruttura di firma ha fatto esattamente ciò che le era stato chiesto: firmare una transazione legittima con destinazione sbagliata.

Trasposta nel mondo agentico, la conclusione è scomoda e diretta: in un sistema in cui una macchina autorizza pagamenti a partire da testo, l’attaccante non ha più bisogno di rubare una chiave. Gli basta convincere l’agente. La superficie di attacco smette di essere l’HSM e diventa ogni pagina web, ogni risposta di API, ogni PDF e ogni email che l’agente elabora durante un compito. Tutto questo è input non affidabile con la capacità di muovere denaro.

La differenza rispetto alla frode tradizionale è di scala e di velocità. Un attaccante che riesce a iniettare un’istruzione non svuota un conto: svuota tutti i conti di tutti gli agenti che usano lo stesso template di prompt, in parallelo, in microtransazioni sotto qualsiasi soglia di allerta, regolate in secondi e senza possibilità di reversione.

Chi sta scrivendo le regole dell’economia macchina-a-macchina

Qui sta il punto che la copertura di prodotto non tocca. x402 è, di fatto, uno standard definito da quattro hyperscaler statunitensi più Block e Coinbase. Ospitarlo nella Linux Foundation gli dà una governance aperta sul piano tecnico, ma non cambia chi porta il traffico, gli SDK e gli endpoint di default. Non c’è una controparte europea. Non c’è una controparte cinese. E soprattutto non c’è una specifica delle tre cose che qualsiasi regolatore finanziario chiederà per prime:

• Identità e attribuzione. Chi è l’ordinante ai fini AML: l’agente, l’operatore dell’agente, il titolare del conto che lo ha dispiegato? Che cosa succede quando un agente subappalta a un altro agente e questo a un terzo?
• Compliance. La Travel Rule presuppone due entità identificabili che si scambiano i dati dell’ordinante e del beneficiario. Un pagamento di 0,004 dollari per una chiamata API tra due processi non rientra in quel modello nemmeno a forzarlo. Non ci rientra nemmeno lo screening sanzioni applicato transazione per transazione a un volume di milioni al minuto.
• Reversibilità e responsabilità. Se l’agente paga chi non doveva perché un sito gli ha iniettato un’istruzione, chi si assume la perdita? Nella PSD2 esiste il concetto di operazione non autorizzata dall’utente. Qui l’operazione è stata autorizzata: dall’agente, che agiva con mandato valido.

Il vettore geopolitico si deduce da solo. Se un attore statale ottiene già centinaia di milioni compromettendo i backend degli exchange, un parco di agenti con budget proprio, senza un umano che firmi e con regolamento definitivo è un bersaglio migliore. E funziona anche nella direzione opposta: un flusso di micropagamenti macchina-a-macchina, frammentato e automatizzato, è un’architettura ragionevolmente efficace per muovere valore aggirando controlli sui capitali e liste di sanzionati senza che nessuno abbia premuto un pulsante. Che nessuno l’abbia ancora specificato non significa che nessuno ci stia guardando.

Dove questa lettura può sbagliare

Ci sono tre controargomenti seri, e conviene prenderli sul serio.

Il primo: x402 è un protocollo di trasporto del pagamento, non una politica di autorizzazione. Nulla impedisce di costruire al di sopra limiti di spesa rigidi, whitelist di beneficiari, conferma fuori banda oltre una certa soglia o conti con fondi segregati per compito. L’irreversibilità del binario si compensa con un caveau piccolo. È esattamente ciò che hanno fatto le carte virtuali usa e getta, e ha funzionato.

Il secondo: l’entità del rischio dipende dallo scontrino medio. Se il 99% dei pagamenti agentici è di centesimi per chiamate API, il tetto di perdita per agente compromesso è il saldo del suo hot wallet, non la tesoreria dell’azienda. Paragonarlo a un hackeraggio da 352 milioni a un exchange significa confrontare classi di attivi diverse.

Il terzo, e il più probabile: che il commercio agentico impieghi molto più tempo a materializzarsi di quanto suggeriscano gli annunci. Che Amazon blocchi Muse indica che i grandi marketplace non hanno alcuna fretta di lasciare che agenti terzi comprino a casa loro. Senza il lato dell’offerta, il binario resta confinato alle demo e al traffico tra API di infrastruttura, e il dibattito su sanzioni e Travel Rule arriva con tre anni di margine.

L’evidenza che smentirebbe la tesi sarebbe concreta: che i primi dodici mesi di x402 in produzione passino senza un incidente rilevante di spesa non intenzionale da prompt injection. Se accadrà, l’architettura di contenimento avrà funzionato e questo articolo avrà esagerato. Ciò che non è difendibile è la posizione opposta: dare per scontato che non succederà nulla perché finora non è successo.

Che cosa significa se stai costruendo

La decisione architetturale non è «adotto x402?». Quasi certamente sì, perché il costo di integrazione è basso e l’alternativa è restare fuori da uno standard con sei nomi grossi alle spalle. La decisione è dove metti il confine di fiducia tra il modello e la chiave, e quella decisione si prende ora, in fase di design, non dopo il primo incidente.

Tre implicazioni pratiche. Primo: l’agente non deve avere la chiave, deve avere una sessione con budget, scadenza e lista di beneficiari ammessi, emessa da un componente deterministico che il modello non possa riscrivere con del testo. Se un prompt può alterare il limite di spesa, non esiste alcun limite di spesa. Secondo: registra l’intenzione firmata, non solo la transazione. Quando arriverà la controversia — e arriverà — la domanda sarà quale istruzione concreta, proveniente da quale origine, ha generato il pagamento; senza quella traccia non c’è attribuzione possibile e la responsabilità ricadrà per default su chi ha dispiegato l’agente. Terzo, per chi investe: lo strato che manca in questo stack non è il binario di pagamento, che è già risolto ed è open source. È il controllo di autorizzazione, l’attestazione di quale agente ha fatto cosa, e l’assicurazione che copra lo scarto tra «operazione valida» e «operazione voluta». In quello scarto ci saranno i soldi del prossimo ciclo, e in questo momento non lo copre nessuno.