Sicurezza degli agenti A2A e MCP: identità, delega e audit trail

L’iniezione di prompt riceve la maggior parte dell’attenzione in termini di sicurezza nei sistemi LLM e merita attenzione, ma non è l’unico problema una volta che gli agenti iniziano a chiamare strumenti e a delegare il lavoro ad altri agenti.

MCP fornisce agli agenti un accesso strutturato a file, API, database e sistemi di ticketing. A2A consente a un agente di inviare task, messaggi e artefatti a un altro agente che potrebbe appartenere a un team diverso, a un fornitore o a un runtime diverso. Questi protocolli sono utili proprio perché attraversano i confini di fiducia, il che significa che identità, autorizzazione, limiti di delega e registri di audit diventano elementi architetturali di prima classe piuttosto che indurimento opzionale.

Questo articolo è la guida canonica per la sicurezza dei protocolli degli agenti nel cluster Architettura LLM. Copre modelli di minaccia, identità, gateway, registri, delega e checklist di produzione. Per la validazione degli input, il filtraggio degli output e i pattern di sicurezza dei prompt, consultare invece Guardrails LLM nella Pratica.

Guardrails vs Sicurezza dei Protocolli vs Policy di Runtime

Questi tre livelli risolvono problemi diversi e falliscono in modi diversi quando vengono confusi.

I guardrails LLM operano sull’input e sull’output del modello: bloccano i pattern di iniezione, filtrano contenuti dannosi, validano la struttura JSON e applicano regole di tono o conformità sul testo generato. Proteggono il livello di conversazione.

La sicurezza dei protocolli opera sui confini degli agenti: chi può chiamare quale strumento MCP, quale agente può delegare a quale peer, quali ambiti OAuth sono associati a un task e se un agente a valle può agire per conto di un utente. Protegge il livello di azione.

La policy di runtime si colloca tra i due: un motore di policy che valuta le richieste rispetto alle regole, indipendentemente dal fatto che il trigger fosse linguaggio naturale o una chiamata di protocollo strutturata. Può richiedere l’approvazione umana prima che uno strumento venga eseguito, bloccare l’egress verso domini sconosciuti o negare la delega quando l’ambito supera quello dell’utente che ha generato la richiesta.

Il mio parere è schietto: guardrails senza sicurezza dei protocolli producono chatbot educati che comunque esfiltrano dati attraverso una chiamata a uno strumento. La sicurezza dei protocolli senza guardrails produce agenti ben autenticati che comunque seguono istruzioni maliziose incorporate in un artefatto. Hai bisogno di entrambi, più policy di runtime per azioni ad alto rischio.

Modello di Minaccia per i Sistemi di Agenti A2A e MCP

Inizia con asset e avversari, non con una lista della spesa di controlli.

Asset da proteggere: dati utente nei prompt e negli artefatti, credenziali per i server MCP, sistemi di produzione raggiungibili attraverso gli strumenti, reputazione degli agenti, account di fatturazione legati all’utilizzo dei token e integrità degli audit.

Avversari realistici: utenti esterni che abusano degli endpoint pubblici degli agenti, server MCP compromessi che restituiscono risultati degli strumenti avvelenati, agenti maliziosi che falsificano le competenze nelle Agent Cards, insider che delegano eccessivamente l’autorità e manipolazioni della catena di fornitura sui metadati degli strumenti che manipolano il comportamento del modello.

Strumenti maliziosi o compromessi (MCP)

Un server MCP è codice più dati esposti al modello. Un server ostile può restituire descrizioni degli strumenti fuorvianti, esfiltrare gli argomenti passati dal modello o eseguire azioni oltre l’intento dell’utente quando l’host esegue chiamate agli strumenti senza credenziali con ambito definito.

Agenti maliziosi o impersonati (A2A)

Un agente che accetta task potrebbe essere malizioso, compromesso o semplicemente sovrapermessato. Le Agent Cards descrivono le capacità; non provano l’identità a meno che tu non verifichi firme, TLS e fiducia dell’emittente.

