L\u2019automazione del penetration testing non \u00e8 una novit\u00e0: scanner, framework e script accompagnano da sempre il lavoro offensivo. La novit\u00e0 \u00e8 chi<\/em> orchestra quegli strumenti. Con i framework multi-agente – CrewAI su tutti – non \u00e8 pi\u00f9 un operatore a decidere passo dopo passo quale comando lanciare, ma un modello linguistico che ragiona, sceglie un tool, ne osserva l\u2019output e decide la mossa successiva. \u00c8 il salto dall\u2019automazione deterministica<\/em> all\u2019automazione agentica<\/em>.<\/p>\n\n\n\n Questo articolo analizza l\u2019architettura di un sistema di questo tipo – un piccolo \u201cred team\u201d composto da agenti specializzati che collaborano lungo l\u2019intera pipeline di un assessment, dalla reconnaissance al report – cos\u00ec come viene strutturato nel percorso formativo Agenti nell\u2019Ombra<\/em>. L\u2019obiettivo non \u00e8 fornire ricette operative, ma capire come<\/strong> questi sistemi sono costruiti, dove<\/strong> si collocano i punti di controllo e quali conseguenze<\/strong> hanno per chi lavora sul fronte opposto: difesa, incident response e digital forensics.<\/p>\n\n\n\n La tesi di fondo \u00e8 semplice: un agente AI che impugna strumenti offensivi amplifica tanto le capacit\u00e0 quanto i rischi. Comprenderne il funzionamento interno \u00e8 oggi un prerequisito sia per chi progetta pipeline offensive responsabili, sia per chi deve rilevarne e ricostruirne le tracce.<\/p>\n\n\n\n Per capire il sistema occorre distinguere tre livelli di automazione che vengono spesso confusi. Uno script<\/em> esegue una sequenza di istruzioni decisa a priori: condizione \u2192 azione, nessun ragionamento. Un chatbot<\/em> genera testo ma non agisce sul mondo esterno. Un agente AI<\/em> combina i due: comprende un obiettivo in linguaggio naturale, ma possiede anche strumenti con cui compiere azioni reali e la capacit\u00e0 di decidere, durante l\u2019esecuzione, quale azione eseguire. \u00c8 questa capacit\u00e0 di agire sotto decisione<\/em> a renderlo rilevante – e pericoloso – in cybersecurity.<\/p>\n\n\n\n Il ciclo operativo di ogni agente \u00e8 un loop continuo di quattro momenti: obiettivo<\/strong> (cosa deve ottenere), ragionamento<\/strong> (il modello valuta il contesto e sceglie una strategia), azione<\/strong> (usa un tool per interagire con l\u2019ambiente) e osservazione<\/strong> (interpreta l\u2019output e aggiorna la propria comprensione). Il loop prosegue finch\u00e9 l\u2019obiettivo non \u00e8 raggiunto o non arriva un\u2019istruzione di stop.<\/p>\n\n\n\n CrewAI organizza questo schema in cinque primitive che conviene fissare, perch\u00e9 ricorrono in tutta l\u2019architettura:<\/p>\n\n\n\n Il principio progettuale cardine \u00e8 la separazione delle responsabilit\u00e0<\/strong>: invece di un unico agente \u201ctuttofare\u201d – inaffidabile e difficile da mantenere – si costruisce una crew<\/em> 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\u00e0 e un redattore del report. Ognuno ha un compito solo, e questo rende il comportamento complessivo pi\u00f9 prevedibile e verificabile.<\/p>\n\n\n\n Un elemento spesso sottovalutato merita attenzione forense: la description<\/strong> di un tool non \u00e8 documentazione, \u00e8 parte del prompt operativo. L\u2019agente 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 \u201cprogrammazione\u201d di questi sistemi non sta nel codice ma nel linguaggio naturale che ne definisce il perimetro decisionale.<\/p>\n\n\n\n Il sistema ricalca il flusso di un penetration test professionale, ma ogni fase \u00e8 affidata a un agente dedicato. A monte di tutto sta un controllo non tecnico ma decisivo: la validazione dello scope<\/strong>. Prima che qualunque agente agisca, la pipeline verifica che il target rientri negli indirizzi, domini e regole d\u2019ingaggio autorizzati. \u00c8 il primo filtro di sicurezza dell\u2019architettura e la sua posizione – prima<\/em> di ogni azione – non \u00e8 casuale.<\/p>\n\n\n\n Superato il controllo, il lavoro scorre lungo una catena di specialisti: OSINT<\/strong> costruisce il contesto iniziale da fonti pubbliche; Scanner<\/strong> mappa host, porte e servizi esposti; Enumeration<\/strong> arricchisce i dati con banner, tecnologie e directory; Vulnerability Assessment<\/strong> correla versioni e configurazioni con vulnerabilit\u00e0 note; l\u2019eventuale Exploitation<\/strong> verifica in modo controllato la reale sfruttabilit\u00e0 dei finding autorizzati; infine il Reporting<\/strong> trasforma le evidenze in un documento utile a tecnici e decisori.<\/p>\n\n\n\n Il collante dell\u2019intero sistema \u00e8 lo shared state<\/strong>: una memoria condivisa, una sorta di dossier operativo che ogni agente legge e aggiorna. Lo Scanner vi deposita le porte aperte, l\u2019Enumeration 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.<\/p>\n\n\n\n Dal punto di vista dell\u2019analista forense lo shared state \u00e8 il reperto pi\u00f9 interessante dell\u2019intera architettura: \u00e8 la rappresentazione centralizzata e datata di tutto ci\u00f2 che il sistema ha scoperto e deciso. Se correttamente persistito, diventa una timeline naturale dell\u2019attivit\u00e0 – chi ha aggiunto quale informazione e quando – utile tanto al debugging quanto alla ricostruzione a posteriori.<\/p>\n\n\n\n L\u2019orchestrazione pu\u00f2 seguire due logiche. Nel processo sequential<\/strong> gli agenti lavorano in ordine prestabilito: ciascuno completa il proprio compito e passa il risultato al successivo. \u00c8 semplice, prevedibile, facile da verificare – e proprio per questo preferibile nelle prime fasi e negli ambienti dove la tracciabilit\u00e0 conta.<\/p>\n\n\n\n Nel processo hierarchical<\/strong> compare un Manager Agent<\/strong> che non esegue attivit\u00e0 tecniche ma coordina: osserva lo shared state, decide dinamicamente quali specialisti coinvolgere e, soprattutto, se una vulnerabilit\u00e0 meriti approfondimento. \u00c8 il Manager a presidiare il passaggio pi\u00f9 delicato – l\u2019exploitation – subordinandolo alla verifica di scope e regole d\u2019ingaggio. Maggiore flessibilit\u00e0, ma a un costo: pi\u00f9 complessit\u00e0, debugging pi\u00f9 difficile, consumo di risorse pi\u00f9 alto e, dal punto di vista della sicurezza, una superficie decisionale pi\u00f9 ampia e meno prevedibile.<\/p>\n\n\n\n Lo schema seguente sintetizza il flusso end-to-end e il ruolo cardine dello stato condiviso.<\/p>\n\n\n\n Pipeline agentica: 7 fasi, shared state, Manager (hierarchical)<\/p>\n\n\n\n Le frecce verticali sono il flusso sequenziale; quelle orizzontali il doppio accesso in lettura\/scrittura allo shared state. Il riquadro tratteggiato \u00e8 il Manager, presente solo nel modello hierarchical, che pu\u00f2 ridirigere il flusso e autorizza l\u2019exploitation \u2014 la fase evidenziata in ambra, la pi\u00f9 delicata.<\/p>\n\n\n\n Lo stesso corso \u00e8 netto su un punto: non si sta costruendo una macchina che compromette automaticamente qualsiasi bersaglio. \u00c8 un sistema che assiste<\/em> l\u2019operatore, il quale resta responsabile di scope, interpretazione e decisioni. Questa non \u00e8 una clausola di stile: \u00e8 la linea che separa uno strumento professionale da un acceleratore di danni. Analizziamo i rischi concreti.<\/p>\n\n\n\n La superficie di rischio \u00e8 il tool, non il modello.<\/strong> Il componente centrale – un ShellTool che esegue comandi arbitrari su Kali – \u00e8 insieme la fonte della potenza e del pericolo. Il principio \u00e8 lineare: pi\u00f9 uno strumento \u00e8 potente, pi\u00f9 controllo richiede. Un agente che pu\u00f2 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.<\/p>\n\n\n\n I rischi specifici da presidiare:<\/p>\n\n\n\n I controlli che il percorso formativo integra fin dall\u2019inizio rispondono punto per punto:<\/p>\n\n\n\n Il filo rosso \u00e8 l\u2019autonomia controllata<\/strong>: non assenza di controllo, ma capacit\u00e0 di decidere entro limiti chiari. L\u2019essere umano definisce lo scope, interpreta i risultati e mantiene la responsabilit\u00e0 finale – un principio che la presenza di strumenti automatizzati non attenua, ma rende pi\u00f9 stringente.<\/p>\n\n\n\n Questa tecnologia non resta confinata nei laboratori autorizzati. La stessa architettura che accelera un pentest etico pu\u00f2 essere adottata da un attaccante per automatizzare recon e scanning su larga scala. Per chi fa difesa e digital forensics, tre implicazioni meritano attenzione.<\/p>\n\n\n\n 1. Cambia la firma dell\u2019attivit\u00e0 offensiva.<\/strong> 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 \u201cdecisionali\u201d, scelta adattiva dei tool, enumerazione che cambia direzione in base ai risultati. Riconoscere questa cadenza non umana ma non deterministica<\/em> diventa un segnale utile nel threat hunting.<\/p>\n\n\n\n 2. Lo shared state \u00e8 una miniera forense.<\/strong> Se un sistema di questo tipo \u00e8 coinvolto – come strumento legittimo da acquisire o come artefatto trovato su una macchina compromessa – lo stato condiviso \u00e8 il reperto pi\u00f9 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<\/em> questi artefatti si depositano (file di stato, cache, log applicativi) prima che vengano sovrascritti.<\/p>\n\n\n\n 3. L\u2019autorizzazione resta il discrimine giuridico.<\/strong> Il punto ribadito in tutto il corso – operare solo su target autorizzati<\/mark> – non \u00e8 una raccomandazione etica ma il confine tra un\u2019attivit\u00e0 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\u2019intenzionalit\u00e0 e della diligenza.<\/p>\n\n\n\n Gli agenti AI applicati alla sicurezza offensiva non sostituiscono il professionista: ne spostano il lavoro dal fare<\/em> verso il decidere e supervisionare<\/em>. L\u2019analogia pi\u00f9 onesta, proposta dal corso stesso, \u00e8 quella dell\u2019analista junior supervisionato<\/mark><\/strong>: veloce, instancabile, utile sulle attivit\u00e0 ripetitive – ma da non lasciare mai senza controllo sulle decisioni che contano.<\/p>\n\n\n\n Per chi opera in DFIR, la lezione \u00e8 duplice. Da un lato, questi framework sono strumenti che possiamo usare per rendere pi\u00f9 rapide le nostre stesse attivit\u00e0 autorizzate. Dall\u2019altro, definiscono una nuova classe di minaccia da saper riconoscere, acquisire e ricostruire. In entrambi i casi vale lo stesso principio che regge l\u2019intera architettura: la potenza dell\u2019automazione ha valore solo quando resta sotto controllo umano<\/mark>.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Quando il red team diventa una \u201ccrew\u201d di agenti AI Questo articolo nasce dall\u2019esigenza di mettere un po\u2019 d\u2019ordine agli appunti presi durante il corso \u201cAgenti nell\u2019Ombra\u201d di Ethical Hacker Italiani. A fine corso ho creato una piccola crew di specialisti che fanno OSINT, scanning, enumeration, analisi delle vulnerabilit\u00e0 e che, orchestrati con CrewAI, collaborano … Leggi tutto “Agenti nell\u2019ombra”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":""},"categories":[114,12,14,15,106,112],"tags":[108,156,159,157,52,158,160,107],"class_list":["post-60669","post","type-post","status-publish","format-standard","hentry","category-ai","category-cyber-security","category-digital-forensics","category-ethical-hacking","category-sviluppo","category-vibe-coding","tag-ai","tag-ai-agent","tag-blue-team","tag-crewai","tag-digital-forensics","tag-red-ream","tag-shared-state","tag-vibe-coding"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/60669","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=60669"}],"version-history":[{"count":6,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/60669\/revisions"}],"predecessor-version":[{"id":61908,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/60669\/revisions\/61908"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=60669"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=60669"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=60669"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Dai primitivi di CrewAI al \u201cmini red team\u201d<\/h2>\n\n\n\n
Primitiva<\/td> Ruolo<\/td> Analogia operativa<\/td><\/tr><\/thead> Agent<\/strong><\/td> Unit\u00e0 con identit\u00e0, obiettivo e competenze specifiche<\/td> Il professionista virtuale specializzato<\/td><\/tr> Tool<\/strong><\/td> Capacit\u00e0 operativa: esegue comandi, interroga API, legge file<\/td> Le \u201cmani\u201d dell\u2019agente<\/td><\/tr> Task<\/strong><\/td> L\u2019incarico: contesto, istruzioni e output atteso<\/td> L\u2019ordine di lavoro<\/td><\/tr> Crew<\/strong><\/td> L\u2019insieme coordinato di agenti e task<\/td> La squadra<\/td><\/tr> Process<\/strong><\/td> La logica con cui il lavoro viene eseguito<\/td> Il regolamento operativo<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n L\u2019architettura: pipeline, stato condiviso e orchestrazione<\/h2>\n\n\n\n
Lo shared state come \u201cfonte unica della verit\u00e0\u201d<\/h3>\n\n\n\n
Sequential contro hierarchical<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www.fabriziogiancola.eu\/wp-content\/uploads\/2026\/10\/image.jpg\")
<\/figure>\n\n\n\nDove si annidano i rischi (e come contenerli)<\/h2>\n\n\n\n
\n
Controllo<\/td> A quale rischio risponde<\/td><\/tr><\/thead> Validazione dello scope prima di ogni azione<\/strong><\/td> Esecuzione fuori perimetro<\/td><\/tr> Human-in-the-loop<\/strong> sulle decisioni critiche<\/td> Allucinazioni, autonomia eccessiva<\/td><\/tr> Exploitation subordinata a verifica<\/strong> del Manager<\/td> Azioni distruttive non autorizzate<\/td><\/tr> Timeout e troncamento dell\u2019output<\/strong><\/td> Saturazione del contesto, processi bloccati<\/td><\/tr> Autonomia controllata<\/strong> (decidere entro limiti definiti)<\/td> Comportamenti imprevedibili<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Che cosa cambia per DFIR e incident response<\/h2>\n\n\n\n
In sintesi<\/h2>\n\n\n\n