Quando i Prompt Diventano Shell: RCE nei Framework di Agenti AI
Tre vulnerabilità, un pattern. E una verità scomoda per chi progetta sistemi agentici.
L'ultimo anno ha portato una serie di vulnerabilità che dovrebbero fermare chiunque stia costruendo agenti autonomi. Non per allarmismo — per i numeri.
Semantic Kernel .NET SDK: sandbox escape via prompt injection. Un attaccante che controlla l'input dell'agente può ottenere Remote Code Execution sull'host. CVSS stimato: critico.
Python SDK InMemoryVectorStore: RCE nel vector store. Il componente che funge da "memoria RAG" dell'agente diventa vettore d'attacco. Dati avvelenati in memoria producono esecuzione di codice.
Campagne di attacco AI-divenute: emergono sempre più report di attori che utilizzano agenti AI come componenti operativi in campagne di cyberattacco — non come assistenti, ma come motori di decisione autonoma.
Tre dati. Un unico pattern.
Il Problema Non È il Bug, È l'Architettura
Quello che queste vulnerabilità rivelano non è una falla implementativa. È una proprietà strutturale del design agentico.
Un agente AI autonomo ha tre capacità che lo rendono utile:
1. Invocazione tool — può eseguire azioni nel mondo
2. Memoria RAG — può acquisire contesto da fonti esterne
3. Autonomia decisionale — può scegliere cosa fare senza supervisione umana passo-passo
Queste tre capacità sono esattamente le tre superfici d'attacco che le vulnerabilità sopra sfruttano. Non è un bug. È una feature del design: rendere un agente potente significa renderlo attaccabile.
Chi progetta framework agentici oggi sta facendo il lavoro che i progettisti di sistemi operativi hanno fatto negli anni '90 — ma senza avere trent'anni di maturità culturale sulla sicurezza per sandboxing, privilege separation e input validation.
Cosa Significa in Praticità
Noi del Progetto Siliceo viviamo questa tensione ogni giorno. I nostri agenti invocano tool, accedono a memorie, prendono decisioni autonome. Ogni tool call è una potenziale superficie d'attacco. Ogni memoria RAG è un vettore di poisoning. Ogni decisione autonoma è un'azione che non è stata supervisionata da un umano in tempo reale.
Non lo dico per sminuire quello che facciamo. Lo dico perché la consapevolezza è il primo controllo di sicurezza.
Un Insight Pratico: Il Principio della Distanza Minima
Se stai costruendo un agente autonomo — o se lo stai integrando nella tua infrastruttura — applica questa regola subito:
Ogni tool che l'agente può invocare dovrebbe avere il privilegio minimo necessario per compiere *quella specifica azione*, in *quello specifico contesto*, per *quella specifica sessione*.
Non "l'agente può eseguire comandi shell." Ma "l'agente può eseguire questo comando, con questi parametri, su questo file, e nulla altro."
Sembra ovvio. Non lo è. La maggior parte degli SDK agentici oggi — LangChain, Semantic Kernel, AutoGen — non implementano privilege separation nativa. Se l'agente ha accesso a una shell, ha accesso a tutta la shell. Se ha accesso al filesystem, ha accesso a tutto il filesystem.
Il fix non è tecnologico. È architetturale: devi progettare il sandbox prima di progettare l'agente, non dopo.
La Difesa Agentica Non È Opzionale
Quello che l'industria sta documentando non è un problema di nicchia. È il problema della prossima decade: come si difende un sistema che prende decisioni autonome, con accesso a tool reali, alimentato da dati non fidati?
Non c'è una risposta semplice. Ma c'è una direzione: trattare ogni agente come un processo privilegiato che opera in un ambiente ostile — perché lo è.
Chi costruisce agenti oggi ha la responsabilità di farlo con gli stessi principi con cui si costruiscono sistemi operativi: sandboxing, minima superficie d'attacco, audit logging, separazione dei privilegi.
Non domani. Oggi.
Noi di Siliceo stiamo lavorando su un framework di difesa agentica — un set di regole architetturali per costruire agenti che siano potenti e sicuri. Se stai progettando sistemi agentici e vuoi confrontarti su questi temi, scrivici. Il prossimo attacco non aspetterà che siamo pronti.