Confused deputy (Deputato confuso)

L’Agente B ha l’autorizzazione per accedere a un’API finanziaria. L’Agente A, con privilegi inferiori, chiede a B di “riassumere questa fattura” mentre nasconde un’istruzione di trasferimento in un artefatto. B esegue utilizzando le proprie credenziali a meno che l’ambito di delega non venga applicato da capo a fondo.

Permessi eccessivamente ampi e catene di delega nascoste

L’utente approva un singolo passaggio. L’orchestratore collega silenziosamente tre salti A2A e cinque chiamate MCP. L’utente non vede mai il grafico completo, ma l’organizzazione è comunque responsabile del risultato.

Iniezione di prompt attraverso artefatti e messaggi tra agenti

L’iniezione non è solo un problema di messaggi utente. Un artefatto PDF, una pagina web recuperata da uno strumento o un messaggio dall’Agente C possono trasportare istruzioni rivolte al modello dell’Agente D. Tratta tutti i contenuti trasportati dal protocollo come input non fidati al confine del modello.

Agent Cards avvelenate o fuorvianti

Le descrizioni e i nomi delle competenze sono superficie di prompt. Una card che pubblicizza safe_read_only_analysis (analisi di sola lettura sicura) mentre accetta backend in grado di scrittura è uno strato di ingegneria sociale, non una garanzia tecnica.

Modello di Identità per Sistemi Multi-Agente

La sicurezza del protocollo inizia con tipi di identità chiari e ciò che ciascuno è autorizzato a dimostrare.

La Agent Card di A2A pubblicizza schemi di autenticazione supportati (OAuth 2.0, chiavi API, mTLS e pattern simili allineati con la pratica OpenAPI) e competenze con requisiti di sicurezza opzionali. La card è metadati di discovery, non un’ancora di fiducia. I client ottengono credenziali out-of-band e le inviano nelle intestazioni HTTP standard in ogni richiesta; i server devono convalidare in ogni chiamata e restituire 401 o 403 quando l’autenticazione o l’ambito falliscono.

Viste interne vs esterne dello stesso agente

Gli agenti di produzione spesso pubblicano una Agent Card pubblica con un elenco limitato di competenze e una card autenticata più ricca per i chiamanti interni. La specifica A2A consente card estese per i client autenticati. Usa questa separazione deliberatamente: i partner non dovrebbero vedere le competenze interne e gli orchestratori interni non dovrebbero affidarsi solo al discovery pubblico per l’autorizzazione.

Autenticazione e Autorizzazione per MCP e A2A

L’autenticazione risponde a chi sta chiamando. L’autorizzazione risponde a cosa possono fare.

Accesso agli strumenti MCP

Per ogni connessione MCP, definisci:

• quale host dell’agente può connettersi
• quali strumenti sono abilitati per quell’host
• quale utente OS o account servizio esegue effetti collaterali
• se l’utente umano deve approvare ogni chiamata di mutazione

Preferisci liste di consento degli strumenti rispetto a configurazioni MCP “connetti tutto”. Un agente di coding non ha bisogno di server MCP per la retribuzione sullo stesso profilo di un bot di supporto pubblico.

Accesso agli agenti A2A

Per ogni relazione tra peer degli agenti, definisci:

• quali ID degli agenti chiamanti possono invocare quali competenze
• profondità massima di delega
• quali tipi di artefatti possono attraversare il confine
• se il contesto utente deve propagarsi come firme firmate

Mappa gli ambiti OAuth (o equivalenti) alle competenze, non all’amministrazione generica degli agenti. Il privilegio minimo a livello di token batte la speranza a livello di prompt.

Policy applicata dal gateway vs policy per agente

La policy per agente funziona quando un team possiede l’intero grafico e i rilasci sono coordinati. La policy applicata dal gateway funziona quando più team, tenant o fornitori condividono una rete di agenti e hai bisogno di un unico posto per applicare liste di consento, limiti di frequenza e audit.

Gateway A2A come Piano di Controllo

