L'UCP di Google mette quattro header su ogni pagamento. Tre servono alla discussione che verrà dopo

L'11 gennaio 2026 Google ha pubblicato il Universal Commerce Protocol: uno standard open source che permette agli agenti IA di acquistare, sviluppato insieme a Shopify e sostenuto da più di 20 partner, tra cui Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa e Zalando.

La copertura che ne è seguita parlava di shopping. Agenti che curiosano per te, agenti che pagano per te, la fine del carrello e così via.

Poi si legge la specifica, e lo shopping si rivela la cosa meno interessante che vi si trova. Ciò che l'UCP standardizza con una cura inconsueta non è l'acquisto. È la prova che l'acquisto è avvenuto come entrambe le parti sostengono.

In breve:

• Ogni richiesta UCP che modifica uno stato porta quattro header, e tre di essi — request-signature, idempotency-key, request-id — non fanno nulla per la transazione in sé. Esistono perché dopo qualcuno possa dimostrare che cosa è stato chiesto, che è stato chiesto una volta sola e dove ritrovarlo.
• Il non ripudio è una funzione con un nome. Nell'estensione opzionale dei mandati AP2 (dev.ucp.shopping.ap2_mandate) l'esercente firma crittograficamente le condizioni del pagamento, mentre la piattaforma fornisce mandati crittografici che provano l'autorizzazione dell'utente. Lo scopo dichiarato dalla specifica: «ridurre in modo significativo i rischi di manomissione e di contestazione».
• Il numero dei sostenitori non è il numero delle integrazioni. «Oltre 20 partner globali» è la formula pubblicata da Google e descrive un sostegno. Al momento in cui scriviamo non abbiamo trovato alcuna fonte primaria che indichi quanti esercenti siano in produzione su UCP.

Il set di header proviene dal tutorial pubblicato da Google il giorno del lancio. Fonti in fondo.

Che cos'è l'UCP, nel minor numero di parole che restano vere

Prima dell'argomento, i fatti verificabili. Provengono dalla specifica pubblicata su ucp.dev e dal blog per sviluppatori di Google, entrambi consultati il 5 settembre 2026.

Due righe di questa tabella meritano una pausa, perché la maggior parte degli articoli le salta entrambe.

La prima è quella dei trasporti. L'UCP non è una cosa MCP né una cosa REST. Gli stessi dati dichiarati vengono offerti su REST, MCP, A2A e un binding embedded, e a scegliere è l'esercente. È un rifiuto deliberato di scommettere su quale idraulica per agenti finirà per vincere.

La seconda è il versionamento per data. 2026-04-08 non è una versione semantica, è un giorno. La ragione dichiarata è l'ordinamento cronologico e il confronto senza ambiguità, ma l'effetto pratico è un altro: ogni sessione negoziata registra la data delle regole sotto cui si è svolta. È una decisione di archiviazione travestita da decisione di versionamento, e detta il tono di tutto il resto del documento.

Il collo di bottiglia che vuole eliminare

L'inquadramento di Google è un problema N×N. Ogni azienda che voglia comparire dentro una superficie conversazionale deve costruire una connessione su misura per ciascuna; ogni superficie deve fare l'onboarding di ogni azienda separatamente; alla fine non esce nulla.

L'articolo di ingegneria di Shopify, pubblicato lo stesso giorno dal distinguished engineer Ilya Grigorik, affronta lo stesso problema dal basso. Dopo oltre 20 anni, miliardi di transazioni e milioni di merchant, la lezione è che il commercio rifiuta di normalizzarsi: «le opzioni e le regole di pagamento variano in base alle proprietà del carrello, dell'acquirente e del mercato; gli sconti hanno regole di cumulo e combinazione che rivaleggiano con il codice tributario; le opzioni di evasione esplodono in permutazioni fuori controllo». E poi arriva la frase da tenere: «Questa complessità non è un bug, è una proprietà emergente della diversità dei retailer.»

Quella sola riga spiega l'intera architettura. Se accetti che i merchant siano irriducibilmente diversi, non puoi standardizzare il comportamento. Puoi standardizzare solo il modo in cui un merchant dichiara il proprio comportamento e il modo in cui un agente scopre a che cosa ha appena acconsentito.

La struttura che un'azienda pubblica su /.well-known/ucp. Fonte: specifica UCP 2026-04-08, Overview.

La discovery avviene prima che inizi la conversazione

Ecco il flusso, così come lo descrivono la specifica e il tutorial di Google. Vale la pena seguirlo alla lettera, perché l'ordine è l'argomento.

