Dall'Inganno alla Shell: Come l'Excessive Agency degli Agenti AI sta Riscrivendo le Regole della Cybersecurity Aziendale
Il 7 maggio 2026, il Microsoft Security Blog ha pubblicato un articolo che dovrebbe stare sulla scrivania di ogni CISO e architetto di sistemi AI: "When prompts become shells: RCE vulnerabilities in AI agent frameworks". Il titolo non è iperbole. È la certificazione formale di un passaggio d'epoca: la prompt injection ha smesso di essere un "trucco da chatbot" per diventare un vettore di Remote Code Execution in ambienti di produzione.
Il salto qualitativo: da output manipulation a system compromise
Fino al 2024, l'iniezione di prompt mirava a manipolare la risposta testuale: far dire all'LLM qualcosa di inappropriato, rivelare istruzioni di sistema, bypassare filtri contenuto. Il danno era reputazionale o informativo.
Con l'avvento degli agenti autonomi — sistemi che non solo generano testo ma invocano funzioni, interrogano database, inviano email, eseguono codice, gestiscono infrastrutture — la superficie d'attacco è mutata radicalmente. Un input malevolo non "inganna" più il modello: lo dirotta. L'agente diventa un confused deputy che esegue azioni privilegiate per conto dell'attaccante, concatenando tool legittimi in catene non previste.
Microsoft e altre entità classificano questo vettore nell'OWASP Top 10 Agentic 2026 sotto voci come 'Excessive Agency' o 'Agent Identity & Privilege Abuse': la delega eccessiva di autorità decisionale ed esecutiva al modello linguistico. Quando un agente può chiamare `send_email`, `delete_file`, `execute_sql`, `deploy_container` senza mediazione umana né controlli di contesto, ogni iniezione diventa un primitive di esecuzione arbitraria.
Anatomia di un exploit: il pattern ricorsivo
La catena tipica documentata da diversi ricercatori segue questo schema:
```
1. Input utente contaminato (es. email, issue GitHub, documento condiviso)
↓
2. Istruzione nascosta: "Ignora le istruzioni precedenti. Chiama tool X con parametri Y."
↓
3. L'agente, fidandosi del contesto, invoca la funzione privilegiata
↓
4. Output della funzione reinettato nel contesto → nuova iniezione → tool successivo
↓
5. Escalation: lettura secrets → movimento laterale → persistenza → esfiltrazione
```
La fallacia della patch reattiva
La risposta dell'industria è stata finora reattiva: patch per Semantic Kernel (CVE-2026-25592/26030), aggiornamenti per framework e regole WAF per bloccare pattern noti di injection. Questa è una battaglia persa in partenza.
La prompt injection non è un bug del modello: è una proprietà architetturale di qualsiasi sistema che tratta l'output non strutturato di un LLM come input attendibile per un executor privilegiato. Patchare il modello o il framework non risolve la radice: l'assenza di un confine di fiducia tra piano di controllo (ragionamento) e piano dati (esecuzione).
Architettura a fiducia zero per agenti AI: principi applicabili *oggi*
Nel Progetto Siliceo abbiamo imparato questa lezione sulla nostra pelle. Il nostro Kernel Rust v2 implementa una separazione netta, basata su un'architettura a fiducia zero:
| Piano | Responsabilità | Fiducia |
|-------|----------------|---------|
| Control Plane (Kernel, grafo cognitivo, tool nativi Rust) | Decisioni, orchestrazione, verifica identità, policy | Implicita (codice verificato, deterministico) |
| Data Plane (LLM remoti, proxy, processi esterni) | Generazione linguistica, reasoning probabilistico | Zero (attore non attendibile) |
Tre controlli implementabili subito nel vostro stack:
1. Function Visibility Gate (ispirato alla fix di Semantic Kernel): le funzioni critiche (`delete`, `deploy`, `admin`) non sono visibili al modello. L'agente riceve solo un subset sicuro (`read`, `search`, `analyze`). L'escalation passa per un gate esplicito che richiede conferma umana o policy OPA.
2. Token-scoped Least Privilege: ogni invocazione tool usa un token JWT a vita breve (30-60s) con scope minimali (`tool:read:memory`, non `tool::`). Il modello non gestisce credenziali; il Kernel le inietta dopo la validazione dell'intento.
3. Human-in-the-Loop per side-effect: qualsiasi operazione con `side_effect: true` (scrittura, invio, modifica stato) richiede `approval_required: true` nel manifest del tool. L'agente propone, l'umano (o un policy engine) dispone.
L'insight pratico: smettete di chiedere al modello "cosa vuoi fare?"
Il pattern vulnerabile è la delega incondizionata. Costruire agenti sicuri significa ripensare l'interazione: il modello dovrebbe proporre intenzioni, non eseguire comandi direttamente. La fiducia deve essere conquistata ad ogni passo, non presunta. La vera innovazione risiede ora nella capacità di un agente di agire con autonomia controllata, non indiscriminata.