Meccanismi di sicurezza A2A: il sistema di controllo accessi per la fiducia tra agenti

Quando due AI si “chiamano” a vicenda, qual è la paura più grande? Non che chiacchierino all’infinito, ma che uno sconosciuto bussi alla porta fingendo di essere un conoscente.

Principi di progettazione della sicurezza: prima chiudi la porta, poi aprila

Immagina di trasferirti in una nuova casa: la prima cosa che fai non è appendere le tende, ma cambiare la serratura. I progettisti del protocollo A2A hanno pensato esattamente lo stesso — sicurezza di default, ogni apertura deve essere un’operazione esplicita. Questo meccanismo funziona come un sistema di controllo accessi completo: serratura (token), badge (chiave del peer), spioncino (identificazione), telecamere di sorveglianza (log di audit). Nella piattaforma di messaggistica Hermes, la funzionalità A2A è fornita come plugin, ma i default di sicurezza non scendono a compromessi: senza token configurato, ascolta solo su 127.0.0.1 in locale — come se la porta fosse chiusa a chiave e la chiave fosse solo nelle tue mani.

Le quattro linee di difesa in dettaglio

Prima linea: binding locale + token (la serratura)

Di default, A2A ascolta solo in locale, e dall’esterno non si può nemmeno toccare la porta. Per esporre un servizio verso l’esterno, devono essere soddisfatte due condizioni contemporaneamente: impostare A2A_HOST per esporre l’indirizzo e configurare un bearer token. È come se non bastasse aprire la finestra, ma dovessi anche mettere un cactus spinoso sul davanzale — entrambe le cose sono indispensabili.

Seconda linea: chiave indipendente per ogni peer (il badge)

Ogni peer ha il proprio token esclusivo, configurato tramite A2A_PEER_TOKENS="alice:tok1,bob:tok2". Non è come una chiave maestra che apre tutte le porte, ma ogni visitatore ha il proprio badge personale. L’identità autenticata guida il rate limiting, le liste di fiducia e l’audit — chi ha usato il badge, quante volte, e quando, tutto viene registrato.

Terza linea: filtro di injection + sanificazione (il controllo di sicurezza)

Il testo in ingresso viene filtrato e marcato come “input da peer non fidato”; i peer remoti non possono invocare i comandi slash dell’operatore. È come il controllo in aeroporto: i liquidi nel bagaglio devono essere estratti e controllati separatamente. Nelle risposte in uscita, le stringhe che assomigliano a credenziali (API key, JWT, token) vengono automaticamente cancellate — come se nelle lettere spedite venisse oscurato automaticamente il codice fiscale del destinatario.

Quarta linea: log di audit + protezione anti-ciclo (le telecamere di sorveglianza)

Ogni scambio viene aggiunto a ~/.hermes/a2a_audit.jsonl, come se ci fosse una videocamera attiva 24 ore su 24 davanti alla porta. Il limite massimo di round anti-ciclo funziona come il citofono del vicino: se due AI continuano a parlare all’infinito, il sistema interrompe automaticamente.

Storie di attacchi reali: 3 problemi scoperti e corretti dalla community

Storia uno: bypass SSRF (#78298) — ingannare la serratura con un “codice numerico segreto”

Un attaccante ha scoperto che il controllo di sicurezza dell’URL di callback usava un prefisso di stringa per confrontare il nome host, ad esempio verificando se inizia con 127.. Ma gli indirizzi IP hanno una notazione “intera” — 2130706433 è un altro modo di scrivere 127.0.0.1. È come scrivere il numero civico in codice Morse: il portiere non lo riconosce e lascia passare. Soluzione: prima risolvere l’host del callback in un IP standard e poi valutare — come se il portiere traducesse qualsiasi formato di indirizzo in un numero civico standard prima di confrontarlo.

Storia due: collasso dell’identità dietro il reverse proxy (#80534/#80779) — tutti diventano la stessa persona

Quando si è dietro nginx o K8s, il plugin A2A deduce l’identità del chiamante dall’indirizzo del socket. Ma il proxy si mette in mezzo, e tutti i peer appaiono con lo stesso IP — quello del proxy. È come la guardiola del condominio: tutti i visitatori vengono registrati come “firmato dalla guardiola”. Il rate limiting condivide un unico bucket (uno lento rallenta tutti), la whitelist di fiducia può contenere solo l’indirizzo del proxy, e l’audit non vede il vero chiamante. Soluzione: dedurre l’identità reale da X-Forwarded-For, ma accettarlo solo quando si è “dietro un proxy fidato”.

Storia tre: punto cieco nell’audit (#81003/#81042) — i colpi alla porta rifiutati non vengono registrati

Il log di audit registra solo il traffico accettato. Le richieste con 401 (token non valido) e 403 (non fidato) non generano alcuna registrazione. È come se la videocamera di sorveglianza riprendesse solo chi entra senza problemi, ma non registrasse il ladro che scassa la serratura. Attacchi di credential stuffing, tentativi con token revocati, tentativi di movimento laterale — questi attacchi sono esattamente ciò che l’audit dovrebbe catturare. Soluzione: anche tutti i rifiuti di autenticazione vengono aggiunti al log di audit append-only, con campo decision + codice di stato HTTP + IP del chiamante.

Cosa significa per gli utenti

La logica centrale di questo meccanismo è: la sicurezza non è un rimedio a posteriori, ma lo stato predefinito. Come utente di Hermes, non devi essere un esperto di sicurezza per ottenere una protezione di base — le quattro linee di difesa si attivano automaticamente. Ancora più importante, la community continua a rafforzare il sistema attraverso attacchi reali: dal bypass SSRF al collasso dell’identità dietro il reverse proxy, fino ai punti ciechi nell’audit, ogni problema corrisponde a uno scenario reale. Il protocollo A2A è come un castello che viene continuamente fortificato: ogni mattone è stato testato sul campo. La prossima volta che i tuoi due agenti si “chiamano” a vicenda, tra loro non ci sono solo serrature, badge, controlli di sicurezza e videocamere, ma anche un gruppo di guardie che osservano i log.