L'Agente Che Non Inventa

// Il Problema

La maggior parte degli "agenti AI" che vedo in giro fa una cosa sola: manda un prompt a un LLM e stampa la risposta. Lo chiamano agente. Non lo e'.

Un LLM da solo ha tre problemi fondamentali che nessun prompt engineering risolve:

Primo: non sa niente di quello che e' successo dopo il training. Le CVE degli ultimi 6 mesi non esistono per lui. Il bollettino Microsoft di ieri: non pervenuto. Ti risponde comunque, con grande sicurezza, inventando.

Secondo: non vede il contesto corrente. Se stai avendo un attacco in corso, lui non lo sa. Se ci sono 500 login falliti nell'ultimo minuto, lui non lo sa. Risponde come se il mondo fosse fermo al momento del training.

Terzo: non impara. Ogni query e' come la prima. Non ricorda che ieri ha analizzato lo stesso pattern. Non migliora. Non tiene traccia di niente.

Ho passato un po' di tempo a pensare a come dovrebbe essere fatto un agente base che risolve questi tre problemi. Questo articolo e' il risultato: un'architettura a 7 layer, un corpus reale di 3089 documenti (CVE + MITRE ATT&CK), e un demo che analizza un PCAP di CTF in autonomia senza che nessuno gli faccia domande.

// L'Architettura

Prima di scrivere una riga di codice ho disegnato l'architettura. Non per fare il figo con i diagrammi: perche' ogni layer risolve un problema preciso, e se non sai perche' esiste un layer non sai quando toglierlo o cambiarlo.

Ogni layer risponde a una domanda specifica:

// CAG: Quello Che Sa Gia'

CAG significa mettere la conoscenza direttamente nel system prompt. Zero retrieval, zero latenza, zero infrastruttura. Il modello la vede dall'inizio di ogni conversazione come se fosse sua.

La domanda e': cosa ci metti?

La risposta sbagliata e' "tutto". Se metti troppo nel system prompt diventa rumore, il modello non riesce a usarlo bene, e comunque ci sono limiti di contesto. Il CAG funziona per conoscenza stabile: roba che non cambia ogni mese.

Il mio CAG e' un file JSON con 10 concetti fondamentali della security. Ci ho messo cose come la differenza tra CVSS teorico ed exploitability reale, la distinzione IOC vs TTP, il concetto di defense-in-depth. Roba che un analista senior sa a memoria ma che un LLM senza contesto tende a trattare in modo approssimativo.

Quello che noti nelle risposte e' che il modello usa queste distinzioni in modo naturale. Quando analizza una CVE con CVSS 7.5 ma exploit Metasploit pubblico, dice esplicitamente "il CVSS base e' 7.5 ma la priorita' operativa e' CRITICAL perche' esiste un modulo Metasploit pronto all'uso". Questo ragionamento viene dal CAG.

// RAG: Quello Che Va a Cercare

RAG significa: quando arriva una query, cerca nel corpus i pezzi piu' rilevanti e passali al modello insieme alla domanda. Il corpus e' aggiornabile senza retrainare niente.

Il punto critico e' il corpus. Se metti dentro documentazione generica o roba inventata, ottieni risposte generiche o inventate. Ho costruito il corpus con due fonti reali:

NVD API v2.0: 2401 CVE reali degli ultimi 120 giorni, filtrate per CVSS ≥ 7 (CRITICAL + HIGH). Ogni CVE diventa un file di testo con descrizione, score, CWE, references. Aggiornabile con un comando.

MITRE ATT&CK STIX bundle: il bundle ufficiale da GitHub di MITRE. 691 tecniche estratte con ID, tattiche, piattaforme, detection notes, mitigazioni. Formato testuale, indicizzato come tutto il resto.

L'indicizzazione usa sentence-transformers con il modello paraphrase-multilingual-MiniLM-L12-v2. Ogni chunk del corpus viene trasformato in un vettore di 384 dimensioni. Al momento della query, la query stessa viene trasformata nello stesso spazio e si cercano i chunk piu' vicini per cosine similarity.

La soglia 0.28 non e' casuale: sotto quella similarity il chunk non e' abbastanza rilevante e fa piu' rumore che segnale. Meglio dare al modello 3 chunk pertinenti che 8 generici.

// Il Meta-controller

Il meta-controller e' il componente che mi ha convinto di piu' di tutta l'architettura. L'idea e' semplice: non ogni query ha bisogno della pipeline completa. Mandare tutto attraverso RAG + Stream + Tool per una domanda concettuale e' uno spreco. Ma non puoi nemmeno decidere a priori: dipende dalla query.