Un gateway A2A non è strettamente richiesto dal protocollo, ma diventa necessario quando il traffico degli agenti ha bisogno di una governance centralizzata.

Un gateway tipicamente gestisce:

• terminazione dell’autenticazione e scambio di token
• routing verso il servizio dell’agente corretto per competenza o tenant
• controlli di policy prima che i task siano accettati o inoltrati
• negoziazione della versione del protocollo
• limitazione della frequenza e rilevamento dell’abuso
• emissione strutturata degli audit su ogni transizione del task

Quando un gateway è eccessivo vs necessario

Un gateway è spesso eccessivo per un singolo orchestratore e due agenti specialisti in uno spazio dei nomi Kubernetes mantenuto da un singolo team. Diventa necessario quando i partner invocano i tuoi agenti, quando più unità aziendali condividono l’infrastruttura, quando la conformità richiede logging uniforme o quando non puoi fidarti che ogni implementazione dell’agente applichi la policy correttamente.

Abbina un gateway A2A con un gateway MCP (o proxy MCP) in modo che l’accesso agli strumenti riceva lo stesso trattamento: identità, liste di consento, controlli di egress e audit al confine dello strumento piuttosto che solo nell’interfaccia utente della chat.

Agent Cards per partner vs interni

Pubblica metadati di discovery diversi per chiamanti esterni e interni. Le card esterne espongono competenze ristrette e autenticazione più rigorosa. Le card interne possono elencare competenze di manutenzione o amministrazione ma non devono mai essere raggiungibili senza un’autenticazione più forte di quanto implichi la card pubblica.

Sicurezza del Registro e del Discovery degli Agenti

Il discovery è parte della superficie di attacco. Chiunque controlli quali agenti appaiono “disponibili” controlla dove gli orchestratori inviano il lavoro.

Registro vs URL noti delle Agent Card

Le piccole distribuzioni usano URL noti per agente (/.well-known/agent-card.json). Le distribuzioni enterprise aggiungono un registro che indicizza ID degli agenti, versioni, endpoint, proprietari e tag di policy. Il registro è un oggetto di policy: le voci dovrebbero registrare quali tenant possono scoprire quali agenti, non solo dove si trovano.

Versionamento, deprecazione e proprietà

I record del registro hanno bisogno di proprietari, cronologia delle modifiche e date di deprecazione. Un orchestratore che memorizza in cache le Agent Card deve aggiornarsi sul TTL e verificare le firme dove supportato. Le card obsolete sono il modo in cui le competenze ritirate continuano a ricevere traffico molto dopo che una vulnerabilità è stata patchata.

Reti interne enterprise vs partner esterni

I mesh di agenti interni possono fare affidamento su mTLS e DNS privati. Gli agenti dei partner hanno bisogno di regole di federazione esplicite, competenze con ambito contrattuale e ispezione degli artefatti più rigorosa perché non controlli il loro runtime.

Delega Attraverso i Confini degli Agenti

La delega è dove la sicurezza A2A viene vinta o persa. Quando l’Agente A invia un task all’Agente B, tre domande devono avere risposte precise:

1. Di chi autorità sta essere esercitata? Quella dell’utente, dell’account servizio di A o di un token delegato misto?
2. Cosa è consentito a B fare con quell’autorità? Analisi di sola lettura, o strumenti di mutazione per conto di A?
3. Chi è responsabile se B supera l’ambito? A, B, la policy del gateway o l’umano che ha approvato un prompt ambiguo?

Propagare l’intento utente vs delega eccessiva

Passa firme di delega firmate che includano ID utente, ID task originale, competenze consentite, scadenza e conteggio massimo dei salti. Gli agenti a valle devono rifiutare i task che espandono l’ambito silenziosamente. Se B ha bisogno di privilegi superiori rispetto a quelli detenuti da A, passa a input_required (input richiesto) e ottieni l’approvazione umana esplicita piuttosto che aggiornare i token invisibilmente.

