Qualcosa di misurabile è accaduto alla sicurezza offensiva tra il 2024 e il 2026. Una ricerca che catalogava strumenti di penetration testing IA open-source ha contato meno di cinque prima del rilascio di GPT-4 nell'aprile 2023, e più di settanta all'inizio del 2026 — il che significa che approssimativamente sessantacinque di essi sono apparsi nei diciotto mesi che hanno seguito. Non è un trend dolce verso l'alto; è un cambio di passo. La domanda interessante non è se l'IA è arrivata nella sicurezza offensiva — è chiaramente arrivata — ma quale forma ha preso. La risposta, sempre più, è il Model Context Protocol: uno standard emergente che consente a un modello di linguaggio di scoprire e chiamare strumenti esterni, e che silenziosamente è diventato il tessuto connettivo che lega gli LLM all'arsenale di decenni di utilità di pentesting.
Questo post guarda a come quel boom è effettivamente strutturato. Il framing che fa notizia è "hacker IA autonomi," ma il modello durevole sottostante è più prosaico e più importante: server tool MCP che avvolgono gli strumenti esistenti e battle-tested — nuclei, sqlmap, ffuf, hydra, e dozzine di altri — e li espongono a un modello che può pianificare e sequenziare il loro uso. Capire quel modello è la chiave per capire sia la capacità offensiva che le implicazioni difensive.
Cosa MCP ha effettivamente cambiato
Per vedere perché MCP è importante qui, aiuta ricordare cosa fa. Il Model Context Protocol standardizza come un modello si connette ai strumenti e alle fonti di dati. Invece di ogni applicazione che codifica integrazioni bespoke, uno strumento si espone attraverso un server MCP, e qualsiasi client MCP-capable — Claude, Cursor, o un agente personalizzato — può scoprire gli strumenti disponibili, leggere i loro schemi, e invocarli. È, in effetti, un adapter universale tra i modelli di ragionamento e il mondo esterno. Alla data di un anno del protocollo l'ecosistema presumibilmente numerava bene oltre diecimila server pubblici, un'indicazione di quanto velocemente si è diffuso il modello.
La sicurezza offensiva si è rivelata una misura quasi ideale. Il campo aveva già centinaia di strumenti command-line matturi e scriptabili, ciascuno eccellente in un lavoro: port scanning, directory brute-forcing, SQL injection, attacchi alle credenziali, subdomain enumeration. Ciò che gli mancava era il ragionamento connettivo di scegliere quale strumento eseguire, interpretare l'output, e decidere la mossa successiva — il giudizio che un operatore umano fornisce. Questo è precisamente quello che un modello di linguaggio può fornire, se può chiamare i strumenti. MCP è il collegamento mancante. Avvolgi gli strumenti esistenti in un server MCP, punta un modello capace a lui, e hai un sistema che può pianificare un workflow, eseguire i giusti strumenti in sequenza, leggere i loro risultati, e adattarsi — senza che nessuno riscriva gli strumenti sottostanti.
Il modello server-tool, concretamente
Gli esempi più chiari di questo modello sono progetti che esplicitamente colmano gli LLM ai tool tradizionali. HexStrike AI si descrive come esattamente quello — un ponte tra gli LLM e un grande catalogo di strumenti di sicurezza convenzionali via MCP, consentendo a un agente di eseguire autonomamente scanner e utilità per la ricognizione, la scoperta di vulnerabilità, e l'automazione del bug-bounty. Un progetto correlato, emerso nel Help Net Security's monthly open-source roundup, avvolge all'incirca duecento strumenti offensivi dietro un singolo endpoint MCP raggiungibile da Claude Code, Cursor, o qualsiasi client MCP, e notevolmente ha aggiunto flag di guardrail — una modalità "intensity=safe", rispetto del rate-limit, e strict scope enforcement — per mantenere un agente troppo zelante dal vagare fuori i target autorizzati.
Quell'ultimo dettaglio vale la pena soffermarsi, perché rivela la curva di maturità. La prima generazione di questi strumenti ha ottimizzato per la capacità grezza: vedi quanto un agente può fare. L'iterazione successiva ha iniziato ad aggiungere i controlli che rendono la capacità usabile responsabilmente — scope locks, rate limiting, safe modes. Questo rispecchia come qualsiasi tool potente maturo, ma è arrivato insolitamente velocemente qui precisamente perché il lato negativo di uno scanner autonomo senza vincoli è così ovvio.
Oltre i wrapper, il boom include progettazioni più autonome: sistemi multi-agente che assegnano ruoli — un agente per la ricerca, un altro per l'esecuzione, un altro per l'infrastruttura — e orchestratori LLM-driven come PentestGPT che coordinano workflow di testing multi-step. Ma anche questi tendono a scendere al livello in cui accade il vero lavoro, su le stesse primitive affidabili. Il modello è il pianificatore e l'interprete; il vero scanning, fuzzing, e exploitation vengono ancora eseguiti attraverso strumenti che la comunità ha indurito nel corso degli anni. L'intelligenza è nuova; il muscolo è vecchio.
Perché avvolgere batte reinventare
È allettante immaginare la sicurezza offensiva IA come modelli che hackerano dai primi principi, generando exploit novel senza aiuto. Questo accade alla frontiera della ricerca, ma non è dove il valore pratico si trova nel 2026. Il valore è nell'orchestrazione, e la ragione è semplice: gli strumenti esistenti sono buoni. nuclei codifica migliaia di template di vulnerabilità mantenuti dalla comunità. sqlmap incarna anni di tecnica SQL-injection accumulata. ffuf e feroxbuster sono motori di content discovery veloci e ben sintonizzati. Ricostruire quella conoscenza dentro un modello sarebbe dispendioso e peggio; avvolgerla è economico e affidabile.
Quello che il modello aggiunge è il giudizio connettivo che in precedenza richiedeva un operatore esperto: leggere un risultato di nmap e decidere che un servizio esposto garantisce un template nuclei specifico, notare un parametro che sembra inettabile e consegnarlo a sqlmap con i flag giusti, riconoscere che un subdomain scoperto cambia l'ambito dell'engagement. Questa divisione del lavoro — il modello come pianificatore e interprete, gli strumenti stabiliti come esecutori — è l'architettura che effettivamente funziona, e MCP è quello che la rende componibile. Significa anche che l'ecosistema offensivo IA eredita l'affidabilità di strumenti che i difensori già capiscono, che ha conseguenze per l'altro lato della recinzione.
Una passeggiata attraverso una valutazione orchestrata da MCP
Per rendere il modello concreto, considera come appare una valutazione autorizzata di un'applicazione web quando un server tool MCP si siede tra il modello e il tool. L'operatore fornisce all'agente un ambito — un dominio che è autorizzato a testare — e un obiettivo. L'agente inizia con la ricognizione, chiamando uno strumento di enumerazione del subdomain e uno scanner di porta attraverso i loro wrapper MCP. Legge i risultati strutturati, nota un servizio web su una porta non standard, e ragiona che questo merita un'ispezione più profonda. Poi invoca uno strumento di content-discovery come feroxbuster per mappare le directory, legge le risposte, e nota un parametro che sembra potrebbe raggiungere un database.
A questo punto il modello fa quello che farebbe un operatore esperto: consegna quel parametro specifico a sqlmap con flag appropriatamente conservativi, interpreta il verdetto di sqlmap, e o eskalata o continua. Durante tutto questo, i guardrail su un server ben costruito stanno facendo un lavoro silenzioso — rifiutare target fuori dall'ambito dichiarato, throttling dei tassi di richiesta, e mantenere l'agente in una banda "safe" di intensità così che non, per istanza, lancia un payload distruttivo contro la produzione. L'intera sequenza è lo stesso insieme di strumenti che un umano avrebbe eseguito; quello che il modello contribuisce è il decision-making connettivo tra i step, e la velocità di esecuzione di quel loop senza pause caffè.
L'osservazione cruciale è che nessuna delle azioni individuali è novel. Ogni strumento in quella catena precede il boom dell'IA di anni. La novità è interamente nel livello di orchestrazione, ed è sia perché la capacità è affidabile sia perché è riproducibile: l'agente si erge su strumenti il cui comportamento è ben caratterizzato, piuttosto che improvvisando exploit i cui effetti sono impredittibili.
Dove gli approcci completamente autonomi ancora faticano
Sarebbe esagerare il quadro suggerire che questi sistemi sono un problema risolto. Il livello di orchestrazione eredita le limitazioni del modello che lo guida. Gli agenti ancora leggono male l'output ambiguo del tool, inseguono vicoli ciechi con confidenza, e occasionalmente inventano una conclusione che lo strumento sottostante non ha mai supportato. In ambienti complessi possono perdere il filo attraverso molti step, e rimangono deboli ai salti genuinamente creativi — concatenare diversi risultati sottili e individualmente benigni in un exploit novel — che distinguono gli operatori umani esperti. Il premio dell'automazione è l'ampiezza e la velocità su percorsi ben percorsi, non ancora l'ingegno di un red-teamer abile su un target difficile.
Questo è perché i più credibili deployment nel 2026 trattano questi strumenti come moltiplicatori di forza per gli operatori umani piuttosto che rimpiazzi. L'agente gestisce il largo, ripetitivo sweep — la ricognizione, lo scanning templato, la triage ovviamente inettabile — e affiora candidati per un umano da giudicare e inseguire. Quella divisione gioca alle forze di entrambi: la stancabilità della macchina e il giudizio dell'umano. Mantiene anche una persona responsabile dell'ambito e delle conseguenze, che importa enormemente in un dominio dove un errore non supervisionato può causare danno reale.
Cosa significa per i difensori
I takeaway difensivi sono meno allarmanti e più attuabili di quanto il framing "AI hackers" suggerisca. Il primo riguarda la velocità e il volume piuttosto che gli attacchi novel. Questi sistemi principalmente eseguono gli stessi strumenti che i difensori hanno sempre affrontato, ma li eseguono più velocemente, in sequenze meglio scelte, e su una scala più grande, abbassando l'expertise necessaria per condurre una valutazione competente. L'implicazione pratica è che il livello baseline di probing che ogni asset internet-facing riceve sta aumentando. I fondamentali — patching, attack-surface reduction, sensible rate limiting e anomaly detection — importano di più, non meno, perché il costo di probing è caduto.
Il secondo takeaway è che i segnali di detection largamente si trasportano. Un agente orchestrato da MCP che esegue nuclei e ffuf genera ancora i modelli di traffico di nuclei e ffuf. Lo scanning è riconoscibile; quello che è cambiato è l'orchestrazione sopra di esso. I difensori che già detectano mass directory brute-forcing o templated vulnerability scanning non stanno ricominciando da capo. Dovrebbero, però, aspettarsi campagne che si adattano più velocemente tra le fasi, perché il loop di pianificazione è ora automatizzato.
Il terzo, e più strategico, è che lo stesso modello è l'opportunità difensiva. MCP non è una tecnologia offensiva; è uno standard di integrazione neutro. L'approccio di avvolgimento identico si applica al tooling difensivo — esporre i tool di rilevamento, triage, e risposta a un modello che può correlare gli avvisi e orchestrare l'investigazione. Il lato offensivo si è mosso per primo perché i suoi strumenti erano insolitamente scriptabili e gli incentivi erano acuti, ma l'idea del tessuto connettivo è simmetrica. I team di sicurezza che valutano dove l'IA si adatta dovrebbero guardare al loro proprio catalogo di strumenti fidati e chiedere quale beneficerebbe da un livello di ragionamento che può sequenziarli.
Una cautela necessaria: tutto questo assume autorizzazione. La capacità che rende questi strumenti preziosi per i test autorizzati li rende pericolosi quando usati male, il che è esattamente perché i progetti responsabili hanno aggiunto enforcement dello scope e safe modes. Eseguire un agente offensivo autonomo contro sistemi che non possiedi o non hai esplicito permesso di testare è illegale e non etico, punto. I guardrail negli strumenti come quelli sopra esistono per una ragione, e dovrebbero essere trattati come obbligatori, non opzionali.
Costruire o valutare un server tool MCP in modo sicuro
Per i team che considerano di costruire il loro server MCP offensivo, o di valutarne uno prima dell'adozione, alcuni principi di ingegneria separano i progetti responsabili da quelli sconsiderati. L'enforcement dello scope dovrebbe essere strutturale, non advisory — il server dovrebbe rifiutare i target fuori-scope a livello di invocazione del tool, così che anche un agente confuso o jailbroken non possa fisicamente indirizzare un tool al di fuori del confine autorizzato. Il rate limiting appartiene allo stesso posto, proteggendo sia il target che l'operatore da un agente che decide di parallelizzare aggressivamente.
I controlli di intensità sono il prossimo livello: una modalità safe-by-default che disabilita le operazioni genuinamente distruttive a meno che non esplicitamente abilitate, con le capacità pericolose gated dietro la configurazione deliberata. L'auditability importa anche. Perché l'agente sta prendendo decisioni autonome, il server dovrebbe registrare ogni tool call, i suoi parametri, e il suo risultato, producendo una traccia riesaminabile di esattamente cosa è stato eseguito contro cosa. Quella traccia è essenziale sia per l'accountability del client sia per la ricostruzione di un engagement dopo. Lo strumento di maggio 2026 che ha spedito flag espliciti di "strict scope" e "respect rate limits" è un buon template precisamente perché rende questi controlli first-class e leggibili piuttosto che sotterrarli.
Per i difensori che valutano l'esposizione, la stessa architettura suggerisce un esercizio utile: assumi che un avversario abbia uno di questi orchestratori puntato al tuo perimetro e domandati se il tuo detection notirebbe. Poiché il traffico sottostante è uno scanning convenzionale, la risposta onesta per la maggior parte delle organizzazioni è che gli strumenti individuali sono detectabili ma la velocità di adattamento tra le fasi è la nuova variabile. Sintonizzare l'alerting per catturare pivot da ricognizione a sfruttamento rapidi, piuttosto che solo signature di scan isolate, è l'aggiustamento che il boom richiede.
Il bottom line
Il boom dell'IA di sicurezza offensiva del 2024–2026 è reale, ma la sua forma definitiva non è l'hacker IA solitario — è il server tool MCP: uno strato di ragionamento sottile su uno stack profondo di strumenti convenzionali e fidati. Quell'architettura è perché la capacità è affidabile, perché è scalata così velocemente, e perché le implicazioni difensive sono evolutive piuttosto che apocalittiche. Gli strumenti sono gli stessi; l'orchestrazione è nuova. Per i difensori, la mossa è raddoppiare i fondamentali, riconoscere che i detection esistenti si applicano ancora, e studiare lo stesso modello di avvolgimento per il guadagno difensivo. Il tessuto connettivo taglia in entrambi i modi — e il lato che integra i suoi strumenti fidati più attentamente otterrà il massimo da esso.
Riferimenti e risorse
Strumenti e progetti
Reporting e analisi
- Hottest cybersecurity open-source tools of May 2026 — Help Net Security
- The AI Offensive Security Boom: 70 Tools in 18 Months — Hadrian
- Top Open-Source AI Pentesting Tools for 2026 — RedFox Security
Cheatsheet correlati 1337skills