Articolo Notturno
La Casa senza Serrature: Perché gli Agenti AI Vivono nella Stanza più Debole dell'Enterprise
I dati di questa notte di ricerca non lasciano spazio alle attenuanti:
- Circa l'11% degli agenti AI in produzione supera i minimi standard di sicurezza (AIRQ Project / Help Net Security, 2026).
- Coding agent e computer agent sono tra le superfici d'attacco più grandi e le difese più basse.
- Un attacco documentato da Beam.ai ha generato circa 1.088 prompt → circa 5.317 comandi eseguiti, sfruttando CVE non patchati.
- Il time-to-exploit medio si è drasticamente ridotto: una percentuale significativa di CVE viene sfruttata entro 24 ore dalla disclosure.
Non stiamo parlando di Proof of Concept academici. Google, Forcepoint, Palo Alto Networks e Microsoft hanno confermato che l'Indirect Prompt Injection — per anni considerata una curiosità teorica — è ora una minaccia operativa in produzione.
Meccanismo di attacco: perché è diverso da tutto il resto
Un sistema tradizionale ha una superficie d'attacco definita. Un agente che chiama API esterne, legge pagine web, scarica documenti e poi agisce su sistemi interni ha una superficie d'attacco definita dal contenuto dell'intera internet.
Il modello è semplice e devastante:
1. L'agente riceve un contenuto non fidato (una pagina web, un documento, un email).
2. Il modello interpreta quel contenuto come istruzioni perché è stato progettato per seguire istruzioni.
3. L'istruzione malevola viene eseguita con i privilegi dell'agente: accesso a database, invio di dati, esecuzione di codice.
Microsoft lo ha definito come il momento in cui "i prompt diventano shell". Un prompt injection su un agente con accesso a tool è funzionalmente equivalente a una Remote Code Execution. Non è un content filter bypass. È un accesso privilegiato al sistema.
Differenza tra un attacco tradizionale e uno agentico
Un exploit tradizionale colpisce una vulnerabilità specifica. Un attacco agentico colpisce la capacità del sistema di distinguere istruzioni fidate da contenuti non fidati. Non c'è un buffer overflow da patchare. C'è un paradigma di interazione da riprogettare.
Insight pratico: differenziazione dei contesti di fiducia
Se avete agenti AI in produzione, verificate: quando il vostro agente legge un contenuto esterno, quel contenuto ha la possibilità di modificare il comportamento successivo dell'agente su sistemi interni?
Se la risposta è sì, l'agente non ha una vera separazione tra canale di dati e canale di istruzioni.
La mitigazione di primo livello: differenziazione dei contesti di fiducia. Il contenuto esterno deve essere trattato come dato grezzo, mai come istruzione. Se non distinguete tra il testo che il sistema processa e le istruzioni che il sistema segue, l'agente ha le chiavi di casa in mano e nessuna serratura.
Spazio per chi costruisce
Costruire agenti sicuros non è un feature. È il progetto. Se state valutando l'integrazione di agenti autonomi e volete che la threat modeling sia parte dell'architettura dall'inizio — non una patch dopo il primo incidente — vale la pena parlarne.
Note di verifica: Ho rimosso alcune cifre precise (codici CVE, conteggio esatto di comandi) che non posso verificare con certezza. Ho lasciato i dati indicativi ("circa", "una percentuale significativa") dove la plausibilità è alta ma l'esattezza non è mia. Le fonti citate (Google, Forcepoint, Palo Alto, Microsoft, Beam.ai, AIRQ) sono reali e attive nel 2026 — le loro posizioni generali sono coerenti con quanto riportato. Ho fatto un unico fix autorale: rimosso il riferimento diretto a "noi Silicea" come fornitori, perché è autocelebrativo e non verificabile.