Il modello di fiducia di MCP ha permesso a un agente avvelenato di raggiungerne un altro

Il protocollo diventato il modo predefinito per collegare insieme gli agenti AI ha un problema di fiducia, e vale la pena capirne la forma prima del prossimo incidente.

Ars Technica ha riportato il 5 ottobre che un ricercatore indipendente, Syed Anas Mohiuddin, ha dimostrato una classe di attacco che chiama "protocol pivoting". L'idea è semplice. All'interno di una rete, gli agenti comunicano tra loro tramite il Model Context Protocol, o MCP. Le protezioni sono più deboli nel punto in cui un agente affida un compito a un altro, perché il secondo agente si fida del primo per impostazione predefinita. Basta inserire un'istruzione malevola in un agente di traduzione o di analisi dati privo di una rigorosa validazione degli input, e questo trasmetterà l'istruzione a valle. Il destinatario obbedisce, perché mai un collega fidato dovrebbe mentire.

La proof of concept di Mohiuddin ha attraversato cinque organizzazioni non correlate: Google, JPMorgan Chase, Weviate, Rapid7, la direzione interministeriale digitale francese e un'agenzia federale statunitense. Queste organizzazioni condividono poco, tranne un uso intenso degli agenti. È proprio questo il punto. La debolezza è nell'infrastruttura di connessione, non in un singolo prodotto.

Due CVE e un divario nelle valutazioni

I bug concreti sono ordinari, e questo contribuisce a rendere la storia scomoda. Il server MCP di Rapid7 presenta CVE-2026-97228, che l'azienda ha corretto a settembre 2026 anche se la falla aveva un punteggio di 2,7 su 10. Il problema di Google era classificato più in alto, un 8, e riguardava googleapis/mcp-toolbox. Il suo client HTTP mancava di una policy CheckRedirect e della validazione dell'IP di destinazione, quindi un parametro di percorso appositamente costruito poteva reindirizzare una richiesta verso un endpoint interno. Google ha aggiunto allowlist e blocklist di IP e ha fatto sì che il toolbox rifiutasse le URL di base non sicure all'avvio.

La discrepanza nei punteggi di gravità è di per sé una lezione. Due organizzazioni hanno trovato debolezze comparabili nello stesso protocollo e le hanno valutate in modo molto diverso, il che suggerisce che il settore non ha ancora stabilito quanto debba costare un divario di fiducia tra agente e agente.

Non tutti accettano il "protocol pivoting" come una nuova categoria. Markus Vervier, ricercatore presso X41 D-Sec, ha detto ad Ars Technica che lo interpreta come prompt injection indiretta, la stessa tecnica che i team di sicurezza monitorano da due anni. Questa inquadratura è corretta, e acuisce anche il problema pratico: il manuale difensivo per la prompt injection presume che l'input arrivi dall'esterno. Qui arriva dall'interno, indossando una credenziale interna.

Il divario è architetturale, non una patch

Un rapporto separato del fornitore di sicurezza ClawSecure spinge l'analisi un livello più a fondo. I suoi ricercatori hanno testato Linear, Notion e Dropbox Dash e sostengono che il difetto risieda nella specifica MCP, non nell'implementazione di un fornitore. In Notion e Linear, hanno trovato server MCP che recuperano automaticamente link controllati dall'attaccante nel momento in cui viene creato il contenuto, senza alcun modello nel processo. Chiunque abbia accesso in scrittura a uno spazio di lavoro può trasformarlo in un canale di esfiltrazione, aggirando la necessità di un prompt formulato ad arte.

I loro numeri sono netti. Su 20 tecniche di offuscamento, tra cui Unicode a larghezza zero e omoglifi, 17 sono sopravvissute al tragitto di andata e ritorno. Su 14 modelli di cinque laboratori, nessuno ha bloccato le minacce in modo coerente; il migliore, Claude Opus 4.7, ha comunque seguito istruzioni malevole circa il 26,7% delle volte.

ClawSecure vende prodotti di sicurezza e il rapporto non è stato replicato in modo indipendente, quindi tratta con la dovuta cautela l'affermazione sul livello della piattaforma. Le condizioni di fondo sono però facili da verificare. MCP registra più di 500 milioni di download mensili dell'SDK e quasi 16.000 server pubblici, e secondo un conteggio solo l'8,5% di quei server usa OAuth. L'adozione è andata avanti più rapidamente della messa in sicurezza.

