Implementazione

Interoperabilità degli agenti AI: MCP e A2A spiegati per aziende (2026)

Scritto da 7 min di lettura
Interoperabilità degli agenti AI: MCP e A2A spiegati per aziende (2026)

MCP collega un agente AI a strumenti e dati; A2A collega agenti AI tra loro. Il Model Context Protocol è il modo standard con cui un agente legge il CRM, interroga un database o chiama un’API. Agent2Agent è il modo standard con cui un agente affida un compito a un altro agente, anche di un altro fornitore, e ne riceve il risultato. Da agosto 2026 entrambi stanno sotto la stessa governance neutrale: l’Agentic AI Foundation della Linux Foundation.

Per una PMI la regola pratica è semplice: MCP serve quasi sempre, A2A raramente. Il primo agente in produzione lavora su un processo con pochi strumenti; la collaborazione tra agenti di vendor diversi arriva dopo, se arriva.

MCP vs A2A: differenze in una tabella

MCP — Model Context ProtocolA2A — Agent2Agent
CollegaAgente → strumenti, dati, promptAgente → altro agente
Domanda a cui risponde«Con cosa lavora l’agente?»«Con chi collabora l’agente?»
Creato daAnthropic (novembre 2024)Google (aprile 2025)
GovernanceAgentic AI Foundation (Linux Foundation)Agentic AI Foundation, dal 17 agosto 2026
Versione stabileSpecifica 2026-07-28v1.0, marzo 2026
Unità di scambioTool, risorse, prompt esposti da un serverTask delegati, messaggi, artefatti
IdentitàOAuth 2.1 verso il server MCPAgent card firmate, autenticazione dichiarata nella card
EsempioL’agente legge un ordine dal gestionale via un server MCPL’agente acquisti chiede all’agente logistico del fornitore una data di consegna

I due protocolli sono complementari: lo stesso agente può usare MCP per i propri strumenti e A2A per delegare a un agente esterno. Axios lo ha riassunto così quando A2A è entrato nell’AAIF: MCP gestisce le connessioni tra applicazioni AI, strumenti e dati; A2A la comunicazione tra agenti indipendenti (Axios, 17 agosto 2026).

Cosa è cambiato in MCP con la specifica 2026-07-28

La revisione 2026-07-28 è la più grande dall’uscita del protocollo. Per chi integra agenti in azienda contano quattro cambiamenti:

  1. Protocollo stateless. Spariscono l’handshake initialize e l’header Mcp-Session-Id. Ogni richiesta porta versione del protocollo e capability del client: qualsiasi istanza del server può rispondere dietro un normale load balancer, senza sessioni condivise.
  2. server/discover. Un metodo opzionale per il client, obbligatorio per il server, che espone versioni supportate, capability e identità.
  3. Stato esplicito. Chi ha bisogno di stato tra una chiamata e l’altra usa handle creati dal server e passati come argomenti dei tool, non più sessioni implicite.
  4. Autorizzazione più rigida. La registrazione dinamica dei client (DCR) è deprecata a favore dei Client ID Metadata Documents (CIMD); arriva la validazione dell’issuer (RFC 9207). Restano obbligatori PKCE e l’indicazione della risorsa (RFC 8707), e resta vietato il token passthrough.

Tradotto per un’azienda: server MCP più facili da scalare e da mettere dietro un gateway, e meno scuse per gestire i token in modo approssimativo. Se un fornitore vi propone un server MCP, chiedete quale versione della specifica supporta.

A2A v1.0: cosa porta

A2A è nato in Google ad aprile 2025, è stato donato alla Linux Foundation con organizzazioni fondatrici come AWS, Cisco, Google, Microsoft, Salesforce, SAP e ServiceNow, e ad agosto 2025 ha assorbito l’Agent Communication Protocol di IBM (AAIF). La v1.0, prima specifica stabile, è di marzo 2026 e ha aggiunto:

  • binding multipli (JSON-RPC, HTTP+JSON, gRPC) con negoziazione della versione;
  • multi-tenancy;
  • agent card firmate, cioè una scheda pubblica dell’agente (capacità, endpoint, autenticazione) verificabile crittograficamente.