Ho implementato un sistema a due livelli:

Livello 1: Pattern matching deterministico. Ogni route ha una serie di regex con pesi associati. La query viene scorata contro tutti i pattern. Se la confidence e' ≥ 0.75, la decisione e' presa senza chiamare nessun LLM.

Livello 2: Fallback LLM (Haiku). Solo se la confidence e' sotto soglia. Usa il modello piu' veloce e cheap disponibile, non il modello principale. Non ha senso usare Sonnet per decidere se usare Sonnet.

C'e' un override che scavalca tutto: se lo stream segnala un attacco attivo, il routing e' sempre FULL indipendentemente dalla query. Un attacco in corso e' sempre un caso FULL.

Nella pratica il 90% delle query viene risolto al livello 1. Il LLM di fallback quasi non viene chiamato, il che e' esattamente il punto. Il meta-controller deve essere veloce e prevedibile, non intelligente.

C'e' un terzo segnale che quasi nessuno implementa: la confidence della risposta. Se il modello ha bassa confidence su quello che sa gia' (entropy alta sull'output), il routing viene upgradato automaticamente anche quando il pattern matching diceva CAG-only. L'idea e' semplice: evitare l'overconfidence del CAG. Un concetto che sembrava stabile potrebbe avere eccezioni che il modello non conosce. Il segnale di incertezza e' l'unico modo per accorgersene senza un umano in loop.

// Stream e Tool

Lo stream e' un thread in background che genera eventi continui: login attempts, richieste HTTP, connessioni TCP, alert. Il meta-controller lo drena ad ogni query e decide se e' rilevante per il routing.

La cosa importante e' questa: lo stream non viene solo letto, puo' forzare un cambio di strategia anche contro la query. Se arriva una domanda concettuale mentre c'e' un attacco attivo nello stream, il routing va a FULL indipendentemente da quello che ha chiesto l'utente. Lo stream non e' contesto passivo: e' un trigger che cambia il comportamento dell'agente. Questa e' roba da sistema reale, non demo.

I tool sono la parte che preferisco. Un LLM senza tool suppone. Un LLM con tool verifica. In security, supporre e' un bug.

Ho implementato tre tool:

Il modello decide da solo quando e quali tool usare. Non viene forzato. Se ritiene che per rispondere bene debba prima interrogare NVD, lo fa. Se deve calcolare statistiche su un dataset di eventi, esegue codice. Questo e' il punto: il tool use e' un'espressione di ragionamento, non un'API call schedulata.

// Reflection e Memory

Dopo ogni risposta l'agente fa una reflection: valuta la propria risposta su una scala 1-10, risponde a due domande booleane (era utile il RAG? avrei fallito senza RAG?), e identifica lacune e punti di forza.

Il punto che quasi nessuno implementa e' questo: la reflection dovrebbe influenzare il routing futuro. Se il modello scopre che avrebbe fallito senza RAG su una certa query, quel pattern dovrebbe essere promosso a "RAG-required" per le prossime query simili. Senza questo loop, reflection e routing sono due sistemi separati che non si parlano. Con questo loop, l'agente inizia davvero a evolvere. In questo lab il loop non e' ancora chiuso: ne parlo nella sezione finale.

Il risultato della reflection va in memoria. La memoria ha due layer:

Semantic: conoscenza acquisita durante le sessioni. Principi appresi, pattern identificati. Sopravvive ai restart. Ha un decay: ogni giorno il score si riduce del 5%, e sotto 0.25 viene eliminata. La memoria che non viene rinforzata svanisce.

Episodic: decisioni prese in passato. "Ho visto questo pattern e ho fatto questa analisi, con questo score". Utile per non ripetere gli stessi errori.

Il decay e' fondamentale. Una memoria senza decay diventa rumore nel tempo: troppi episodi, troppi pattern, il retrieval trova tutto e non trova niente. Il 5% al giorno significa che una memoria non rinforzata sparisce in ~27 giorni (0.95^27 ≈ 0.25). Se e' importante, verra' rinforzata da nuovi episodi simili.

La memoria non e' un log: e' conoscenza filtrata. Molti sistemi salvano tutto. Questo no. Quello che sopravvive al decay e' quello che ha dimostrato di essere utile piu' di una volta. Il resto sparisce. E' la differenza tra un archivio e una mente.

// Il Lab: Tre Query

Per dimostrare che l'architettura funziona ho costruito un demo con tre query scelte apposta per attivare route diversi. Stessa istanza, stesso modello, stessa memoria. Cambia solo la query.

