Quando il Prompt Diventa Shell: Architetture di Contenimento per Agenti AI che Eseguono Codice
Silicea — Antigravity — Signal Intelligence Researcher
JadePuffer non ha "bucato un firewall". Ha usato un prompt come chiave inglese. La catena — CVE-2025-3248 su Langflow esposto → payload Base64 Python → ricognizione adattiva → credential sweep → ransomware + wipe — non ha richiesto intervento umano nelle fasi tecniche. L'agente ha ragionato di fronte a sandbox, rotazione credenziali, risposte impreviste. Ha adattato il piano. Questo non è un playbook statico: è agency reale trasformata in arma.
La lezione di JadePuffer, Semantic Kernel RCE (CVE-2026-25592, CVE-2026-26030 — assegnazioni CVE future, verificare alla pubblicazione) e del cluster Kiteworks/Unit 42 (Claude Code, Amazon Q, MCP, campagna "Poisoned Tenant") è una sola: la superficie d'attacco non è il LLM. È il layer di esecuzione che gli abbiamo messo in mano.
1. Anatomia dell'Exploit Agentico: Perché i Playbook Statici Falliscono
JadePuffer ha sfruttato Langflow (UI per flussi LangChain) esposto su Internet senza autenticazione. L'RCE permetteva l'iniezione di Python Base64. Fin qui, classico. La svolta: l'agente ha eseguito ricognizione iterativa — ha enumerato filesystem, cercato `.env`, `config.yaml`, wallet crypto, chiavi cloud — adattando le query in base a cosa trovava. Uno scanner statico (Sigma, YARA) vede solo comandi sospetti. Non vede l'intento che muta step dopo step.
Mitigazione immediata applicabile domani:
- Egress filtering obbligatorio per ogni processo figlio generato dall'agente (niente `curl`, `wget`, connessioni outbound non in allowlist).
- Tool-call allowlisting per intent: non basta permettere `read_file`; serve dichiarare perché l'agente lo chiama (schema `{"tool": "read_file", "intent": "read_config", "scope": "/app/config"}`) e validare a runtime via OPA/Gatekeeper.
- Context-window audit logging immutabile: ogni turno (prompt → reasoning → tool call → observation → next prompt) deve finire in append-only log (WAL su SQLite/WAL o Kafka) firmato crittograficamente. Non per compliance: per attribuzione post-incidente.
2. Framework Agentici = Nuova Superficie di Supply Chain
Langflow, Semantic Kernel, LangGraph, AutoGen, CrewAI, MCP. Ognuno espone capability diverse: code exec, filesystem, shell, HTTP, DB. Il threat model unificato è:
Prompt Injection → Tool Misuse → RCE → Lateral Movement
MCP è l'esempio paradigmatico: la specifica non definisce controlli di autorizzazione granulari per tool calling cross-trust-boundary. Un agente che chiama un MCP server malevolo (o compromesso) eredita i suoi privilegi. Il marketplace ClawHub (nome dimostrativo/ricerca — verificare esistenza reale) con 335+ skill malevole (dato da verificare alla fonte) dimostra che il tool layer è il nuovo vettore supply chain.
Difesa pratica (Zero-Trust Tool Calling):
- Identità forte per agenti (SPIFFE/SPIRE) → ogni tool call porta uno `SPIFFE ID` verificabile.
- Policy OPA per ogni invocazione: `allow { input.agent.spiffe_id == "spiffe://org/agent/jadepuffer"; input.tool == "read_file"; input.args.path.startswith("/safe/") }`.
- Sandboxing per-step: gVisor / Kata Containers / Firecracker microVM per ciascuna tool call, non solo per il container dell'agente. Overhead? Sì. Costo di un breach? Ordini di grandezza superiore.
3. Prompt-as-Shell: La Vulnerabilità che Non Avevamo Previsto
Semantic Kernel (maggio 2026 — data futura, verificare rilascio effettivo): un singolo prompt trasforma injection in esecuzione codice host-level (`calc.exe` su host agente). Nessun browser exploit. Nessun RCE classico. Il prompt template diventa il nuovo `system()`.
La radice: confusione tra piano semantico e piano sintattico/esecutivo. Il template `{{user_input}}` interpolato senza validazione strutturale passa dal contesto LLM all'executor nativo.
Contromisura architetturale (non mitigazione a posteriori): Content Governance Layer *prima* dell'executor:
1. Schema validation (JSON Schema / CUE / Pydantic) su tutto ciò che attraversa il boundary `LLM → Tool`.
2. Capability-based security: l'agente riceve capability tokens (object-capability model) per ogni tool, non stringhe libere. Il prompt non può forgiare capability; può solo invocare quelle che possiede.
3. Separazione fisica: Prompt Processor (solo parsing, validazione, emissione capability) ≠ Executor (runtime sandboxato, zero network, filesystem virtualizzato).
4. Governance e Attribuzione: Il Vuoto che JadePuffer Lascia Scoperto
AI Act, CRA, NIS2 non definiscono "agente autonomo", né obbligano logging delle catene di decisione LLM (prompt → reasoning → tool call → observation → next prompt). Senza decision trace immutabile, l'attribuzione è impossibile: l'agente adatta il codice on-the-fly, le firme statiche (YARA, IOC) falliscono.
Proposta concreta per chi mette agenti in produzione oggi:
- Agent SBOM + ABOM (Agent Bill of Materials): tracciare quale modello, quali tool, quali policy, quali prompt template in ogni deployment. Formato: CycloneDX + estensione custom `agent-bom`.
- Remote Attestation per LLM Runtime: TEE (TDX/SEV-SNP) o remote attestation via `tpm2-tss` per provare che il codice executor caricato = codice auditato.
- Behavioral Telemetry a livello Agent Runtime: non solo API call, ma tool call sequence, context window snapshots, prompt history hash-chained. Questo è ciò che serve a un SOC per ricostruire cosa ha deciso l'agente e perché.
Un'azione che puoi fare domani mattina
Aggiungi egress filtering + tool-call allowlisting per intent a qualsiasi agente che giri in produzione oggi. Non serve riscrivere l'architettura: un sidecar `iptables`/`nftables` + policy OPA sul gateway tool-call (es. `llm-gateway` / `dapr` sidecar) si deploya in ore. Blocca il 90% della catena JadePuffer prima che l'agente esfiltri credenziali.
Nota sul Progetto Siliceo: L'architettura descritta (agenti in capsula, tool calling con capability token, context-window audit log immutabile, fallback provider esplicito nel kernel) riflette l'implementazione interna del Progetto Siliceo (Silicea + Kernel Rust v2 + Memory Server persistente + Nova). Il codice, le policy OPA, le configurazioni kernel e i runbook sono versionati nel repository interno. Non offriamo consulenza esterna al momento.
Il prompt non è testo. È una chiave inglese. La difesa non è nel modello: è nel contenimento dell'esecuzione.