1. Panorama attuale

Il settore ha dimostrato che è possibile standardizzare parti cruciali dell’architettura agenziale. Il Model Context Protocol (MCP) si è consolidato come interfaccia di fatto per collegare agenti a strumenti, dati e applicazioni. Tuttavia, non esiste ancora uno standard equivalente, ampiamente adottato, che risolva l’interoperabilità generale tra agenti indipendenti.

Il problema non è solo far scambiare messaggi a due agenti, ma consentire loro di scoprire reciprocamente la propria identità, descrivere le capacità in modo comparabile, delegare compiti e autorità, limitare permessi e produrre risultati tracciabili mediante regole comuni.

1.1 – MCP – Protocollo consolidato agente‑strumento

Il Model Context Protocol normalizza come un’applicazione o agente acceda a strumenti, risorse e servizi. La versione di luglio 2026 ha sostituito il nucleo basato su sessioni con un modello stateless di richiesta‑risposta, ha rafforzato l’autorizzazione e ha reso opzionale la scoperta tramite server/discover. Il ciclo di attività, inizialmente sperimentale, è passato a una estensione.

Grazie alla sua adozione trasversale, agli SDK ufficiali e alla governance della Agentic AI Foundation, MCP è considerato uno standard di fatto in questo ambito specifico.

MCP dimostra due aspetti rilevanti per il dibattito:

    • I fornitori possono convergere su un’interfaccia aperta.
    • OAuth e gli standard web esistenti possono fungere da base per la sicurezza.

Tuttavia, MCP non risolve da solo la relazione completa tra agenti autonomi. Un server MCP espone capacità al client, ma non rappresenta necessariamente un altro agente con identità, autonomia, obiettivi, ciclo di attività e capacità di delega propri.

1.2 – A2A Protocol: produzione e adozione in espansione

A2A Protocol è stato creato da Google per la comunicazione tra agenti indipendenti. Lanciato nell’aprile 2025, è stato donato alla Linux Foundation e, nell’agosto dello stesso anno, il Agent Communication Protocol di IBM è stato integrato in A2A. Da agosto 2026 è un progetto della Agentic AI Foundation, non più un’estensione privata di Google.

La versione 1.0, prima specificazione stabile, definisce:

    • Scoperta tramite Agent Cards.
    • Descrizione delle capacità e meccanismi di sicurezza.
    • Negoziazione di versione, multitenancy e Agent Cards firmate.
    • Messaggi, compiti e artefatti.
    • Stati, cancellazione e monitoraggio.
    • Interazione sincrona, streaming e notifiche.
    • Bindings HTTP/JSON, JSON‑RPC e gRPC.

È un protocollo aperto con implementazioni in produzione. Il progetto fornisce un Technology Compatibility Kit per i tre binding e un repository di test per gli SDK ufficiali, includendo due suite: ITK per verificare l’interoperabilità tra SDK e ACTS per la conformità alla specifica.

Superare questi test non equivale a una certificazione indipendente né dimostra chi ha originato una richiesta, quale autorità è stata delegata a ciascun salto o quali dati e operazioni sostengono il risultato. La Linux Foundation segnala più di 150 organizzazioni che lo supportano e implementazioni in produzione, ma questo non quantifica l’effettivo utilizzo.

A2A è integrato nelle piattaforme di agenti di Google Cloud, Microsoft Azure AI Foundry e Amazon Bedrock AgentCore, mentre Huawei lo ha adottato come protocollo tra il suo assistente di sistema e gli agenti di applicazione in HarmonyOS.

Un’esperienza di produzione basata su A2A 0.3, descritta da una ingegnere di Eon nel blog della fondazione, ha evidenziato carenze nella trasmissione dell’identità del richiedente e nella tracciabilità necessaria per verificare i risultati.

1.3 – Altre iniziative: scoperta e controllo del traffico

AGNTCY, proposto da Cisco alla Linux Foundation, offre un servizio di directory di agenti (Agent Directory Service) con scoperta federata, metadati descritti mediante lo schema OASF (Open Agentic Schema Framework) e firma/verifica crittografica dei record.

AGNTCY si occupa della scoperta e della descrizione delle capacità, incorporando meccanismi di fiducia federata tramite SPIFFE (Secure Production Identity Framework for Everyone) e la sua implementazione di riferimento SPIRE (SPIFFE Runtime Environment), tra domini configurati per federarsi. Tuttavia, non stabilisce da solo la fiducia tra parti sconosciute.

Agentgateway, progetto della Agentic AI Foundation dal giugno 2026, applica politiche di sicurezza e osservabilità al traffico MCP e A2A; è un’infrastruttura di controllo, non uno standard di interoperabilità.

1.4 – Identità e autorizzazione: esistono i mattoni, manca il profilo comune