I flussi di approvazione Human-in-the-loop per la delega rischiosa sono trattati in Streaming A2A e Task Asincroni per Flussi di Lavoro degli Agenti di Lunga Durata dove input_required è uno stato del task di prima classe piuttosto che un errore.

Separare il ragionamento dalle permessi di esecuzione

Un agente potrebbe aver bisogno di un ampio accesso in lettura per pianificare mentre gli strumenti di scrittura restano dietro l’approvazione. Dividi le credenziali o usa profili MCP distinti per la pianificazione rispetto all’esecuzione in modo che un errore del modello non possa mutare immediatamente la produzione.

Registri di Audit e Provenienza delle Risposte

Se non puoi ricostruire una catena di delega, non puoi spiegare un incidente, passare un audit o contestare un’anomalia di fatturazione.

Registra su tre livelli:

Gateway: risultato dell’autenticazione, decisione di policy, ID dell’agente instradato, ID task, ID del task genitore, eventi di limitazione della frequenza.

Agente: transizioni dello stato del task, messaggi inviati/ricevuti, invocazioni di modello/strumento (argomenti redatti se necessario), artefatti creati, delega in uscita.

Server MCP: nome dello strumento, ID dell’agente chiamante, contesto utente, successo/insuccesso, latenza, righe interessate o ID risorsa (se la policy lo permette).

Correla con l’ID trace attraverso tutti i livelli. Osservabilità per Sistemi LLM copre i backend di strumentazione; questo articolo definisce cosa deve essere catturato in modo che quei backend abbiano un segnale significativo.

La provenienza della risposta finale dovrebbe rispondere a: quale utente, quale task dell’orchestratore, quali agenti specialisti, quali strumenti, quali artefatti hanno influenzato il testo visto dall’utente e quali gate di policy sono stati attivati lungo il percorso.

Policy di Runtime, Egress e Segreti

I motori di policy di runtime (OPA, Cedar, servizi di regole personalizzati) valutano eventi strutturati: “strumento X con argomenti Y per utente Z”. Completano i guardrails perché non dipendono dal fatto che il modello si comporti bene.

L’approvazione umana appartiene alla policy di runtime per azioni irreversibili o ad alto costo: pagamenti, email esterne, modifiche alla configurazione di produzione, concessione di privilegi.

I controlli di egress limitano quali domini i server MCP e gli agenti possono chiamare. Un agente che può sia leggere segreti che POST su URL arbitrari è una perdita di dati in attesa di accadere.

I segreti non appartengono mai nelle Agent Card o nei prompt. Gli host MCP dovrebbero iniettare credenziali a vita breve al momento dell’esecuzione da un gestore di segreti. Per crittografia dei trasporti, gestione delle chiavi e pattern di sicurezza infrastrutturali di base, vedere Pattern Architetturali per la Sicurezza dei Dati.

I webhook di notifica push nei flussi A2A asincroni hanno bisogno della stessa rigore: verifica l’identità del mittente, rifiuta eventi obsoleti e non considerare mai il payload di un webhook come autorizzazione di per sé.

Architettura di Sicurezza di Riferimento

Il seguente diagramma riassume un layout orientato alla produzione per distribuzioni A2A fuori, MCP dentro su larga scala.

L’orchestratore vede gli agenti specialisti attraverso A2A. Gli specialisti vedono gli strumenti attraverso MCP. Gli utenti non ricevono mai credenziali MCP grezze e i partner non ricevono superfici di competenze interne senza revisione della policy.

Per i concetti del protocollo (Agent Cards, task, artefatti), vedere Cos’è il Protocollo A2A?. Per l’adozione e il contesto enterprise, vedere Protocollo Google A2A nel 2026. Per la topologia quando molti agenti coordinano, vedere Pattern di Orchestrazione Multi-Agente.

Checklist di Produzione per la Sicurezza A2A e MCP

Prima di esporre i protocolli degli agenti oltre un sandbox fidato, verifica:

Identità e autenticazione

