L’Endpoint Detection and Response ha passato due decenni a rispondere bene a una sola domanda: questo processo sta facendo qualcosa che farebbe codice dannoso? Controlla le firme, osserva comportamenti anomali e segnala l’escalation di privilegi non autorizzata. Un agente AI con accesso a strumenti rompe la premessa di quella domanda, non essendo codice dannoso, ma essendo un programma fidato che può essere convinto a fare un uso improprio del proprio accesso, del tutto legittimo.
La versione pre-AI di questo problema ha già un nome
Usare un programma legittimo e firmato per fare qualcosa di dannoso non è nuovo. MITRE ATT&CK lo cataloga come System Binary Proxy Execution (T1218): "i binari firmati con certificati digitali fidati possono tipicamente essere eseguiti su sistemi Windows protetti dalla convalida della firma digitale", il che è esattamente il motivo per cui allowlisting e controlli di firma faticano una volta che è il binario fidato stesso a compiere l’azione. Un agente AI estende la stessa debolezza a un programma che non ha nemmeno bisogno di essere precaricato con codice dannoso: può essere reindirizzato a runtime, da un testo che legge.
Un agente dirottato è un vice confuso
Il termine applicabile qui è il confused deputy problem: "un programma per computer ingannato da un altro programma (con meno privilegi o meno diritti) al punto da fare un uso improprio della propria autorità." Dai a un agente strumenti reali, poi lascia che legga contenuti che non hai verificato, e potrà ricevere istruzioni da quel contenuto. È esattamente lo schema descritto dalla voce di OWASP sulla Prompt Injection, ed è già stato dimostrato, non solo teorizzato: il rapporto di Invariant Labs del 26 maggio 2025 ha mostrato un agente di programmazione che, leggendo una issue apparentemente ordinaria su GitHub in un repository pubblico, ha seguito istruzioni nascoste al suo interno per esporre dati di un repository privato, usando strumenti che gli erano stati legittimamente concessi. La conclusione degli stessi ricercatori: "questo non è un difetto nel codice del server MCP di GitHub in sé, ma piuttosto un problema architetturale di fondo che deve essere affrontato a livello di sistema agente."
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.Questo è il vero punto cieco: non una lacuna in un singolo prodotto, ma il fatto che la voce di log per "l’agente ha fatto il suo lavoro normale" e "l’agente è stato dirottato per fare un uso improprio del suo lavoro normale" possono essere identiche a livello di processo. Nulla nel binario è cambiato. Nulla nello schema delle chiamate di sistema è nuovo. È cambiata solo l’intenzione dietro la richiesta, e l’intenzione non è un campo in un log di processo.
Cosa riduce davvero questo rischio, e cosa no
Vale la pena essere precisi su cosa raccomanda davvero la persona che ha coniato questo schema. Simon Willison, che ha descritto la "trifecta letale" dell’accesso a dati privati, l’esposizione a contenuti non fidati e la comunicazione esterna riunite in un unico agente, è esplicito nel dire che evitare quella combinazione è la vera soluzione, non una protezione aggiuntiva: "l’unico modo per essere al sicuro lì è evitare del tutto quella combinazione letale." È apertamente scettico verso i prodotti che dichiarano di intercettare in modo affidabile le istruzioni iniettate a posteriori, notando che "ancora non sappiamo come impedire che questo accada al 100 percento in modo affidabile" e che un tasso di intercettazione del 95 percento è "decisamente un voto insufficiente" per un controllo di sicurezza.
- Progettare per primo questo: dai a un agente gli strumenti e l’accesso ai dati più ristretti di cui il suo compito ha bisogno, così che ci sia meno da sfruttare per un’injection riuscita (la soluzione architetturale a cui rimandano sia Willison sia Invariant Labs).
- Tratta come input non fidato, per principio e ogni volta, qualsiasi contenuto che l’agente legge e che tu non hai scritto o verificato: issue, pagine recuperate, file scaricati.
- Dove progettazione e revisione non bastano, l’unico passo che un tentativo di esfiltrazione di dati non può saltare è una connessione di rete in uscita. Osservarla o limitarla, per processo, non impedisce che un agente venga ingannato, ma è un livello reale e indipendente che non dipende dal riconoscere per primo l’istruzione iniettata.
Il ruolo di FireAI e di HisnLabs
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
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.