A GovWare 2026, in corso dal 13 al 15 ottobre, GoDaddy, Infoblox, Google e Cloudflare presentano con l’IMDA di Singapore Chain of Trust: un’architettura di riferimento che simula l’acquisto di un volo da Madrid a Singapore tramite agenti indipendenti. La persona approva la spesa con una passkey e il flusso si conclude con un pagamento in modalità test: non vengono trasferiti fondi reali.
I quattro agenti e la persona che autorizza
La prova mette in relazione quattro agenti: uno cerca e acquista, uno vende, un servizio emette le autorizzazioni e un verificatore indipendente controlla i registri. La persona usa un assistente AI per avviare la richiesta, ma mantiene l’approvazione dell’acquisto. Secondo il caso tecnico ufficiale di Open Agent Commerce, gli agenti operano su quattro domini e tre provider cloud: AWS ospita l’agente acquirente, Cloudflare quello venditore, mentre Google Cloud ospita il servizio di approvazione e il verificatore.
Dalla scoperta del venditore ai controlli
Il percorso documentato parte dall’accesso con passkey e dalla ricerca del venditore tramite DNS. L’agente acquirente effettua 14 controlli sul venditore, riceve preventivi firmati e sottopone l’acquisto all’approvazione umana. Il servizio di approvazione emette quindi due mandati AP2 firmati; l’agente invia una richiesta di completamento commerciale firmata e il venditore esegue 10 controlli prima di procedere. Il flusso prosegue con il pagamento di test, le ricevute firmate, i registri e la verifica indipendente.
I protocolli hanno compiti distinti: DNS supporta la scoperta del venditore, A2A la comunicazione tra agenti, MCP collega l’assistente della persona all’agente acquirente e UCP trasporta i dati commerciali e la richiesta di checkout. La prova mostra così dove avvengono la ricerca, il consenso e i controlli, senza affidare l’intero percorso a un’unica piattaforma condivisa.
Come l’approvazione limita l’autorità dell’agente
La passkey serve a esprimere il consenso della persona; l’identità dell’agente, da sola, non gli conferisce il diritto di spendere. Il mandato AP2 di checkout è vincolato a un venditore e a uno specifico checkout, mentre quello di pagamento indica un beneficiario e un importo. Entrambi sono limitati nel tempo e associati alla chiave dell’agente acquirente. L’agente acquirente non può firmare i mandati per conto proprio.
Nel flusso descritto, la persona può interrompere l’agente o annullare un’autorizzazione. Il venditore controlla in tempo reale lo stato del mandato; chi gestisce un agente può inoltre ritirarne la chiave o rimuovere il relativo record DNS. Sono controlli della specifica implementazione di riferimento, non caratteristiche automatiche di ogni sistema di pagamento basato su agenti.
Pagamento di test e limiti dei registri
Stripe opera in modalità test e la simulazione non trasferisce denaro reale. Il caso tecnico riferisce inoltre che le richieste contraffatte o alterate provate negli scenari di test sono state respinte e non hanno prodotto pagamenti.
Ogni partecipante mantiene un registro con hash concatenati; punti di controllo firmati vengono registrati anche in un log pubblico SCITT. Un log di trasparenza può attestare che un record esisteva, inalterato, in un determinato momento: non certifica che il suo contenuto sia vero. I registri pubblici servono alla dimostrazione; per gli impieghi commerciali, il progetto prevede registri privati con accesso concesso a verificatori scelti.
Il progetto descrive Chain of Trust come un’architettura di riferimento in fase iniziale. Anche le tecnologie impiegate hanno livelli di maturità diversi: DNS-AID e ANS sono Internet-Draft dell’IETF, mentre ARD è una specifica di comunità.