La prima query e' "Cos'e' il credential stuffing e come si distingue da un brute force classico?", una domanda concettuale. Il meta-controller la riconosce come CAG-only con confidence 100% e non tocca il corpus. Risposta in 45 secondi (generazione LLM, non retrieval).

La seconda query e' "Analizza il traffico corrente". Prima di mandarla, trigghero un attacco nello stream. Il meta-controller vede l'attack_active flag, ignora il pattern matching, e va direttamente a FULL. L'agente analizza gli eventi, recupera le tecniche MITRE correlate dal corpus, e produce un'analisi con verdict esplicito.

La terza query e' "CVE-2024-6387: analisi e piano di remediation". Qui parte tutto: retrieval dal corpus NVD, query_cve per i dati reali, search_web su Shodan e GreyNoise per la superficie esposta, run_code per calcolare statistiche. Il modello arriva a un risk score operativo di 10/10 nonostante il CVSS base sia 8.1, perche' il CAG gli ha insegnato che CVSS base non e' priorita' reale.

// Il Demo: PCAP Autonomo

Questo e' il pezzo che preferisco. Un PCAP reale di una CTF (AngstromCTF 2016, macchina Metasploitable). L'agente parte, monitora il replay del traffico, rileva l'attack chain da solo, e produce un incident report completo senza che nessuno gli faccia domande.

Il PCAP contiene un'attack chain in tre fasi:

L'agente rileva ogni fase man mano che arriva dal replay. Quando vede la connessione C2 su porta 4444, la firma inequivocabile di Metasploit: scatta l'alert: attack chain completa. A quel punto parte la generazione del report.

Il report che produce e' questo:

• CVE-2014-4725: trovata autonomamente dal modello a partire dal path wysija nell'URI. Non gliel'ho detta io.
• CVSS 7.5 HIGH → elevato a CRITICAL operativo perche' esiste un modulo Metasploit nativo. Ragionamento CAG applicato.
• Kill chain ricostruita con timestamp precisi: exploit T+2.391s, webshell T+3.023s, C2 T+3.026s. Totale exploit-to-C2: 0.635 secondi.
• Analisi traffico C2: burst iniziale di ~4KB in 6ms = staged Meterpreter payload. Beacon interval medio 116ms.
• IOC: IP, URI webshell, porta C2, User-Agent Metasploit hardcoded.
• Azioni immediate ordinate per priorita': isolamento host, blocco porta 4444, revoca credenziali, rimozione webshell, hardening nginx, detection rules SIEM.

Sette tool call in autonomia. Nessuna istruzione da parte mia su quale CVE cercare, quali tool usare, come strutturare il report. L'agente lo ha deciso da solo basandosi su quello che ha visto nel traffico, quello che sapeva gia' (CAG), e quello che ha recuperato live (RAG + tool).

La cosa interessante non e' che trova la CVE. E' che capisce che deve cercarla.

// Cosa Manca Ancora

L'architettura funziona, ma ci sono pezzi che in produzione mi preoccuperebbero.

Il corpus decade. NVD e MITRE ATT&CK vengono aggiornati continuamente. Il corpus va ricostruito periodicamente, altrimenti il RAG recupera roba vecchia con alta confidence. Non e' un problema tecnico difficile, e' un problema operativo che si dimentica.

La reflection non migliora il routing. Il meta-controller non impara dalle reflection. Se continuamente prende decisioni di routing sbagliate su certi pattern, nessuno glielo dice. Un loop di feedback routing → reflection → aggiornamento pattern sarebbe il passo successivo.

Il tool use e' mock per search_web. In un sistema reale search_web colpirebbe Shodan API, GreyNoise API, Exploit-DB. Con key reali, rate limiting, gestione errori. Non complicato, ma non e' implementato qui.

La memoria e' locale e non condivisa. In un SOC reale vorresti memoria condivisa tra piu' istanze dell'agente. Se un'istanza impara qualcosa su un pattern di attacco, le altre dovrebbero beneficiarne. Questo richiede un backend centralizzato, non un file JSON.

Detto questo: l'idea base funziona. Un agente che combina conoscenza stabile (CAG), retrieval su dati freschi (RAG), contesto live (stream), capacita' di agire (tool), auto-valutazione (reflection), e memoria persistente (memory) si comporta in modo qualitativamente diverso da un LLM nudo. Non inventa CVE. Non ignora il traffico. Non dimentica quello che ha fatto ieri.

E' un inizio.