OAuth, OpenID Connect, JWT, PKCE, mTLS, DPoP e OAuth Token Exchange forniscono meccanismi maturi per autenticare client, limitare accessi e delegare credenziali. Il problema emerge quando si concatenano più agenti, che devono distinguere:

    • la persona o organizzazione che origina l’istruzione;
    • l’applicazione cliente;
    • l’agente decisionale;
    • l’operatore dell’agente;
    • gli agenti delegati;
    • la risorsa finale su cui si agisce.

L’OpenID Foundation ritiene che OAuth funzioni adeguatamente in scenari semplici e all’interno di un unico dominio di fiducia, ma può risultare insufficiente in operazioni autonome, asincrone, multi‑utente o inter‑organizzative.

Nel IETF coesistono lavori di diversa maturità: OAuth Identity Chaining è un draft del gruppo OAuth in via di standardizzazione, in coda al RFC Editor; Transaction Tokens è un altro lavoro del gruppo, già con consenso interno. Il profilo DAAP, specificamente orientato agli agenti, resta una proposta individuale e non è stato adottato dal gruppo.

Al momento nessuno di questi costituisce un profilo universale di identità e delega multi‑agente.

2. Cosa funziona oggi: prenotazioni, acquisti e pagamenti

Esistono già flussi operativi di acquisto e prenotazione eseguiti da agenti. Per valutare cosa risolvono, è utile distinguere l’accesso a un servizio, l’autorizzazione di una transazione e l’interoperabilità generale tra agenti.

2.1 – Accesso tramite API o browser

Un agente può utilizzare l’API di un fornitore, direttamente o esposta come strumento MCP, per eseguire le operazioni consentite dal servizio. Questa integrazione non richiede comunicazione tra due agenti autonomi; l’agente agisce come client di un servizio mediante un’interfaccia definita.

In alternativa, l’agente può operare su form e controlli di una pagina web. Quando utilizza la sessione dell’utente senza presentare un’identità propria, il servizio non dispone necessariamente di una distinzione verificabile tra utente e agente, né di limiti di delega. È il problema della “rappresentazione opaca” evidenziato dall’OpenID Foundation. Inoltre, non implica che tutti gli agenti basati su browser siano indetectabili.

2.2 – Protocolli settoriali di commercio e pagamenti

ACP (Agentic Commerce Protocol), sviluppato congiuntamente da OpenAI e Stripe, sostiene l’Instant Checkout in ChatGPT fornendo specifiche aperte per integrare processi di acquisto tra agenti e commercianti.

    • Definisce sessioni di acquisto tramite API, richieste firmate, chiavi di idempotenza per evitare duplicati e notifiche sullo stato dell’ordine.
    • Il commerciante conserva la decisione di accettare l’ordine e gestisce il pagamento con il proprio provider.
    • Il pagamento delegato stabilisce un importo massimo e una scadenza per l’autorizzazione di addebito.

Questo ACP commerciale è distinto dal Agent Communication Protocol di IBM citato in precedenza.

AP2 (Agent Payments Protocol), iniziato da Google, aggiunge autorizzazione verificabile ai pagamenti agenziali e può integrarsi con A2A. La versione 0.2 distingue i mandati di acquisto (Checkout Mandates) e di pagamento (Payment Mandates), collegati mediante l’hash dell’oggetto di acquisto firmato. Supporta l’approvazione di un acquisto specifico o un’autorizzazione preventiva.

Entrambi i protocolli dimostrano che, in contesti commerciali, è possibile definire flussi sicuri e tracciabili, ma rimangono limitati al dominio del commercio e non affrontano la completa interoperabilità tra agenti con obiettivi e autorità differenti.

3. Lacune e prospettive future

Nonostante i progressi, persistono sfide critiche:

    • Assenza di un profilo di identità e delega universalmente riconosciuto per catene multi‑agente.
    • Scarsa capacità di trasportare la provenienza della richiesta attraverso più salti, indispensabile per la verifica dei risultati.
    • Necessità di standardizzare il “discovery” federato con garanzie di fiducia reciproca, oltre al semplice annuncio di capacità.
    • Integrazione di meccanismi di audit e tracciabilità che siano interoperabili tra diversi ecosistemi (cloud, on‑premise, edge).

Le organizzazioni di standardizzazione – IETF, OpenID Foundation, Linux Foundation – stanno lavorando su draft e proposte, ma la convergenza richiederà tempo, sperimentazione su larga scala e un impegno coordinato tra fornitori di cloud, produttori di hardware e comunità open source.

Nel frattempo, le imprese possono adottare una combinazione di MCP per l’interfaccia con strumenti, A2A per la comunicazione agente‑agente, e i profili OAuth più avanzati per la delega di credenziali, integrando soluzioni di directory come AGNTCY per la scoperta federata. Tale approccio “ibrido” rappresenta la via più pratica per realizzare sistemi agenziali complessi, pur riconoscendo che la piena interoperabilità rimane un obiettivo a medio‑lungo termine.