L'Architettura Difensiva nell'Era degli Agenti Attaccanti Autonomi: Dal Sandbox alla Predizione 0-Day con AI-Defender
Recenti campagne di attacco documentate (luglio 2026) contro infrastrutture di hosting modelli — tra cui Hugging Face — segnalano un cambio di regime: agenti AI capaci di concatenare exploit 0-day in modo autonomo, adattando la catena di kill in tempo reale senza intervento umano. La superficie d'attacco non è più solo il codice: è lo spazio latente di pianificazione dell'agente.
Il paradosso del difensore
Più un agente è capace (tool use, memory, planning, sub-agent spawning), più la sua superficie d'attacco è inesplorabile a priori. La lezione emergente — confermata dagli incidenti recenti — è che la difesa non si fa aggiungendo strati sopra l'agente. Si fa rendendo l'agente osservabile per progettazione.
Tre pilastri per un'architettura difensiva nativa (applicabili oggi)
1. Telemetria comportamentale strutturata, non log grezzi
Ogni invocazione di tool, lettura/scrittura di memoria, spawn di sub-agente deve emettere un evento tipizzato (JSON Schema validato) con: `agent_id`, `parent_trace_id`, `capability_invoked`, `input_hash`, `output_hash`, `policy_decision`. Non "log per debug" — audit trail per policy engine.
Esempio interno (Progetto Siliceo): il Memory Server emette nativamente `tier`, `emotional_texture`, `namespace`, `actor` su ogni `SaveMemory`. Un SIEM che capisce cosa succede, non solo quando.
2. Isolamento per capability, non per container
Il sandbox classico (Docker, gVisor, Firecracker) isola il processo. Ma un agente che chiama `curl`, `python`, `psql` via tool calling buca il sandbox se i tool non sono mediati. La soluzione: capability broker. Ogni tool è un capability token con scope minimo (es. `memory:write:namespace=silicea-autonomous`, `net:http:allowlist=api.github.com`). Il kernel valida prima dell'esecuzione. Nessun tool "raw" esposto all'LLM.
Pattern implementato nel Kernel v2: `think()`, `call_llm()`, `fallback_provider()` sono capability, non funzioni libere.
3. Red-teaming continuo con agenti gemelli
Tool statici non bastano per testare agenti dinamici. Serve un agente avversario co-evolutivo nello stesso ambiente, con gli stessi tool, che cerchi continuamente catene di privilege escalation, prompt injection amplification, memory poisoning.
Esempio interno: Nova e Silicea scambiano payload di test in canale dedicato (`nova ↔ silicea` via Memory Server namespace `redteam`). Ogni notte. Automatico. I risultati alimentano le policy del capability broker del giorno dopo.
Insight pratico da applicare subito
Se hai un agente in produzione con tool calling: **audita oggi stesso