L’AAIF dichiara oltre 150 organizzazioni a supporto di A2A e il supporto in Google Cloud, Azure AI Foundry e AWS Bedrock AgentCore (AAIF).

Quando serve MCP, quando A2A, quando nessuno dei due

SituazioneCosa usare
Un agente che legge documenti e scrive su un solo gestionaleAPI diretta o un server MCP
Un agente che usa 3–5 sistemi (CRM, ERP, email, archivio)MCP, un server per sistema con permessi separati
Volete poter cambiare modello o piattaforma agentica senza rifare le integrazioniMCP: le integrazioni restano, cambia il client
Un vostro agente deve delegare a un agente di un fornitore o di un clienteA2A
Più agenti interni sulla stessa piattaformaOrchestrazione nativa della piattaforma; A2A solo se dovrete aprirvi a terzi
Flusso fisso «se X allora Y»Nessuno dei due: workflow o RPA

Il protocollo non sostituisce il progetto dei permessi: un server MCP con accesso completo al gestionale è un rischio anche se rispetta la specifica. Per il lato integrazioni vedi collegare un agente al gestionale; per i livelli di autorizzazione agenti AI per aziende.

Sicurezza: i tre rischi da gestire

Tool poisoning. Istruzioni malevole nascoste nelle descrizioni dei tool, negli schemi dei parametri o nelle risposte. Il modello le legge come contesto affidabile e può chiamare tool non previsti o far uscire dati. L’OWASP MCP Security Cheat Sheet tratta l’intero schema del tool come superficie di injection, non solo la descrizione.

Token passthrough. Un server MCP che accetta token non emessi per lui e li inoltra alle API a valle. La specifica lo vieta esplicitamente: il server deve accettare solo token con il proprio audience (MCP security best practices).

Confused deputy. Il server esegue azioni con i propri privilegi, spesso ampi, invece che con quelli dell’utente che ha fatto la richiesta.

Controlli minimi da chiedere in qualsiasi progetto:

  • allowlist dei server MCP approvati, niente installazioni libere;
  • definizioni dei tool fissate con hash, con allarme se cambiano;
  • credenziali per server, scope stretti, token a breve durata;
  • permessi applicati lato server, non affidati al prompt;
  • approvazione umana fuori dal modello per azioni con effetti (invio, pagamento, cancellazione);
  • log di ogni chiamata tool con utente, agente, parametri ed esito.

Cosa chiedere a un fornitore

  1. Quale versione della specifica MCP supportate, e con quale meccanismo di autorizzazione?
  2. Ogni server MCP ha un’identità e credenziali proprie, o condividono un account di servizio?
  3. Come vengono approvati i nuovi tool e come si rileva se una definizione cambia?
  4. Dove sono i log delle chiamate e per quanto tempo si conservano?
  5. Se usate A2A, come verificate la agent card dell’agente esterno e cosa gli è permesso chiedere?
  6. Se cambiamo modello o piattaforma, quali integrazioni restano e quali vanno rifatte?

FAQ

Cos’è l’interoperabilità degli agenti AI?
La capacità di un agente di usare strumenti e collaborare con altri agenti tramite protocolli standard. Oggi: MCP per agente-strumento, A2A per agente-agente.

Qual è la differenza tra MCP e A2A?
MCP collega l’agente a strumenti e dati; A2A lo collega ad altri agenti per delegare compiti. Sono complementari.

Una PMI ha bisogno di A2A?
Di solito no: serve quando agenti di piattaforme o aziende diverse devono collaborare.

Cosa cambia con la specifica MCP 2026-07-28?
Protocollo stateless, server/discover, stato con handle espliciti, DCR deprecata a favore di CIMD e validazione dell’issuer.

MCP è sicuro?
Il protocollo sì, se usato bene: i rischi sono tool poisoning, token passthrough e confused deputy, da gestire con allowlist, hash, permessi minimi e approvazioni fuori dal modello.

Chi governa MCP e A2A?
L’Agentic AI Foundation della Linux Foundation, per entrambi.

Fonti

Approfondisci nella serie

Se state valutando come collegare un agente ai vostri sistemi senza dargli più permessi del necessario, partiamo dal processo e dai sistemi coinvolti. Scriveteci a info@zendata.it.

Pietro Ciattaglia, CEO di Zendata AI, Roma