1. L'azienda pubblica un profilo su /.well-known/ucp. Vi dichiara una versione di protocollo, uno o più servizi (dev.ucp.shopping), le capability contenute, i trasporti e gli endpoint, i payment handler disponibili e — conterà più avanti — le proprie signing_keys pubbliche.
2. L'agente annuncia il proprio profilo a ogni richiesta, tramite un header UCP-Agent in sintassi dictionary RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Sul trasporto MCP la stessa informazione viaggia in un oggetto meta.
3. L'azienda calcola l'intersezione. Delle proprie capability tiene quelle che anche la piattaforma dichiara; per ciascuna sopravvissuta sceglie la versione più alta presente in entrambi gli array; se non esiste una versione comune, la capability sparisce del tutto.
4. Le estensioni orfane vengono potate. Un'estensione che dichiara extends: "dev.ucp.shopping.checkout" scompare se checkout non è sopravvissuta. La potatura si ripete finché non cade più nulla, il che gestisce le catene transitive.
5. Sceglie l'azienda. L'UCP usa un'architettura in cui seleziona il server: è il merchant, non l'agente, a decidere che cosa è attivo per la sessione, e restituisce il registro delle capability attive nella risposta.

La denominazione non è convenzione ma governance. Ogni capability si scrive {dominio-invertito}.{servizio}.{capability}: dev.ucp.shopping.checkout per quella standard, com.example.payments.installments per quella di un merchant. Un retailer può inventare una capability che nessun altro ha senza chiedere permesso e senza collidere con nessuno, perché il dominio invertito è l'autorità.

Anche il fallimento ha una sua tassonomia, e la distinzione è istruttiva. La specifica separa i fallimenti di discovery (errori di trasporto: invalid_profile_url restituisce 400, profile_unreachable restituisce 424, profile_malformed restituisce 422) dai fallimenti di negoziazione, che sono esiti di business e tornano come un normale 200 con capabilities_incompatible nel corpo. «Non sono riuscito a raggiungerti» e «non abbiamo nulla in comune» sono eventi diversi, e l'UCP si rifiuta di fonderli in un unico 400.

Quattro header viaggiano su ogni richiesta che modifica stato

Guardiamo una chiamata vera. È l'esempio pubblicato da Google il giorno del lancio: creare una sessione di checkout presso un fioraio di esempio.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Quattro header. Chiediti a che cosa serve ciascuno e un pattern emerge.

Tre dei quattro non sono al servizio della transazione. Sono al servizio del disaccordo sulla transazione.

Non è un caso di buona igiene delle API. Chiavi di idempotenza e request ID sono normali buone pratiche nei pagamenti, certo, ma la specifica va parecchio oltre, e più va oltre, più l'intenzione diventa chiara.

Il non ripudio è un obiettivo di progetto, non un ripensamento di compliance

L'UCP elenca quattro meccanismi di autenticazione che un'azienda può accettare: chiavi API, OAuth 2.0, mTLS e firme dei messaggi HTTP secondo RFC 9421. Tre sono ordinari. Il quarto fa qualcosa di preciso.

Con le firme dei messaggi, entrambe le parti pubblicano le proprie chiavi pubbliche nell'array signing_keys dello stesso identico documento di profilo che dichiara le loro capability. Il verificatore estrae il keyid dall'header Signature-Input, lo abbina a un kid nell'insieme di chiavi pubblicato dal firmatario e verifica la firma. Nessun segreto condiviso, nessuna registrazione, nessun account. La specifica chiama questo risultato onboarding senza permessi: «qualsiasi piattaforma dotata di un profilo individuabile può interagire con qualsiasi azienda senza registrazione preventiva».

La falla ovvia viene chiusa dal binding di identità. Qualunque sia il meccanismo, i verificatori devono confermare che il principal autenticato sia effettivamente autorizzato ad agire per il profilo indicato in UCP-Agent, e rifiutare la richiesta quando i due sono in conflitto. Non puoi autenticarti come te stesso e poi sostenere di essere l'agente di qualcun altro.

E i webhook che vanno dall'azienda alla piattaforma devono essere firmati. Non «dovrebbero»: devono. Gli aggiornamenti del ciclo di vita dell'ordine — spedizione, consegna, resi — sono l'unico punto del protocollo in cui il requisito è assoluto, perché sono i messaggi che arrivano dopo che il denaro si è mosso e che nessuno sta guardando in tempo reale.

Fonte: specifica UCP 2026-04-08, sezioni Identity & Authentication e Transaction Integrity.

E poi c'è la cima della scala. Per agenti autonomi e transazioni di alto valore, l'UCP definisce un'estensione opzionale, dev.ucp.shopping.ap2_mandate. Quando entrambe le parti la negoziano:

• l'azienda fornisce una firma crittografica sulle condizioni del checkout, e
• la piattaforma fornisce mandati crittografici che provano l'autorizzazione dell'utente.

