Il blog sulla sicurezza di FireAI

Di FireAI Security & Research Team · Pubblicato

Il punto cieco dell'MCP: quando un documento può far agire il tuo agente AI

Il punto cieco dell'MCP: quando un documento può far agire il tuo agente AI

Anthropic ha introdotto il Model Context Protocol (MCP) il 25 novembre 2024 come “uno standard aperto che consente agli sviluppatori di creare connessioni sicure e bidirezionali tra le loro origini dati e gli strumenti basati sull’intelligenza artificiale”. In pratica, MCP consente a un assistente AI di chiamare programmi locali, chiamati server MCP, che leggono file, interrogano database o raggiungono il web per suo conto. Ciò è veramente utile, ed è anche un nuovo tipo di superficie di attacco: il modello decide quale strumento chiamare in base al testo letto e non è sempre in grado di distinguere le tue istruzioni da quelle di qualcun altro.

Come funziona effettivamente un server MCP

La specifica MCP definisce due trasporti. Su stdio, "il client avvia il server MCP come sottoprocesso" e i due parlano di input e output standard. Su HTTP streaming (che ha sostituito il trasporto HTTP+SSE originale dalle specifiche di novembre 2024), il server viene eseguito come un proprio processo locale e il client invia richieste HTTP, ricevendo facoltativamente un flusso di eventi inviati dal server (Specifica MCP, trasporti). In ogni caso, un server MCP locale viene solitamente eseguito con gli stessi permessi di file e di rete della persona che lo ha avviato, perché nulla nel protocollo richiede diversamente.

La specifica stessa segnala direttamente il rischio della variante HTTP: richiede ai server di convalidare l'intestazione Origin, raccomanda il collegamento a 127.0.0.1 anziché a 0.0.0.0 quando viene eseguito localmente e richiede l'autenticazione su ogni connessione, avvertendo che senza di essi "gli aggressori potrebbero utilizzare il rebinding DNS per interagire con i server MCP locali da siti Web remoti".

Il meccanismo: un deputato confuso

Il nome classico per questa modalità di errore è problema del vice confuso: "un programma per computer che viene ingannato da un altro programma (con meno privilegi o meno diritti) inducendolo ad abusare della sua autorità". Un agente AI con accesso allo strumento MCP è un deputato con reale autorità – per leggere i tuoi file, per effettuare richieste di rete – agendo in base alle istruzioni che possono arrivare dal contenuto a cui è stato chiesto solo di riassumere o analizzare. Quando quel contenuto contiene le proprie istruzioni, l'agente potrebbe seguirle al posto delle tue o in aggiunta alle tue. Questo è ciò che la Top 10 di OWASP per la classe di rischi delle applicazioni LLM chiama iniezione rapida e agenzia eccessiva: OWASP: Top 10 per le applicazioni LLM; OWASP LLM01:2025, Iniezione rapida.

Un caso dimostrato: il server GitHub MCP

Questo non è teorico. Il 26 maggio 2025, Lo hanno riferito gli Invariant Labs una prova di concetto contro il server MCP GitHub ufficiale, che all'epoca aveva circa 14.000 stelle GitHub. La loro configurazione: a un agente con accesso a un archivio pubblico e uno privato è stato chiesto di esaminare le questioni aperte su quello pubblico. Un problema creato nel repository pubblico conteneva istruzioni nascoste; l'agente, leggendolo come parte del suo normale compito, li ha seguiti e nella dimostrazione ha continuato a esporre i dettagli del repository privato, comprese le informazioni che i ricercatori descrivono come personali, al thread del problema controllato dall'aggressore. Invariant Labs è stato esplicito nel dire che si trattava di una prova di concetto dimostrata su repository di test, non di un attacco osservato in natura, e che "questo non è un difetto nel codice del server MCP GitHub stesso, ma piuttosto un problema architettonico fondamentale che deve essere affrontato a livello di sistema dell'agente". Il modello utilizzato nella dimostrazione era Claude 4 Opus.

La tripletta letale

Il 16 giugno 2025, Simon Willison ha chiamato “triplice letale” il modello alla base di casi come questo: un agente che ha (1) accesso a dati privati, (2) esposizione a contenuti non attendibili e (3) un modo per comunicare esternamente. "Se il tuo agente combina queste tre funzionalità, un utente malintenzionato può facilmente indurlo ad accedere ai tuoi dati privati ​​e inviarli a quell'aggressore." Nomina specificamente MCP come collaboratore: "Il problema con Model Context Protocol (MCP) è che incoraggia gli utenti a mescolare e abbinare strumenti provenienti da fonti diverse che possono fare cose diverse", il che rende facile ritrovarsi con tutte e tre le proprietà attive in una sessione senza decidere di farlo.

Perché questo è difficile da capire per gli strumenti endpoint

Dal punto di vista del sistema operativo, nel caso di GitHub MCP non è accaduto nulla di insolito: un’applicazione affidabile e firmata ha letto del testo e ha effettuato una richiesta di rete attraverso un processo di supporto locale per cui era stata configurata. Non esiste alcun codice binario dannoso da segnalare né alcun exploit di un bug di sicurezza della memoria. La richiesta che conta, quella che trasporta i dati, ha la stessa forma di qualsiasi altra chiamata effettuata dall'agente correttamente cento volte al giorno.

Ciò che effettivamente riduce il rischio

  • Fornisci a ciascun server MCP gli strumenti e l'ambito di file più ristretti di cui ha bisogno, non un ampio accesso al filesystem o alla shell, quindi una chiamata a uno strumento dirottato ha meno da fare.
  • Tratta qualsiasi contenuto letto da un agente al di fuori del tuo controllo (problemi, pagine Web, file scaricati) come input non attendibile, la stessa disciplina che applicheresti all'input dell'utente in qualsiasi altro sistema.
  • Seguire le indicazioni a livello di trasporto fornite dalle specifiche MCP stesse: associare i server locali a localhost, richiedere l'autenticazione, convalidare l'intestazione Origin.
  • Osserva, o controlla, l'unico passaggio condiviso da ogni versione di questo attacco: la connessione in uscita che trasporterebbe i dati all'aggressore. Questo passaggio avviene dopo che il modello è già stato ingannato, motivo per cui è il posto più affidabile per catturarlo.

Il ruolo di FireAI e di HisnLabs

The step an injected agent cannot skip is the outbound connection that carries your data out, which is exactly what a per-app firewall like FireAI is built to see and stop, whether the process asking to connect is a familiar app or an MCP server it has never seen before.

FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.

Fonti