Annuncio di prodotto pubblicato sul blog di **Cloudflare** il **4 agosto 2026** da **Will Papper**, nell'ambito di **Agents Week**: **Cloudflare Wallets**, presentato come *"il wallet programmabile per l'Internet agentico"*. **Il problema enunciato** è preciso e ben scelto: un agente che vuole provare un'API deve passare da una pagina di login **pensata per gli umani**, farsi aggiungere un metodo di pagamento da un umano, generare una chiave API, per poi capire come chiamare il servizio. Due lacune strutturali lo spiegano — *"Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs"* — con la conseguenza che *"AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans"*. **L'architettura proposta si riduce a due tipi di wallet**: gli **Account Wallets**, destinati agli umani titolari di un account Cloudflare (finanziare, delegare, prelevare), e i **Virtual Wallets**, destinati agli agenti, **funzionanti tramite API key** e il cui limite di spesa è **fissato dal titolare dell'account**. Le protezioni annunciate sono esplicite: **allocazione, allow list, importo massimo per transazione**. **Il canale di pagamento è il protocollo x402** (pagamenti collegati alle richieste HTTP) e la valuta è la **stablecoin** — il che colloca l'offerta in un campo distinto dagli schemi costruiti sui circuiti delle carte. **L'argomento più interessante è controintuitivo e centrale**: *"These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000."* → **il limite non è ciò che vincola l'autonomia, è ciò che la rende accettabile.** **Secondo componente, più strategico del primo**: l'identità, tramite un namespace **`cloudflare.pay`** — un agente di ricerca potrebbe vivere a `research.example.cloudflare.pay`, dando al merchant la certezza di parlare con l'agente di un'organizzazione identificata. Cloudflare rivendica un'ambizione deliberatamente minimale (*"a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS"*), costruita sui suoi mattoni esistenti (**Turnstile**, Bot Management, **Web Bot Auth** e le sue keypair), e dichiara l'intenzione di adottare gli schemi della **x402 Foundation** man mano che emergono. **Un'avvertenza decisiva sullo statuto del testo**: **quasi tutto è al futuro**. Ciò che esiste il giorno dell'annuncio è la **riserva di un handle**; pagamenti, Virtual Wallets, protezioni e le rampe per accedere ai fondi sono annunciati (*"Soon, you will be able to…"*). Si tratta di una **presa di posizione su un namespace**, più che di un servizio che entra in funzione.
**Will Papper** — auteur de l'annonce sur le blog Cloudflare (lecture annoncée : 8 minutes). Publication rattachée à l'**Agents Week** de Cloudflare et étiquetée *Agents Week · AI · AI Bots · Developer Platform · Developers · Payments · Product News · x402*.
Annuncio di prodotto pubblicato sul blog **Stripe** il **29 aprile 2026** da **Dan Hill** (Product Manager, Link Consumer Product), a seguito del keynote **Stripe Sessions 2026**: il lancio del **wallet per agenti di Link**, costruito su un nuovo building block, **Issuing for agents**. **La diagnosi sta in una frase, ed è la più importante del testo**: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* → **Stripe riconosce che i protocolli di pagamento nativi per macchine non sono ancora pronti, e fornisce un ripiego sui binari esistenti piuttosto che una scommessa su quelli nuovi.** **Il meccanismo**: un consumatore concede a un agente l'accesso al proprio wallet Link tramite un **flusso OAuth standard**; l'agente emette quindi una *spend request* e riceve o una **carta monouso**, o uno **Shared Payment Token** — appoggiato sulle carte e sui conti bancari già presenti nel wallet. Punto cardine: *"The agent never gets access to your raw payment credentials."* La credenziale è **delimitata** (importo, valuta, esercente) e l'agente deve fornire il **contesto della transazione** affinché l'essere umano capisca cosa sta approvando — l'esempio riportato nella CLI è esplicito: `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **Il vincolo strutturante è temporale, ed è assunto come tale**: *"Today, each request requires the person's review before the credential is shared with your agent"* — approvazione **umana**, **transazione per transazione**, sul web o nelle **nuove app Link iOS e Android**. I limiti di spesa e i casi in cui l'agente agirebbe **senza approvazione aggiuntiva** sono annunciati, non consegnati. **Il secondo livello è il vero prodotto infrastrutturale**: **Issuing for agents** apre l'intero set di API di Issuing a chiunque costruisca il proprio wallet agentico — carte virtuali monouso, deposito di fondi, controlli di spesa, permessi a livello di carta, controlli antifrode **al momento dell'autorizzazione**, visibilità in tempo reale. Sono citati quattro casi d'uso: automazione della spesa interna, carte agentiche integrate presso **fintech**, piattaforme **SaaS verticali** che emettono carte alle PMI a proprio marchio, **marketplace** i cui agenti venditori pagano fornitori e logistica. **Argomento di distribuzione**: Link rivendica **oltre 200 milioni di consumatori**, e l'articolo cita **OpenClaw** come esempio di agente personale che ne beneficia. **Due riserve da segnalare fin da subito**: l'approvazione per transazione è presentata come una comodità di design mentre è in realtà **un'ammissione che l'autorizzazione delegata degli agenti non è risolta**; e stablecoin, *agentic tokens*, e "altri metodi di pagamento" sono tutti al **futuro** (*"coming soon"*).
#Stripe#Link#wallet per agenti
**Dan Hill** — Product Manager · **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe · rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public** · pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.