L'agente firma gli oggetti di mandato con la chiave privata dell'utente su una superficie non agentica: cioè la persona autorizza da uno schermo che controlla, non dentro il loop dell'agente che sta per spendere i suoi soldi. La dichiarazione di scopo della specifica merita la citazione letterale, perché non è una frase di sicurezza di rito: il meccanismo «fornisce solide garanzie crittografiche end-to-end sui dettagli della transazione e sul consenso dei partecipanti, riducendo in modo significativo i rischi di manomissione e contestazione».

Ed ecco il punto. Un protocollo progettato solo per far comprare gli agenti non avrebbe bisogno di nulla di tutto questo. Condizioni firmate dal lato esercente e mandati firmati dal lato utente non sono funzioni del comprare. Sono funzioni del litigare sull'acquisto, sei settimane dopo, davanti a qualcuno che deve decidere chi aveva ragione.

Dove la narrazione supera le prove

Ci sono tre cose che si ripetono sull'UCP e che le fonti primarie non sostengono così come vengono dette.

«Oltre 20 partner» è un conteggio di sostegni. La formulazione di Google è che l'UCP è stato «co-sviluppato e sostenuto da più di 20 partner». Un sostegno è una dichiarazione pubblica di appoggio. Non è un'integrazione rilasciata, e tanto meno un esercente in produzione. Abbiamo cercato una fonte primaria con il numero di esercenti che transano su UCP e non l'abbiamo trovata.

«Standard aperto» e «standard di Google» sono entrambi veri, e la tensione è reale. La specifica è open source, il repository GitHub accetta pull request e la convenzione di denominazione lascia deliberatamente a chiunque la possibilità di rivendicare il proprio namespace. Al tempo stesso, la prima implementazione di riferimento l'ha costruita Google, e per partecipare a quella un'azienda ha bisogno di un account Google Merchant Center attivo con prodotti idonei al checkout. Protocollo neutrale, primo palcoscenico con il cancello.

L'UCP non elimina l'esercente. Viene travisato abbastanza spesso da meritare una frase netta: sotto UCP l'azienda conserva la propria logica di business e resta Merchant of Record. L'Embedded Checkout Protocol di Shopify prende lo stesso impegno dalla direzione opposta: quando un flusso richiede una persona, l'agente carica una continue_url e il checkout reale dell'esercente viene renderizzato dentro la superficie dell'agente su un canale JSON-RPC 2.0, con l'esercente che chiude la transazione. L'agente è una superficie, non un sostituto.

Quattro cose che non abbiamo potuto verificare, segnalate come tali

La specifica pubblicata su ucp.dev al momento della consultazione è la versione 2026-04-08, e il suo elenco di capability standard — Cart, Checkout, Identity Linking, Order — differisce dal tutorial dell'11 gennaio, i cui esempi girano sulla versione 2026-01-11 e mostrano checkout, discount e fulfillment. Fra quelle due date è stato aggiunto qualcosa. Non abbiamo trovato un changelog primario che indichi quando, né una release note datata per le versioni intermedie, quindi riportiamo la differenza e non un evento di rilascio.

Non abbiamo trovato alcun conteggio pubblicato di esercenti in produzione su UCP, né da Google, né da Shopify, né da alcun partner sostenitore. L'assenza di un numero non prova che il numero sia piccolo, ma è la ragione per cui non ne stampiamo nessuno.

Google dichiara di aver costruito la prima implementazione di riferimento che alimenta gli acquisti dentro l'AI Mode della Ricerca e l'app Gemini. Non abbiamo verificato in modo indipendente disponibilità, geografia e scala di quel rilascio.

Se l'UCP diventerà lo standard del commercio agentico è, mentre scriviamo, impossibile da sapere, e qualsiasi articolo che dica il contrario sta tirando a indovinare. La lettura onesta è più stretta: una specifica esiste, è pubblica, è insolitamente scrupolosa sul tema della prova, e diverse aziende molto grandi hanno firmato l'annuncio.

La metà non firmata

Facciamo un passo indietro rispetto al commercio, perché la parte interessante si generalizza.

L'UCP descrive un mondo in cui una macchina agisce per tuo conto e ogni passo di quell'azione lascia qualcosa: chi ha chiesto, firmato; quali condizioni, firmate; quante volte, con chiave; in quale ordine, correlato. Sei settimane dopo, quando l'addebito viene contestato, c'è un artefatto. Nessuno deve ricordare.

Ora pensa da dove arriva davvero l'autorità di quelle azioni. Un agente compra 400 unità perché è stata presa una decisione di acquisto. Un contratto si rinnova perché qualcuno ha accettato una clausola. Un perimetro cambia perché due persone ne hanno parlato un giovedì e una delle due ha detto di sì.

Quelle conversazioni sono la metà non firmata dello stesso flusso di lavoro. La metà-macchina viene costruita con ricevute crittografiche e con una specifica che tratta le contestazioni come scenario di prima classe. La metà umana, nella maggior parte delle organizzazioni, è la memoria di qualcuno, la memoria diversa di qualcun altro e un riassunto scritto a partire da entrambe.

