Quando il red team diventa una “crew” di agenti AI
Questo articolo nasce dall’esigenza di mettere un po’ d’ordine agli appunti presi durante il corso “Agenti nell’Ombra” di Ethical Hacker Italiani. A fine corso ho creato una piccola crew di specialisti che fanno OSINT, scanning, enumeration, analisi delle vulnerabilità e che, orchestrati con CrewAI, collaborano lungo l’intera pipeline di un assessment.
L’automazione del penetration testing non è una novità: scanner, framework e script accompagnano da sempre il lavoro offensivo. La novità è chi orchestra quegli strumenti. Con i framework multi-agente – CrewAI su tutti – non è più un operatore a decidere passo dopo passo quale comando lanciare, ma un modello linguistico che ragiona, sceglie un tool, ne osserva l’output e decide la mossa successiva. È il salto dall’automazione deterministica all’automazione agentica.
Questo articolo analizza l’architettura di un sistema di questo tipo – un piccolo “red team” composto da agenti specializzati che collaborano lungo l’intera pipeline di un assessment, dalla reconnaissance al report – così come viene strutturato nel percorso formativo Agenti nell’Ombra. L’obiettivo non è fornire ricette operative, ma capire come questi sistemi sono costruiti, dove si collocano i punti di controllo e quali conseguenze hanno per chi lavora sul fronte opposto: difesa, incident response e digital forensics.
La tesi di fondo è semplice: un agente AI che impugna strumenti offensivi amplifica tanto le capacità quanto i rischi. Comprenderne il funzionamento interno è oggi un prerequisito sia per chi progetta pipeline offensive responsabili, sia per chi deve rilevarne e ricostruirne le tracce.
Dai primitivi di CrewAI al “mini red team”
Per capire il sistema occorre distinguere tre livelli di automazione che vengono spesso confusi. Uno script esegue una sequenza di istruzioni decisa a priori: condizione → azione, nessun ragionamento. Un chatbot genera testo ma non agisce sul mondo esterno. Un agente AI combina i due: comprende un obiettivo in linguaggio naturale, ma possiede anche strumenti con cui compiere azioni reali e la capacità di decidere, durante l’esecuzione, quale azione eseguire. È questa capacità di agire sotto decisione a renderlo rilevante – e pericoloso – in cybersecurity.
Il ciclo operativo di ogni agente è un loop continuo di quattro momenti: obiettivo (cosa deve ottenere), ragionamento (il modello valuta il contesto e sceglie una strategia), azione (usa un tool per interagire con l’ambiente) e osservazione (interpreta l’output e aggiorna la propria comprensione). Il loop prosegue finché l’obiettivo non è raggiunto o non arriva un’istruzione di stop.
CrewAI organizza questo schema in cinque primitive che conviene fissare, perché ricorrono in tutta l’architettura:
| Primitiva | Ruolo | Analogia operativa |
| Agent | Unità con identità, obiettivo e competenze specifiche | Il professionista virtuale specializzato |
| Tool | Capacità operativa: esegue comandi, interroga API, legge file | Le “mani” dell’agente |
| Task | L’incarico: contesto, istruzioni e output atteso | L’ordine di lavoro |
| Crew | L’insieme coordinato di agenti e task | La squadra |
| Process | La logica con cui il lavoro viene eseguito | Il regolamento operativo |
Il principio progettuale cardine è la separazione delle responsabilità: invece di un unico agente “tuttofare” – inaffidabile e difficile da mantenere – si costruisce una crew di specialisti. Nel contesto offensivo i ruoli ricalcano naturalmente le fasi di un assessment: un analista OSINT, uno scanner, un esperto di enumeration, un analista delle vulnerabilità e un redattore del report. Ognuno ha un compito solo, e questo rende il comportamento complessivo più prevedibile e verificabile.
Un elemento spesso sottovalutato merita attenzione forense: la description di un tool non è documentazione, è parte del prompt operativo. L’agente sceglie quale strumento usare leggendo le descrizioni disponibili. Una description vaga produce comportamenti vaghi; una description precisa – cosa fa il tool, quando usarlo, quali limiti rispettare – guida le decisioni. In pratica, buona parte della “programmazione” di questi sistemi non sta nel codice ma nel linguaggio naturale che ne definisce il perimetro decisionale.
L’architettura: pipeline, stato condiviso e orchestrazione
Il sistema ricalca il flusso di un penetration test professionale, ma ogni fase è affidata a un agente dedicato. A monte di tutto sta un controllo non tecnico ma decisivo: la validazione dello scope. Prima che qualunque agente agisca, la pipeline verifica che il target rientri negli indirizzi, domini e regole d’ingaggio autorizzati. È il primo filtro di sicurezza dell’architettura e la sua posizione – prima di ogni azione – non è casuale.
Superato il controllo, il lavoro scorre lungo una catena di specialisti: OSINT costruisce il contesto iniziale da fonti pubbliche; Scanner mappa host, porte e servizi esposti; Enumeration arricchisce i dati con banner, tecnologie e directory; Vulnerability Assessment correla versioni e configurazioni con vulnerabilità note; l’eventuale Exploitation verifica in modo controllato la reale sfruttabilità dei finding autorizzati; infine il Reporting trasforma le evidenze in un documento utile a tecnici e decisori.
Lo shared state come “fonte unica della verità”
Il collante dell’intero sistema è lo shared state: una memoria condivisa, una sorta di dossier operativo che ogni agente legge e aggiorna. Lo Scanner vi deposita le porte aperte, l’Enumeration vi aggiunge le tecnologie, il Vulnerability Assessor vi attinge per la correlazione. Senza questa struttura ogni agente ripeterebbe il lavoro dei colleghi, con duplicazioni, incoerenze e costi computazionali moltiplicati.
Dal punto di vista dell’analista forense lo shared state è il reperto più interessante dell’intera architettura: è la rappresentazione centralizzata e datata di tutto ciò che il sistema ha scoperto e deciso. Se correttamente persistito, diventa una timeline naturale dell’attività – chi ha aggiunto quale informazione e quando – utile tanto al debugging quanto alla ricostruzione a posteriori.
Sequential contro hierarchical
L’orchestrazione può seguire due logiche. Nel processo sequential gli agenti lavorano in ordine prestabilito: ciascuno completa il proprio compito e passa il risultato al successivo. È semplice, prevedibile, facile da verificare – e proprio per questo preferibile nelle prime fasi e negli ambienti dove la tracciabilità conta.
Nel processo hierarchical compare un Manager Agent che non esegue attività tecniche ma coordina: osserva lo shared state, decide dinamicamente quali specialisti coinvolgere e, soprattutto, se una vulnerabilità meriti approfondimento. È il Manager a presidiare il passaggio più delicato – l’exploitation – subordinandolo alla verifica di scope e regole d’ingaggio. Maggiore flessibilità, ma a un costo: più complessità, debugging più difficile, consumo di risorse più alto e, dal punto di vista della sicurezza, una superficie decisionale più ampia e meno prevedibile.
Lo schema seguente sintetizza il flusso end-to-end e il ruolo cardine dello stato condiviso.
Pipeline agentica: 7 fasi, shared state, Manager (hierarchical)
Le frecce verticali sono il flusso sequenziale; quelle orizzontali il doppio accesso in lettura/scrittura allo shared state. Il riquadro tratteggiato è il Manager, presente solo nel modello hierarchical, che può ridirigere il flusso e autorizza l’exploitation — la fase evidenziata in ambra, la più delicata.
Dove si annidano i rischi (e come contenerli)
Lo stesso corso è netto su un punto: non si sta costruendo una macchina che compromette automaticamente qualsiasi bersaglio. È un sistema che assiste l’operatore, il quale resta responsabile di scope, interpretazione e decisioni. Questa non è una clausola di stile: è la linea che separa uno strumento professionale da un acceleratore di danni. Analizziamo i rischi concreti.
La superficie di rischio è il tool, non il modello. Il componente centrale – un ShellTool che esegue comandi arbitrari su Kali – è insieme la fonte della potenza e del pericolo. Il principio è lineare: più uno strumento è potente, più controllo richiede. Un agente che può costruire ed eseguire qualunque comando shell eredita tutti i privilegi del processo che lo ospita; un errore di ragionamento diventa immediatamente un effetto reale sul sistema.
I rischi specifici da presidiare:
- Allucinazioni e decisioni errate. Il modello può produrre output plausibili ma infondati, interrompere un’analisi troppo presto o interpretare male un risultato. In un contesto offensivo questo significa comandi sbagliati verso bersagli reali.
- Esecuzione fuori scope. Un agente autonomo che non valida rigorosamente il target può estendere l’attività oltre il perimetro autorizzato. L’automazione amplifica la velocità con cui un errore di configurazione produce conseguenze legali e contrattuali.
- Prompt injection e output poisoning. Qui sta il rischio più sottile. L’agente osserva l’output dei tool e lo usa per decidere. Un target può restituire deliberatamente banner, pagine o risposte costruite per manipolare il ragionamento dell’agente – trasformando un servizio ostile in un canale di comando verso la crew. La catena di fiducia “output del tool → decisione del modello” è attaccabile.
- Saturazione del contesto. Tool che restituiscono migliaia di righe possono nascondere l’informazione rilevante e degradare le decisioni. Per questo l’output va troncato e filtrato – scelta di efficienza che è anche una scelta di sicurezza.
I controlli che il percorso formativo integra fin dall’inizio rispondono punto per punto:
| Controllo | A quale rischio risponde |
| Validazione dello scope prima di ogni azione | Esecuzione fuori perimetro |
| Human-in-the-loop sulle decisioni critiche | Allucinazioni, autonomia eccessiva |
| Exploitation subordinata a verifica del Manager | Azioni distruttive non autorizzate |
| Timeout e troncamento dell’output | Saturazione del contesto, processi bloccati |
| Autonomia controllata (decidere entro limiti definiti) | Comportamenti imprevedibili |
Il filo rosso è l’autonomia controllata: non assenza di controllo, ma capacità di decidere entro limiti chiari. L’essere umano definisce lo scope, interpreta i risultati e mantiene la responsabilità finale – un principio che la presenza di strumenti automatizzati non attenua, ma rende più stringente.
Che cosa cambia per DFIR e incident response
Questa tecnologia non resta confinata nei laboratori autorizzati. La stessa architettura che accelera un pentest etico può essere adottata da un attaccante per automatizzare recon e scanning su larga scala. Per chi fa difesa e digital forensics, tre implicazioni meritano attenzione.
1. Cambia la firma dell’attività offensiva. Un agente che ragiona tra un comando e il successivo produce pattern temporali diversi da uno script lineare: raffiche di comandi eterogenei intervallate da pause “decisionali”, scelta adattiva dei tool, enumerazione che cambia direzione in base ai risultati. Riconoscere questa cadenza non umana ma non deterministica diventa un segnale utile nel threat hunting.
2. Lo shared state è una miniera forense. Se un sistema di questo tipo è coinvolto – come strumento legittimo da acquisire o come artefatto trovato su una macchina compromessa – lo stato condiviso è il reperto più ricco: un dossier centralizzato e progressivo di target, scoperte e decisioni. Insieme ai log del framework, agli output troncati e alle chiamate API verso il provider del modello, costituisce una timeline ricostruibile. Per il DEFR vale la pena sapere dove questi artefatti si depositano (file di stato, cache, log applicativi) prima che vengano sovrascritti.
3. L’autorizzazione resta il discrimine giuridico. Il punto ribadito in tutto il corso – operare solo su target autorizzati – non è una raccomandazione etica ma il confine tra un’attività lecita e un reato. Un agente AI che esegue una scansione fuori scope genera le stesse conseguenze di un operatore umano. In sede investigativa, la presenza di meccanismi di validazione dello scope (o la loro assenza) diventa un elemento qualificante dell’intenzionalità e della diligenza.
In sintesi
Gli agenti AI applicati alla sicurezza offensiva non sostituiscono il professionista: ne spostano il lavoro dal fare verso il decidere e supervisionare. L’analogia più onesta, proposta dal corso stesso, è quella dell’analista junior supervisionato: veloce, instancabile, utile sulle attività ripetitive – ma da non lasciare mai senza controllo sulle decisioni che contano.
Per chi opera in DFIR, la lezione è duplice. Da un lato, questi framework sono strumenti che possiamo usare per rendere più rapide le nostre stesse attività autorizzate. Dall’altro, definiscono una nuova classe di minaccia da saper riconoscere, acquisire e ricostruire. In entrambi i casi vale lo stesso principio che regge l’intera architettura: la potenza dell’automazione ha valore solo quando resta sotto controllo umano.