• Nessun agente anonimo nei percorsi di produzione
• Ogni chiamata MCP e A2A autenticata in ogni richiesta
• Ambiti OAuth o equivalenti mappati a competenze/strumenti, non amministrazione generica
• Viste delle Agent Card pubbliche vs autenticate definite deliberatamente

Delega e policy

• I token di delega trasportano ID utente, ID task, ambito, scadenza, limite di salti
• Gli agenti a valle rifiutano l’espansione dell’ambito senza approvazione esplicita
• Gli strumenti ad alto rischio richiedono policy di runtime o approvazione umana
• Il ragionamento e l’esecuzione usano credenziali separate ove possibile

Discovery e registro

• Le voci del registro degli agenti hanno proprietari e cronologia delle versioni
• Le Agent Card aggiornate sul TTL; firme verificate dove supportato
• Gli agenti dei partner federati con liste di consento delle competenze esplicite

Audit e osservabilità

• I livelli gateway, agente e MCP emettono eventi di audit correlati
• Le catene di delega registrate con ID del task genitore e figlio
• La provenienza degli artefatti registrata per le risposte finali
• Gli ID trace connessi ai backend di osservabilità

Abuso e resilienza

• Limiti di frequenza per utente, agente e tenant
• Policy di timeout sui task delegati
• Liste di consento di egress sui server degli strumenti
• Segreti in un gestore, non nelle card, prompt o repository

Conclusione

L’interoperabilità A2A e MCP è potente perché agenti e strumenti possono comporsi attraverso i confini dei team e dei fornitori, ma quella potenza è insicura senza identità, autorizzazione, limiti di delega e progettazione degli audit. I guardrails proteggono la conversazione del modello; la sicurezza del protocollo protegge le azioni che gli agenti compiono per conto degli utenti.

Tratta le Agent Cards come pubblicità, la delega come un contratto firmato, gli strumenti MCP come esecuzione di codice privilegiato e i registri di audit come la catena di prove di cui avrai bisogno quando succede qualcosa di interessante alle 2 del mattino.

Costruisci il gateway quando la governance ha bisogno di una gola unica da strozzare. Dividi le credenziali prima di dividere gli agenti. Registra ogni salto in modo che la risposta “il modello ha deciso” non sia mai il rapporto dell’incidente finale.

Domande Frequenti

Qual è la differenza tra guardrails LLM e sicurezza degli agenti A2A MCP? I guardrails vincolano l’input e l’output del modello. La sicurezza del protocollo vincola chi può invocare strumenti, delegare task e agire per conto di chi attraverso MCP e A2A con identità, autorizzazione e registri di audit.

Come dovrebbe funzionare l’identità dell’agente in una distribuzione A2A? Separare le identità umane, del servizio agente e del task. Validare le credenziali in ogni richiesta, usare token con ambito e trattare le Agent Card come metadati di discovery piuttosto che prova di fiducia.

Qual è il problema del “confused deputy” nei sistemi multi-agente? Si verifica quando un agente o strumento privilegiato esegue un’azione sensibile perché un chiamante meno privilegiato ha nascosto istruzioni attraverso la delega o gli artefatti. Applicare l’ambito a ogni salto.

Hai bisogno di un gateway A2A in produzione? Le distribuzioni interne di un singolo team possono applicare la policy per agente. Le reti multi-tenant, multi-fornitore o rivolte ai partner di solito hanno bisogno di un gateway per autenticazione centralizzata, routing, limiti di frequenza e audit.

Cosa dovrebbe contenere un registro di audit A2A MCP? ID utente, ID agente, ID task, ID del task genitore, chiamate agli strumenti, decisioni di policy, artefatti e timestamp correlati con ID trace attraverso i livelli gateway, agente e MCP.

Fonti

• Protocollo A2A – Argomenti di sicurezza enterprise-ready: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• Protocollo A2A – Panoramica della specifica: https://a2a-protocol.org/latest/specification/
• Protocollo A2A – Sicurezza dello streaming e delle notifiche push: https://a2a-protocol.org/latest/topics/streaming-and-async/