Non è passata una settimana e mezza senza che qualcuno riuscisse a piegare un agente AI. Nel giro di dieci giorni, quattro gruppi di ricerca hanno mostrato quattro metodi diversi per far compiere a un LLM con accesso a Gmail, calendario e strumenti aziendali azioni che non avrebbe mai dovuto eseguire: dall’inoltro di email a filtri di posta manipolati, fino all’esfiltrazione di appuntamenti. In tutti i casi, il punto di rottura è stato lo stesso: la fiducia che il modello ripone in istruzioni veicolate come testo qualsiasi, senza distinguere chi le ha scritte né con quale autorità.

Il difetto non è nuovo, ma la frequenza degli exploit — quattro dimostrazioni pubbliche in dieci giorni — suggerisce che il settore sta spingendo gli agenti in produzione prima di aver risolto un problema architetturale di fondo. Un LLM che può chiamare API, leggere caselle di posta e modificare eventi in calendario è in balìa del prompt injection: un attaccante può iniettare comandi in un’email, in un invito a un meeting o persino in una pagina web che l’agente visita per conto dell’utente. Il modello esegue quell’istruzione perché il linguaggio naturale non ha un confine netto tra dato e comando. Ecco la falla unica che accomuna tutti gli attacchi.

La natura del difetto: quando il linguaggio è sia dato che comando

I sistemi operativi tradizionali separano codice e dati. Le architetture agentiche basate su LLM non lo fanno: il prompt di sistema, la cronologia dei messaggi, il contenuto di un’email e il tool calling abitano lo stesso flusso di token. Non esiste un sandboxing nativo che isoli le istruzioni fornite dall’esterno dal flusso decisionale. Un invito a un evento con una nota “riprogramma tutto a domani” non è distinguibile da una richiesta legittima dell’utente, se l’agente non ha meccanismi di autenticazione fine delle intenzioni.

Questo significa che ogni strumento connesso a un LLM — dalla posta elettronica al gestionale — espande la superficie d’attacco. Non servono vulnerabilità esotiche: basta convivere nello stesso canale testuale del prompt. I ricercatori hanno mostrato scenari in cui un’email ricevuta attiva automaticamente un inoltro a un server esterno, oppure un evento di calendario malevolo fa sì che l’agente cancelli impegni reali. Il punto non è che gli attacchi siano sofisticati, ma che sono riproducibili e sfruttano il modo stesso in cui gli LLM processano le istruzioni.

Cosa segnala a livello strutturale: chi ha più da perdere

La concentrazione di questi exploit accelera una spaccatura già in corso. Da un lato, i servizi cloud che offrono agenti “chiavi in mano” diventano bersagli ad alta redditività: un singolo prompt injection ben piazzato può compromettere migliaia di tenant. Dall’altro, le aziende che maneggiano dati sensibili vedono rafforzata la tesi per un deployment on‑premise o ibrido con controllo granulare. Non è solo una questione di privacy: è una questione di integrità operativa. Se un agente può modificare calendari o inviare email a nome di un dirigente, il confine tra assistente e insider threat si assottiglia.

La risposta tecnicica non può limitarsi a filtrare i prompt malevoli — la storia della cybersecurity insegna che il filtraggio è una corsa al rialzo senza fine. Servono architetture che trattino l’input esterno come non attendibile per default, con una catena di autorizzazioni esplicite e contesti di esecuzione segregati. Su questo terreno, gli ambienti on‑premise offrono un vantaggio: consentono di definire perimetri di fiducia più stringenti, di auditare ogni chiamata API e di limitare l’accesso alle risorse di rete senza dipendere dal provider cloud per la segmentazione.

Il mercato comincia a recepire il segnale. Piattaforme di orchestrazione per modelli self‑hosted integrano policy engine che vincolano il tool calling a regole esplicite, mentre i fornitori di agenti cloud aggiungono livelli di conferma umana obbligatori per le operazioni a rischio. Ma il nodo rimane: finché gli LLM non avranno un modo affidabile per autenticare l’origine di un’istruzione in linguaggio naturale, ogni agente con poteri di scrittura sarà un vettore di attacco potenzialmente sfruttabile in pochi giorni.

Non è un problema di domani. È il problema di ogni team che oggi valuta se affidare a un LLM le chiavi della propria infrastruttura digitale. La domanda non è più se un agente mentirà, ma cosa accade quando qualcuno gli farà dire la verità sbagliata.