Repo del giorno: T3MP3ST, il red teaming autonomo guidato dagli agenti AI

💡 Cos'è T3MP3ST: un «meta-harness» offensivo multi-agente

T3MP3ST è un framework di sicurezza offensiva multi-agente: non è un nuovo modello e non è un exploit, è l'impalcatura che coordina più agenti AI attorno a un obiettivo di red teaming. L'idea, nelle parole del progetto, è che «il tuo agente di coding è già un hacker»: T3MP3ST gli mette attorno un arsenale di strumenti e una regia. È scritto in TypeScript, è open source con licenza AGPL-3.0 e conta oltre 4.000 stelle su GitHub.

Lo avvii in locale — `npm install` e `npm run server` — e apri una War Room nel browser: colleghi l'agente che già usi, descrivi in linguaggio naturale un bersaglio autorizzato e la missione parte. La prima riga del README non è una feature ma un avviso, e lo riporto per intero nello spirito giusto: è uno strumento offensivo, va puntato solo su sistemi che possiedi o che hai il permesso scritto di testare. Accesso non autorizzato a sistemi altrui è illegale nella maggior parte delle giurisdizioni.

# 1) installa e avvia il server locale
npm install
npm run server        # War Room → http://127.0.0.1:3333/ui/

# 2) nella War Room colleghi un agente (Claude Code / Codex / Hermes)
#    e descrivi un bersaglio che possiedi o sei autorizzato a testare
# 3) verifica i numeri dichiarati dal progetto
npm run verify-claims  # ri-deriva ogni benchmark dai dati committati

🔓 Perché conta (anche se non farai mai un pentest)

La sicurezza offensiva è sempre stata un mestiere da specialisti: anni di pratica e strumenti costosi. La scommessa di T3MP3ST è che uno sciame di agenti coordinati abbassi quella barriera — web app, CTF, smart contract, codice sorgente, OSS embedded. Puoi essere d'accordo o meno sull'opportunità, ma la direzione è chiara e riguarda tutti: se attaccare costa sempre meno, difendere diventa un problema di tutti i giorni, non solo delle grandi aziende.

Ed è qui il valore per chi non fa il penetration tester di mestiere: è un promemoria sul modello di minaccia. I tuoi sistemi — e sempre più i tuoi sistemi basati su AI — verranno sondati da agenti automatici, instancabili e a basso costo. Capire come ragiona un harness offensivo è il primo passo per chiudere le porte giuste. Non serve saper attaccare: serve sapere che l'attacco, oggi, si automatizza.

⚙️ Come funziona: una kill chain a 8 operatori su MITRE ATT&CK

L'architettura è una catena a otto operatori, ognuno mappato su una fase del Cyber Kill Chain e del framework MITRE ATT&CK: Recon, Scanner, Exploiter, Infiltrator, Exfiltrator, Ghost, Coordinator e Analyst. È il vocabolario standard con cui i difensori descrivono un attacco — vederlo usato come schema di orchestrazione degli agenti è, di per sé, una buona lezione di sicurezza.

La cosa più onesta del progetto è la tabella di stato: dice esattamente cosa è reale e cosa è impalcatura. Oggi il motore di recon è stabile e tool-backed (nmap, DNS, HTTP, fingerprinting), mentre le fasi successive girano lo stesso loop ReAct ma restano sperimentali, e lo «sciame» coordinato è dichiaratamente ancora non provato. Nessuna promessa gonfiata: quello che non è dimostrato, viene marcato come tale.

🛡️ I paletti di sicurezza: autorizzazione, scope e gate umano

Un tool così va giudicato anche — soprattutto — dai suoi freni. E T3MP3ST ne ha di seri, attivi di default. Il primo è il contenimento dello scope in uscita: una volta fissato il bersaglio della missione, gli strumenti di rete integrati rifiutano gli host fuori ambito (rispondono `SCOPE DENIED`) — niente loopback, niente reti private, solo il target dichiarato. Il secondo è il gate di approvazione umana sui driver più pericolosi: l'arsenale di base ha 35 tool, ma i moduli di post-exploitation avanzata (come Metasploit e Hydra) si attivano solo con conferma esplicita di una persona.

C'è poi una pipeline di coordinated disclosure: quando emerge una vulnerabilità reale, il framework prepara le bozze di segnalazione, ma è sempre un umano a inviarle. La regola che gli autori mettono per iscritto è una sola e non negoziabile: «costruisci per i difensori, o non costruirlo qui». Per una PMI il messaggio pratico è che, se mai si testa qualcosa, lo si fa dentro perimetro, con autorizzazione e con i freni inseriti.

• Solo target autorizzati: sistemi propri o con permesso scritto. La responsabilità è di chi usa lo strumento.
• Scope containment on by default: gli host fuori ambito vengono rifiutati (`SCOPE DENIED`).
• Gate umano: i tool offensivi pericolosi richiedono conferma esplicita di una persona.
• Disclosure coordinata: il framework prepara le bozze, l'invio resta all'operatore umano.

📊 Numeri riproducibili: il dettaglio che lo distingue

In un settore pieno di annunci roboanti, T3MP3ST fa una cosa rara: ti mette in mano il modo di rifare i conti. Ogni numero del README si ri-deriva da dati committati con un comando (`npm run verify-claims`, 24 controlli su 24 verdi), e una guardia anti-fitting gira a ogni push. Se una cifra non è riproducibile, non entra. È lo stesso principio editoriale che applico qui: una misura vale quanto la sua metodologia.

