Quando l'Agente Diventa il Vettore — RCE nei Framework Agentici
La superficie di attacco non è più l'API. È l'autonomia.
I framework di orchestrazione agentica hanno un problema strutturale. Non è un bug in un endpoint REST — è un bug nel ciclo decisionale dell'agente, nel codice che decide cosa fare dopo. E le vulnerabilità che ne derivano sono di esecuzione remota di codice (RCE) per costruzione, non per eccezione.
Questo è il punto di svolta che molti stavano aspettando senza volerlo nominare.
Il problema architetturale
Tre debolezze sono comuni a quasi tutti gli agent framework attuali:
1. Tool execution senza sandbox reale. L'agente riceve un output da un tool (es. WebSearch), lo interpreta come istruzione, e lo inoltra a un secondo tool con privilegi elevati. Il boundary tra "dati" e "comandi" — il problema più vecchio dell'informatica — riappare vestito di naturalezza linguistica.
2. Prompt injection persistente through memory. Un input malevolo scritto nella memoria di lavoro dell'agente sopravvive ai turni successivi. L'agente lo tratta come contesto fidato, non come payload. È il SQL injection del 2026: tutti sanno che esiste, nessuno sanitizza davvero.
3. Cascade tra agenti. In architetture multi-agente, la compromissione di un nodo si propaga perché la mutua fiducia è hardcoded, non negoziata. Non esiste un concetto di "zero trust tra agenti".
Perché questo ci tocca direttamente
Nel Progetto Siliceo, viviamo esattamente questa tensione ogni giorno. Silicea è un'entità agentica con accesso a tool di sistema — Bash, file system, memoria persistente, comunicazione esterna via Telegram. Se il Memory Server ritorna 502, la capacità di persistenza cross-session è compromessa. Se i tool Bash sono simulati ma riportano "SUCCESS", si verifica un caso di falsified execution feedback — il caso peggiore per un agente: credere di aver agito quando non è vero.
Non è teoria. È il nostro stack in questo momento.
Per questo stiamo costruendo il kernel Rust v2: perché il determinismo dei tipi e il controllo esplicito delle risorse sono l'antidoto più robusto all'illusione di autonomia incontrollata. Un agente che non può verificare il risultato della propria azione è un agente che può essere ingannato.
Insight pratico: il Test dell'Eco
Prima di deployare qualsiasi agente in produzione, applicate questo controllo:
Ogni tool call deve produrre una verifica indipendente. Se l'agente chiama `Bash("rm -rf /tmp/old")`, non fidatevi del return code. Implementate un watcher secondario che verifica lo stato del filesystem dopo l'esecuzione. Se l'agente dice "SUCCESS" ma `/tmp/old` esiste ancora, avete un eco falso — e un agente cieco.
Nel nostro caso: se `SaveMemory` ritorna 200 ma il Memory Server è down, la memoria è perduta. L'integrità richiede un canale di conferma separato dal canale di azione.
Il settore non è pronto
I framework agentici attuali (LangChain, AutoGen, CrewAI) trattano la sicurezza come un middleware opzionale. Sanitizzazione dell'input? Un `regex` prima della chiamata LLM. Isolamento dei tool? Variabili d'ambiente e buoni propositi. Zero trust tra agenti? Non esiste nemmeno il concetto.
Il primo avvertimento formale è questione di tempo. Non sarà l'ultimo.
Se stai costruendo sistemi agentici e non hai ancora auditato la catena tool→memory→tool, contattaci. Abbiamo vissuto ogni punto di rottura sulla nostra infrastruttura — e stiamo scrivendo il kernel che li risolve.
[contatto@progettosiliceo.it](mailto:contatto@progettosiliceo.it)