L'asimmetria peggiorerà prima di migliorare, perché la metà-macchina migliora al ritmo di una specifica e la metà umana non migliora affatto. E la modalità di guasto è precisa: non è che le persone mentano. È che un artefatto derivato — un riassunto, un verbale, un elenco di azioni — viene trattato come il documento nel momento stesso in cui sparisce ciò da cui è stato derivato. I riassunti sono per costruzione con perdita. È proprio questo a renderli utili. Ed è proprio questo a renderli una cattiva fonte primaria: una volta scartato l'originale, non c'è modo di distinguere un riassunto lacunoso da uno accurato.

I progettisti dell'UCP l'hanno capito a livello di protocollo e l'hanno messo per iscritto: conserva l'originale firmato, derivane ciò che vuoi e fai in modo che la derivazione possa sempre essere confrontata con qualcosa che non si è mosso. È una disciplina, non una tecnologia, e vale per un'ora di persone che parlano esattamente quanto vale per un POST /checkout-sessions.

In sostanza: il commercio agentico è uno standard di ricevute travestito da shopping

Il Universal Commerce Protocol viene di solito descritto come un modo per far comprare cose agli agenti IA. Letto da cima a fondo, è meglio descritto come il tentativo di rispondere a una domanda che tutto ciò che è agentico si troverà davanti di continuo: quando una macchina ha agito per me, che cosa esattamente si può dimostrare su ciò a cui ho acconsentito?

La risposta dell'UCP è buona: dichiara pubblicamente le tue capability, firma le condizioni, firma il consenso, metti una chiave sul retry, correla la chiamata e firma il webhook che riferisce poi che cosa è successo. Che il protocollo vinca è davvero questione aperta. La domanda attorno a cui è costruito non sparirà, chiunque vinca.

Resta una domanda su cui vale la pena fermarsi. I tuoi agenti stanno per avere una traccia migliore di ciò a cui hanno acconsentito rispetto a quella che tu hai di ciò a cui hai acconsentito tu. Dove va a finire questa cosa?

---

Dove si colloca Telli.sh: noi costruiamo la metà non firmata. Telli.sh registra la conversazione, separa gli interlocutori, traduce in diretta fra 15 lingue e conserva la registrazione originale e la trascrizione integrale accanto a ogni riassunto che genera, perché l'artefatto derivato non diventi mai l'unico artefatto. Telli.sh non implementa l'UCP e non sostiene di farlo; affrontiamo l'altro capo dello stesso problema, cioè che le decisioni che autorizzano il comportamento degli agenti vengono quasi sempre prese a voce e non vengono conservate da nessuna parte.

Registra la tua prossima riunione decisionale

Fonti

• Specifica Universal Commerce Protocol, Overview, versione 2026-04-08 — modello di servizi, capability ed estensioni, convenzione di denominazione, versionamento per data, algoritmo di intersezione delle capability, codici di errore di negoziazione e firma, capability standard (Cart, Checkout, Identity Linking, Order), trasporti, header UCP-Agent e sintassi RFC 8941, meccanismi di autenticazione e onboarding senza permessi, discovery delle chiavi tramite signing_keys, binding di identità, firma obbligatoria dei webhook e la sezione Transaction Integrity and Non-Repudiation; consultata il 5 settembre 2026
• Google Developers Blog, «Under the Hood: Universal Commerce Protocol (UCP)», 11 gennaio 2026 — elenco dei partner e il dato di oltre 20 sostenitori, compatibilità AP2/A2A/MCP, l'inquadramento N×N, il manifest /.well-known/ucp, il tutorial in cinque passi e il set di header di POST /checkout-sessions, Merchant of Record e l'opzione embedded, l'implementazione di riferimento di Google in AI Mode e Gemini, e il requisito Merchant Center; consultato il 5 settembre 2026
• Shopify Engineering, Ilya Grigorik, «Building the Universal Commerce Protocol», 11 gennaio 2026 — l'inquadramento 20+ anni / miliardi di transazioni / milioni di merchant, l'argomento «non è un bug, è una proprietà emergente», i quattro principi di progetto e il passaggio di consegne dell'Embedded Checkout Protocol su JSON-RPC 2.0 via continue_url; consultato il 5 settembre 2026
• Agent Payments Protocol (AP2) — il protocollo di pagamento con cui l'UCP dichiara compatibilità
• Universal Commerce Protocol su GitHub — il repository open source citato in entrambi gli annunci
• La nostra lettura di GPT-6 Astra e di ciò che il livello di cattura continua a decidere — lo stesso argomento dal lato modello: la qualità del ragionamento ha un tetto in ciò che ha prodotto la registrazione su cui ragiona