Red Team AI: perché l'on-prem batte il cloud nel pentest enterprise

Se gestisci infrastruttura critica, la tua superficie d'attacco è un segreto di Stato in tutto tranne che nel nome. La topologia di rete, gli hostname interni, le convenzioni delle credenziali, i nomi dei database in produzione — tutto questo è intelligence per cui un attaccante pagherebbe. Allora perché stai mandando la stessa intelligence al cloud di un terzo ogni volta che lanci un "pentest AI moderno"?

È la domanda a cui Zero Hunt è stata costruita per rispondere.

Cosa vuol dire davvero "pentest AI in cloud"

Quasi tutta la nuova ondata di prodotti offensive security guidati da AI è SaaS. Installi un thin agent nella tua rete. L'agent carica output di scan, screenshot, configurazioni parsate, a volte traffico HTTP grezzo, nel cloud del vendor. Una flotta di LLM su GPU ragiona sul tuo ambiente da lì. L'output — candidati di exploit, attack path, finding — torna indietro.

Funziona, tecnicamente. Vuol dire però che:

• La tua topologia di rete vive in un bucket S3 di qualcun altro.
• Una breach del vendor è una breach tua.
• Gli auditor NIS2 o DORA faranno domande scomode sulla "supply chain del tuo AI provider terzo" — domande che diventano più dure con l'entrata in vigore dell'AI Act.
• Non puoi usare lo strumento in ambienti classificati, air-gap o a bassa connettività.

Per la maggior parte delle aziende era una scelta accettabile solo perché non c'era alternativa. Adesso non è più così.

Cosa è cambiato

Negli ultimi 24 mesi tre cose hanno reso davvero praticabile il red teaming AI on-prem:

1. Modelli open-weight che non fanno figuracce. I coder e reasoner locali da 8-70B oggi scrivono primitive di exploit funzionanti senza telefonare a casa. Non sono GPT-5, ma per il dominio ristretto dell'offensive security il gap si sta chiudendo in fretta.
2. GPU di inference a basso costo. Una sola L40S o H100 regge il carico di un pentest enterprise. Non serve una flotta su scala cloud — serve una macchina, ferma per buona parte del tempo, che fa picco durante le campagne.
3. RAG sul tuo corpus. Se i tool cloud sembravano intelligenti non era merito dell'LLM, era il contesto curato che gli davano in pasto. Con pgvector e un embedding model locale, quel corpus puoi costruirlo on-prem e farci entrare quello che vuoi: feed CVE, MITRE ATT&CK, GTFOBins, LOLBAS e — soprattutto — i tuoi finding storici.

Quando queste tre cose esistono in locale, il loop verso il cloud diventa una passività, non una feature.

L'architettura di Zero Hunt, in un paragrafo

Zero Hunt è un'appliance hardware con GPU dedicata, un LLM locale, un servizio di embedding locale (Jina v3 nella build di default), un orchestrator a 10 agenti (Recon → Exploit → Web → Credential → Post-Exploit → Pivot → Tactic → Report, coordinati da un AI Controller) e un'esecuzione Docker in sandbox. Ogni exploit è generato dall'LLM, non recuperato da un database. Ogni finding viene embeddato in pgvector e richiamato nelle campagne future. Niente — niente — lascia la scatola.

Tre pattern che escono naturalmente dall'"on-prem first"

Quando ti imponi l'on-prem come vincolo di design, emergono tre pattern di ingegneria che i prodotti cloud non possono copiare facilmente.

1. Exploit generativi, non firme

I tool cloud tendono a ripiegare su librerie di exploit curate, perché rigenerare exploit per ogni target è costoso e fa scattare i filtri antiabuso. On-prem non abbiamo nessuno dei due vincoli. Ogni target riceve uno script fresco, scritto per il suo stack specifico. Non c'è una signature contro cui i blue team possano matchare — perché non c'è la signature.

2. Backtesting in una palestra sigillata

Ogni nuova "skill" che l'AI propone viene testata contro una libreria privata di ambienti vulnerabili (Vulhub, NYU CTF Bench, Cybench e i nostri) prima di vedere la produzione. In un cloud multi-tenant non lo puoi fare in scala — non puoi dare le skill evolute del Cliente A al Cliente B senza far trapelare com'è fatto lo stack del Cliente A. On-prem la palestra è tua.

3. Compliance come effetto collaterale

Visto che ogni azione, ogni finding e ogni remediation vengono loggati in locale e non escono mai, accumuli esattamente il corpus di evidenze che un auditor NIS2, DORA o ISO 27001 chiederà. Noi firmiamo ECDSA ogni artefatto al momento della scrittura. La richiesta dell'auditor "fammi vedere la chain-of-custody della vulnerabilità X" diventa un unico export firmato.

A cosa rinunci

Non è un pasto gratis. Il red teaming AI on-prem ti costa:

• CapEx iniziale. Un'appliance non è un abbonamento da 10€/mese.
• Modelli leggermente più deboli. Un coder 70B locale non è GPT-5. Compensiamo con specializzazione dei task e RAG, ma un confronto onesto ammette il gap.
• Devi gestire la scatola. Update, patch, engine. Spediamo un sync-server che fa scaricare release firmate alle appliance dei clienti, ma la superficie di responsabilità è più ampia del SaaS.

Quasi tutte le aziende con cui parliamo decidono che il trade-off vale appena immaginano un attaccante che si muove laterale attraverso il loro vendor di pentest.

Dove andare adesso

Se vuoi vedere come funziona nella pratica, la panoramica della piattaforma copre i tre pilastri (pentest generativo, AI traffic analysis, compliance automatica), la matrice di confronto mette in numeri il gap rispetto a Pentera / Horizon3 / XM Cyber / Cymulate, e la sezione funzionalità approfondisce le primitive di ingegneria. Puoi anche chiedere una demo hands-on — niente sales sequence, parli direttamente con gli ingegneri.

Nel frattempo, la sintesi: se il tuo tool di sicurezza è "AI-powered" ma la prima cosa che fa è chiamare casa, non è un tool di sicurezza. È un canale di esfiltrazione dati per cui paghi.