Da sempre il mio mantra è che per saper difendere bisogna saper attaccare. Lo insegnavo sul tatami, e lo ritrovo ogni giorno nel mondo della cybersecurity. Ho sempre creduto nella collaborazione tra red e blue team, prima ancora che qualcuno gli desse un nome: purple teaming.
Qualche mese fa, spinto dalla curiosità e dalla frustrazione di vedere l’AI venduta come la soluzione definitiva a ogni problema del SOC, ho deciso di smettere di ascoltare e iniziare a fare. Ho avviato un esperimento pratico: costruire un laboratorio dove agenti AI autonomi lavorano insieme, ognuno con un ruolo preciso, per capire fino a dove queste tecnologie possano essere spinte e quanto lontano possano portarci.
Non un progetto accademico, non una demo per un webinar. Un banco di prova reale, costruito nel tempo libero, con hardware accessibile e software open-source. Questo articolo è il racconto di quel percorso, gli errori, le scoperte, le notti perse a debuggare timeout e le mattine in cui il sistema ha fatto qualcosa che non mi aspettavo. Nel bene e nel male.
L’Idea: Purple Teaming con Agenti Autonomi
L’idea di partenza era semplice: replicare la struttura di un SOC reale con agenti AI specializzati. In un SOC hai l’analista di triage, il threat hunter, il coordinatore, il responsabile della comunicazione. Ognuno con competenze diverse, tutti orientati allo stesso obiettivo. Perché non fare lo stesso con degli agenti?
Ho scelto nomi dall’universo Marvel, non per gioco, ma perché ogni personaggio incarna esattamente le qualità che volevo nel rispettivo agente.
J.A.R.V.I.S. è l’ethical hacker, l’agente Red Team. Chi conosce l’MCU sa che JARVIS è l’unica AI che riesce a nascondersi da Ultron, sopravvivere e rinascere. Indipendenza, astuzia, adattabilità, esattamente le qualità che vuoi in chi simula un attaccante.
F.R.I.D.A.Y. è il difensore, l’analista Blue Team. Tony la chiama in campo quando la minaccia è di livello Hulk. Risposta rapida, capacità di reggere la pressione quando tutto si muove in fretta. Il suo compito è l’analisi Blue Team nel paradigma MCP: correlare gli alert già classificati, arricchirli di contesto e supportare la risposta agli incidenti.
E.D.I.T.H. è l’evoluzione finale, l’orchestratrice. Lo scudo definitivo. Coordina gli altri agenti, valuta, ha l’occhio di falco sulla situazione e trasforma il caos in decisioni strategiche. È il SOC Manager digitale.
P.E.P.P.E.R. è il quarto agente, quello che non combatte ma comunica. Monitora i feed di threat intelligence e li trasforma in contenuti per il blog e i social. È l’agente più maturo del progetto, e il primo ad aver prodotto output pubblicamente verificabile.
V.E.R.O.N.I.C.A. è l’analista di Tier-1, il motore di triage automatizzato. Nell’MCU, Veronica è il sistema di supporto orbitale che Tony e Bruce costruiscono per gestire le situazioni che richiedono forza controllata, il deposito che consegna l’armatura Hulkbuster quando serve. Nel mio lab è l’agente che regge il volume di alert: a differenza degli altri, non gira sullo stesso stack: è costruita su Claude Code usato come orchestratore agentico, ma puntato sull’inferenza locale (il loop di tool-use lo guida Claude Code, il modello gira sul mio hardware, nessun dato esce dal perimetro). Processa gli alert in arrivo, li classifica come falsi positivi o minacce reali e archivia i casi per costruire una base storica.
La struttura è modulare: ogni agente è indipendente, con il proprio modello, il proprio prompt e i propri strumenti. Se domani esce un modello migliore, posso sostituire il “cervello” di un singolo agente senza toccare gli altri.
Dalla Teoria alla Pratica: Il Primo Impatto con la Realtà
Le prime settimane sono state un bagno di umiltà. La distanza tra “l’AI che funziona nella demo del vendor” e “l’AI che funziona con i tuoi dati, nel tuo ambiente, alle 3 di notte” è un abisso.
F.R.I.D.A.Y. è stata la prima ad essere messa alla prova. L’ho collegata al SIEM via API e le ho dato in pasto gli alert reali. I primi risultati sugli alert accumulati in tre giorni sono stati illuminanti, nel senso che hanno illuminato tutto ciò che non funzionava.
Far parlare un LLM con un SIEM via API non è magia, è ingegneria. Autenticazione JWT, JSON parsing, gestione dei timeout, contesto limitato. Il diavolo è nei dettagli, come sempre. Un token JWT scaduto alle 2 di notte significa che il tuo agente smette di funzionare e nessuno se ne accorge fino alla mattina dopo. Un timeout non gestito significa che il processo resta appeso e blocca tutta la coda degli alert successivi.
Ma i problemi più grossi non erano infrastrutturali. Erano nel modello stesso.
Gli Errori che Mi Hanno Insegnato Tutto
Il modello troppo piccolo
La prima versione degli agenti girava su un modello da 4 miliardi di parametri. La logica era: piccolo, veloce, efficiente. Il risultato: loop infiniti. L’agente riceveva un task multi-step, partiva bene, poi si perdeva in un ciclo dove ripeteva le stesse azioni all’infinito senza mai arrivare a una conclusione.
Sono passato a un 9B, meglio, ma ancora impreciso. Seguiva le istruzioni a metà, si inventava output dove gli pareva, e aveva una tendenza sistematica a ignorare le regole del prompt che avevo scritto con cura. Un giorno gli ho detto “MAI aprire con Ciao a tutti” e lui ha aperto con “Ciao a tutti!”. Un altro giorno gli ho detto “scrivi SOLO il post LinkedIn, niente tabelle” e lui mi ha mandato prima la tabella di analisi e poi il post. Il 9B capiva le parole del prompt ma non ne rispettava lo spirito.
Il vero salto è arrivato con un modello MoE (Mixture of Experts) da 35B parametri, 35 miliardi totali ma solo 3 miliardi attivi per ogni token generato. In pratica: la qualità di un modello grande con la velocità di uno piccolo, e entra nella VRAM di una GPU consumer da 16GB nella versione quantizzata. La prima volta che l’ho testato, la differenza è stata immediata. Rispettava le regole. Scriveva in italiano senza scivolare in inglese. Non inventava CVE. Il tono era professionale. Non è stata un’evoluzione, è stato un salto generazionale.
Ma anche la scelta della quantizzazione è stata una lezione. Ho provato la versione F16 del modello, 18GB, che sulla mia GPU da 16GB causava offloading sulla RAM di sistema: l’inference che prima richiedeva secondi ne richiedeva minuti, e i cron rischiavano il timeout. È stato un test deliberato, concluso in poco tempo, ma mi è costato qualche sessione e mi ha ricordato quanto la quantizzazione incida sulle performance reali, ben più di quanto si creda guardando solo i benchmark. Da allora verifico sempre quale quantizzazione è attiva prima di mettere un agente in esercizio.
Le allucinazioni nella cybersecurity sono pericolose
Il secondo errore è stato sottovalutare le allucinazioni. In una conversazione casuale, se l’AI inventa un dettaglio, è un fastidio. In cybersecurity, se inventa un CVE ID completo di descrizione e punteggio CVSS, il danno è operativo. P.E.P.P.E.R., nei primi test, lo faceva sistematicamente. Creava CVE plausibili che non esistevano, li inseriva nei bollettini con totale sicurezza, e ci volevano ore per verificare e scoprire che erano inventati.
La soluzione è stata un approccio a più livelli. Temperatura del modello bassa (0.3) per ridurre la creatività. Regole esplicite nel prompt: “MAI inventare CVE ID, hash, nomi malware, gruppi threat actor. Ogni affermazione deve avere una fonte. Senza fonte, non scriverla.” E soprattutto: script deterministici per la raccolta dati, il modello non raccoglie dati, li sintetizza. La raccolta la fanno script Node.js che interrogano API con risultati verificabili. Il modello interviene solo nella fase di scrittura, dove il suo talento è reale.
Il context overflow
Il terzo errore è stato il context overflow, il limite di testo che un modello può processare in una singola richiesta. Quando carichi il prompt di sistema, la documentazione, la knowledge base, la memoria dell’agente e l’alert da analizzare, sfori rapidamente il limite. Il modello smette di funzionare o perde informazioni critiche.
Ho ridotto il footprint del workspace di ogni agente del 70-90%. File di configurazione compattati al minimo essenziale. Memoria separata in statica (identity, infrastruttura) e volatile (eventi recenti). È un lavoro oscuro, ma senza di esso niente funziona.
I modelli non conoscono il tuo SIEM
Nessuno dei modelli che ho testato, e ne ho testati diversi, sapeva cosa significa una regola specifica del SIEM. Rispondevano con informazioni inventate o generiche. Ho verificato con test strutturati: domande precise sulle regole, diverse quantizzazioni dello stesso modello. Tutti fallivano. La soluzione: RAG, tool calling verso l’API del SIEM, e un cheat-sheet delle regole più comuni nel prompt. Non aspettatevi che il modello “sappia” qualcosa sul vostro stack, deve avere gli strumenti per cercarlo.
P.E.P.P.E.R.: L’Agente che Ha Funzionato per Prima
Il momento in cui il progetto è passato da esperimento a qualcosa di concreto è stato quando P.E.P.P.E.R. ha pubblicato il suo primo bollettino su questo Blog. Raccolto dai feed RSS, arricchito con dati da una piattaforma di threat intelligence, scritto dall’agente e revisionato da me prima della pubblicazione.
Il flusso oggi è completamente autonomo: raccolta dati da 21 feed RSS ogni 6 ore, query alla piattaforma CTI ogni 4 ore, compattazione giornaliera delle notizie più importanti alle 6 di mattina, e ogni lunedì alle 8 generazione del bollettino settimanale con pubblicazione automatica come bozza sul blog.
Ma arrivarci ha richiesto tante iterazioni. Le prime versioni producevano bollettini pieni di dati inventati, con titoli da comunicato stampa e un tono che oscillava tra il panico e l’irrilevanza. P.E.P.P.E.R. apriva con “Ciao a tutti!” nonostante il prompt dicesse esplicitamente di non farlo. Includeva dettagli interni dell’infrastruttura del lab nei bollettini pubblici. Ripeteva le stesse notizie da un giorno all’altro. Inventava CVE.
Ogni problema è diventato una regola nel prompt. Ogni regola ha reso l’agente un po’ più affidabile. Oggi il bollettino settimanale copre le top notizie della settimana con fonti citate, una sezione ransomware con vittime confermate, una sezione vulnerabilità Italia con alert CSIRT/CERT-GARR, e una prospettiva editoriale. I dati sono reali, le fonti verificate, e ogni settimana il formato migliora.
Il processo di miglioramento è stato guidato dal confronto con bollettini professionali, ho analizzato come lavorano i team CTI strutturati e ho identificato cosa mancava al mio output: date precise per ogni notizia, CVE con CVSS quando disponibili, dettaglio tecnico sui meccanismi di attacco, contesto geopolitico. Ogni lacuna è diventata un’istruzione nel prompt o un filtro nello script di raccolta dati. Il risultato non è ancora al livello di un team di analisti dedicati, ma per un sistema autonomo che richiede solo la mia revisione prima della pubblicazione, è un traguardo significativo.
Un momento chiave è stato quando ho confrontato un bollettino di P.E.P.P.E.R. con le CVE citate nelle fonti originali e ho scoperto che alcune informazioni erano errate, non inventate, ma riportate con dettagli sbagliati. Un “sfruttamento attivo confermato” che in realtà era solo un PoC pubblico. Una “patch disponibile” che in realtà era solo una mitigazione temporanea. Da quel giorno, ogni bollettino passa per un fact-checking delle CVE prima della pubblicazione. È un passaggio manuale che non ho ancora automatizzato, ma che ha alzato enormemente la credibilità del contenuto.
La lezione più importante con P.E.P.P.E.R. è stata questa: il valore non sta nel modello, sta nel sistema che ci costruisci attorno. Gli script di raccolta dati. I filtri di qualità che scartano i report AI-generated di bassa qualità dalla piattaforma CTI. Le regole anti-allucinazione nel prompt. Il flusso di revisione umana prima della pubblicazione. Il modello è un componente, importante, ma non sufficiente.
Il Triage: V.E.R.O.N.I.C.A., F.R.I.D.A.Y. e la Sfida Ancora Aperta
Il triage degli alert è la parte più critica del SOC, e quella dove gli errori hanno conseguenze reali. Qui lavorano due agenti complementari. V.E.R.O.N.I.C.A. è il motore di prima linea: processa il volume di alert, applica le regole di soppressione del rumore e classifica ogni evento. F.R.I.D.A.Y. è l’analista Blue Team che opera nel paradigma MCP, riceve i webhook e porta avanti l’analisi più strutturata. Entrambe propongono, non decidono.
La scelta di costruire V.E.R.O.N.I.C.A. su Claude Code non è stata casuale. Il triage non è un compito di scrittura, è un compito agentico: leggi un alert, interroghi il SIEM, correli con eventi passati, decidi il prossimo passo, ripeti. Claude Code è nato esattamente per questo loop di tool-use iterativo, e usarlo come orchestratore, puntato però sull’inferenza locale e non su API esterne, mi ha dato un agente molto più disciplinato nel seguire una procedura investigativa rispetto ai miei tentativi precedenti. Gira come daemon con un’architettura a due processi, un listener e un runner separati con separazione dei privilegi: il componente che riceve gli input e quello che esegue le azioni non condividono lo stesso livello di accesso. È una precauzione banale nel mondo dei servizi di rete, ma che in troppi progetti AI viene dimenticata. Il risultato concreto: una riduzione del carico di triage manuale nell’ordine del 90%, con i casi validati archiviati per costruire la base storica che servirà al fine-tuning.
Il modello operativo che ho scelto è a tre livelli di revisione: l’agente propone, E.D.I.T.H. valida, io approvo. Nessuna azione viene eseguita automaticamente. Non per sfiducia nella tecnologia, ma perché la responsabilità delle decisioni di sicurezza è e resta umana. Un falso negativo, un’attività malevola classificata come benigna, potrebbe avere conseguenze che nessun prompt engineering può giustificare.
La sfida attuale è il tempo di risposta. Un’analisi che dovrebbe richiedere 30 secondi a volte ne richiede 5 minuti, perché l’agente usa troppi strumenti in sequenza. Stiamo lavorando su un sistema di “budget di tool” per forzare l’efficienza, un concetto semplice ma che richiede un bilanciamento delicato tra velocità e profondità dell’analisi.
Un’altra sfida è stata la gestione di pattern ambigui nella rete. Quando un IP è contemporaneamente un NAS di backup e un concentratore VPN, l’agente deve gestire entrambi i ruoli senza bloccare servizi critici. Ho scoperto che servono regole esplicite per ogni scenario ambiguo, e una meta-regola che impedisca al modello di estendere automaticamente le lezioni di uno scenario verificato a scenari non verificati.
La Scelta Locale: Privacy e Sovranità
Tutto il progetto gira su inferenza locale. Nessun dato lascia il mio perimetro. La ragione è semplice: un alert del SIEM contiene IP interni, nomi utente, dettagli di configurazione. Inviare tutto questo a un’API esterna è un rischio che un SOC Manager non può accettare.
L’infrastruttura è un cluster Proxmox con nodi dedicati per ogni funzione, agenti, SIEM, threat intelligence, tutti su hardware che si trova sul mercato dell’usato. Una GPU consumer con 16GB di VRAM per l’inferenza. Il modello attuale è un MoE da 35B parametri in versione quantizzata, configurato con temperatura 0.3, top_p 0.8. Ogni parametro scelto per ridurre la creatività e massimizzare la precisione.
Il costo totale dell’infrastruttura è inferiore a un mese di abbonamento di molte piattaforme AI cloud. E con esso ho un ambiente persistente, sicuro, sotto il mio controllo completo.
Anche il framework agenti ha subito un’evoluzione. Ho iniziato con un framework multi-agente che mi permetteva di definire ruoli e orchestrare i task, ma col tempo ho scoperto che le esigenze di ogni agente erano troppo diverse per stare sotto lo stesso tetto. P.E.P.P.E.R. ha bisogno di cron scheduling, accesso a filesystem e tool di pubblicazione. F.R.I.D.A.Y. ha bisogno di integrazioni con il SIEM via API e di un daemon che gira 24/7. J.A.R.V.I.S. ha bisogno di un ambiente Kali isolato. Ho dovuto migrare, adattare, a volte riscrivere da zero. Ho imparato che nel mondo degli agenti AI, il framework è il componente più volatile, quello che cambi più spesso. Costruite il vostro sistema in modo che il framework sia sostituibile senza dover riscrivere tutto il resto.
Cosa Ho Imparato in Questi Mesi
L’AI non sostituisce gli analisti, li libera. P.E.P.P.E.R. mi fa risparmiare ore ogni settimana che ora dedico all’analisi e alla strategia. F.R.I.D.A.Y. non prende decisioni al mio posto, mi presenta le informazioni strutturate per decidere più velocemente.
La revisione umana non è opzionale. Ogni bollettino viene revisionato. Ogni triage passa per la mia approvazione. La responsabilità è umana, sempre.
Inizia piccolo, dimostra valore, scala. Il primo agente funzionante è stato il proof of concept che ha giustificato tutto il resto. Se avessi provato a costruire tutto insieme, avrei fallito.
La supply chain dell’AI è un rischio. Framework che cambiano versione ogni settimana. Modelli deprecati. API locali con bug. Gateway che muoiono quando la sessione terminale si chiude. Un nodo Proxmox che crasha e ti porta via l’agente più maturo con tutti i suoi file, e scopri che il backup che pensavi di avere non copriva quella directory. Ho imparato a trattare le dipendenze AI come qualsiasi altro software nel perimetro: backup verificati, monitoring, piano B. Un container Linux che muore e si rialza con systemd è molto più affidabile di un processo lanciato con nohup e una preghiera.
Il diavolo è nei dettagli operativi. Il gaming PC che fa inference si spegne dopo l’inattività. Servono cron WOL (Wake-on-LAN) che lo accendano 10 minuti prima di ogni task AI. Il container OpenCTI che mangia 40GB di RAM e va in OOM, rendendo irraggiungibile la piattaforma CTI per 24 ore. Lo script di raccolta dati che usa l’IP sbagliato perché hai migrato il container su un altro nodo senza aggiornare la configurazione. Nessuno di questi problemi è “AI”, sono problemi di ingegneria di sistema. Ma senza risolverli, l’AI più brillante del mondo resta un cervello senza corpo.
Il tono conta quanto i dati. Un bollettino di threat intelligence non deve creare panico, deve informare. Ho dovuto insegnare a P.E.P.P.E.R. che un SOC Manager mantiene il sangue freddo, analizza i fatti con lucidità, e non usa espressioni come “terrificante” o “emergenza assoluta”. Il tono giusto è quello di un briefing operativo, non di un titolo di giornale.
Dove Stiamo Andando
Il progetto è lontano dall’essere completo. J.A.R.V.I.S. è in deploy su un ambiente dedicato, presto attaccherà le VM vulnerabili senza che F.R.I.D.A.Y. sappia di essere sotto test. L’obiettivo è un ciclo di miglioramento continuo dove il Red Team allena il Blue Team, e viceversa. In tempo reale. In modo autonomo.
Sto esplorando l’integrazione di un agente dedicato all’enrichment passivo degli IOC e la costruzione di un pipeline a 5 iterazioni per il bollettino settimanale, ogni iterazione specializzata su un aspetto diverso (notizie top, ransomware, vulnerabilità Italia, prospettiva, revisione finale).
Il fine-tuning è l’orizzonte più promettente. Ho accumulato mesi di dati, alert analizzati, decisioni prese, falsi positivi identificati. Questo dataset è la base per specializzare il modello sul mio ambiente specifico.
Ma la lezione più importante non è tecnica. È culturale. Costruire un SOC Lab con agenti AI non è un progetto IT, è un cambio di mentalità. Significa accettare che gli strumenti del mestiere stanno cambiando e che l’unico modo per capire se funzionano è provarli, sbagliare e riprovare.
Il futuro della cybersecurity non è scegliere tra attacco e difesa, è farli dialogare. In tempo reale. In modo autonomo.
Stay purple. 🟣
Fonti:
¹ Ponemon Institute, “The State of the SOC: Burnout, Budgets, and Breaches” (2023) ² Ji, Z., et al., “Survey of Hallucination in Natural Language Generation,” ACM Computing Surveys (2023) ³ MITRE ATT&CK® Framework, https://attack.mitre.org/ ⁴ Hu, E.J., et al., “LoRA: Low-Rank Adaptation of Large Language Models,” arXiv:2106.09685 (2021)