Sui benchmark, i risultati dichiarati sono notevoli — 90,1% pass@1 sulla suite XBEN di XBOW (sopra l'85% auto-riportato da XBOW), 23/40 senza indizi su Cybench, e su 10 CVE reali post-cutoff, mai viste dal modello, 8/10 individuate con file, riga e CWE esatti. Ma anche qui l'onestà è parte del prodotto: quei numeri arrivano da un singolo agente, non dallo sciame coordinato, e il progetto lo scrive nero su bianco.

repo       elder-plinius/T3MP3ST
stelle     ~4.400 · licenza AGPL-3.0 · nessuna garanzia
stack      TypeScript · JavaScript · Node.js
agenti     Claude Code · Codex · Hermes · modelli locali
engine     recon tool-backed (stabile) · fasi successive sperimentali
prova      npm run verify-claims → ogni numero si ri-deriva

🧰 Keyless e offline: l'agente (e il modello) che hai già

Due scelte tecniche lo rendono interessante da studiare. La prima è l'approccio keyless: T3MP3ST non chiede nuove API key né un tenant cloud, usa l'agente di coding che hai già collegato. La seconda è la modalità completamente offline: puoi puntarlo su un modello locale servito da Ollama, LM Studio o vLLM, e il tool-calling funziona via testo anche con modelli senza function-calling nativo. Nulla deve uscire dalla tua macchina.

Per una PMI, questo è il punto che pesa: un test di sicurezza — su sistemi propri e autorizzati — può girare in casa, senza spedire nulla a servizi esterni. È anche un bel caso di studio di integrazione: T3MP3ST espone `security_recon` come server MCP, lo stesso protocollo di cui ho parlato tante volte, e un'API HTTP per orchestrare le missioni.

# nessuna chiave, nessun cloud: il modello gira in locale
ollama serve && ollama pull llama3
export TEMPEST_LOCAL_BASE_URL=http://localhost:11434/api
export TEMPEST_LOCAL_MODEL=llama3
npx tempest   # poi: “Change default provider” → local

🏢 Cosa impararne, per sviluppatori e PMI

Per chi sviluppa, T3MP3ST è un piccolo corso accelerato su più fronti: orchestrazione multi-agente con loop ReAct reali, mappatura su MITRE ATT&CK, e soprattutto una disciplina di misurazione (numeri che si ri-derivano, guardie anti-fitting) che vale la pena copiare ben oltre la sicurezza. Anche solo leggere come separa «ciò che funziona» da «ciò che è ancora una scommessa» è istruttivo.

Per una PMI la lettura è difensiva, e semplice: gli avversari si stanno automatizzando, quindi l'igiene di sicurezza non è più un lusso. Testare i propri sistemi (con professionisti e autorizzazioni), aggiornare le dipendenze, mettere in sicurezza i propri deployment di AI: sono attività che il calo del costo d'attacco rende più urgenti, non meno. Lo strumento non serve a spaventare, ma a inquadrare bene il rischio e a spendere le energie di sicurezza dove contano.

⚠️ Cosa sapere prima di avvicinarsi

Metto i puntini sulle i. T3MP3ST è uno strumento offensivo: l'uso non autorizzato è illegale e la responsabilità è interamente di chi lo usa. È distribuito as-is sotto AGPL-3.0, senza garanzie e senza responsabilità per danni o abusi. Non è un giocattolo e non è un pulsante «trova i bug» da premere a caso.

Sul piano tecnico, va ricordato che lo sciame coordinato è ancora non provato: i numeri arrivano da un singolo agente, e molti domini (cloud, mobile, binario/RE, Active Directory) sono dichiaratamente in sviluppo o solo impalcatura. Può azionare tool di exploit reali, quindi i freni — scope containment e gate umano — vanno tenuti inseriti, sempre. Trattalo come si tratta un attrezzo pericoloso: con competenza, perimetro e autorizzazioni.

• Legale solo se autorizzato: sistemi propri o con permesso scritto, dentro le regole d'ingaggio.
• AGPL-3.0, as-is: nessuna garanzia, nessuna responsabilità degli autori.
• Maturità disomogenea: recon stabile, sciame e molti domini ancora sperimentali o roadmap.
• Freni sempre inseriti: scope containment e approvazione umana sui tool pericolosi.

🗺️ Da dove partire (in sicurezza)

Il percorso responsabile parte dai documenti, non dai comandi: leggi prima la `SECURITY.md` e la guida `SCOPE_AND_AUTHORIZATION`, così è chiaro cosa significhi «autorizzato». Poi, se proprio vuoi provarlo, fallo su un tuo laboratorio o su un perimetro esplicitamente autorizzato, con il contenimento di scope attivo e i tool pericolosi dietro il gate umano. L'obiettivo giusto non è «attaccare qualcosa», ma capire il modello di minaccia dell'era degli agenti.

Se lavori in azienda, il messaggio è ancora più semplice: coinvolgi professionisti e metti l'autorizzazione per iscritto. E per inquadrare il tema più in generale, gli approfondimenti qui sotto parlano di governance dell'AI in azienda, autorizzazione degli agenti via MCP e AI agentica nei processi. Capire come si muove un avversario automatico vale più di qualunque singolo exploit.

Altri articoli del blog