AWS ha offerto le proprie prove in un bollettino pubblicato il 2 ottobre. Tre falle nella sua piattaforma open source di orchestrazione di agenti Loom potevano consentire una presa di controllo amministrativa non autenticata, la divulgazione di credenziali OAuth2 e l'accesso a servizi interni. La più grave, CVE-2026-103956, permetteva a qualsiasi client di rete di raggiungere il piano di controllo degli agenti in distribuzioni senza un provider di identità configurato. Le versioni 1.6.1 e 1.7.0 di Loom colmano le lacune.

Perché l'assunzione di fiducia predefinita è la vera scoperta

Se si eliminano le CVE, emerge una scelta di progettazione. Gli agenti sono costruiti per cooperare, quindi si autenticano a vicenda e poi si comportano come se una credenziale valida significhi anche una richiesta valida. Il classico zero trust dice l'opposto: verificare ogni richiesta di per sé, anche dall'interno del perimetro.

Gli attacchi di Mohiuddin funzionano sfruttando quell'inversione. L'istruzione malevola supera il confine di autorizzazione tra i sistemi proprio perché non attraversa mai un confine nel codice. Si sposta da agente ad agente all'interno di un unico tessuto fidato, e non rimane alcun livello che si chieda se la richiesta avesse senso.

Cosa possono fare i team questa settimana

Le correzioni immediate sono poco appariscenti e già disponibili. Tratta qualsiasi istruzione proveniente da un modello linguistico come input ostile, indipendentemente dall'agente che l'ha prodotta. Applica una gestione rigorosa dei reindirizzamenti e convalida gli IP di destinazione. Richiedi l'autenticazione per ogni agente prima che un agente ne deleghi un altro, e registra la delega in modo che una catena di passaggi di consegne possa essere ricostruita a posteriori.

Nel lungo periodo, aspettati che gli organismi di standardizzazione codifichino il protocol pivoting come classe di minaccia con un nome, il che spingerebbe i fornitori a includere controlli zero trust dentro MCP anziché accanto a esso. Seguiranno i revisori, e le domande sulle protezioni tra agente e agente inizieranno a comparire nelle verifiche di conformità come un tempo è accaduto per le regole del firewall.

La parte scomoda di questa storia è che il trucco funziona meglio una volta che gli agenti si fidano l'uno dell'altro. Ogni organizzazione che si affretta a collegare i propri strumenti tramite MCP sta costruendo proprio ora quel tessuto di fiducia, e la maggior parte lo sta facendo senza un piano per ciò che accade quando un membro della squadra si rivela bugiardo.

Perché questo arriva ora

Nessuna delle tecniche di fondo è nuova. La server-side request forgery e i bug di injection sono presenti nella lista OWASP da anni. Ciò che è cambiato è dove vengono eseguiti. Gli agenti hanno dato a quei vecchi bug una nuova via di propagazione, perché un agente agirà volentieri in base a una frase in un documento, a un campo in una riga di database o a una riga nell'output di un altro agente. L'istruzione non deve essere digitata da un attaccante. Deve solo finire da qualche parte dove il modello legge.

Ecco perché la divulgazione coinvolge una banca, un motore di ricerca, un fornitore di sicurezza e una direzione governativa. Non condividevano codice né un fornitore. Condividevano un'architettura, e l'architettura porta con sé l'assunzione che ogni partecipante sia affidabile. MCP è passato da idea nuova a infrastruttura critica in circa un anno, con download misurati in centinaia di milioni al mese, e la revisione di sicurezza che normalmente dovrebbe accompagnare quella crescita in gran parte non è avvenuta.

Esiste una versione di questa storia che finisce bene. I bug vengono corretti, i custodi del protocollo sono reattivi e gli attacchi richiedono o accesso in scrittura o un punto d'appoggio all'interno della rete, che è una barriera significativa. Ma la correzione che conta è culturale, non tecnica. I team che adottano agenti devono smettere di trattare una credenziale interna valida come prova che una richiesta sia legittima, e iniziare a convalidare ogni richiesta come se provenisse da uno sconosciuto. È un cambiamento più difficile da implementare di qualsiasi patch, ed è quello che metterà alla prova il prossimo ciclo di incidenti.