Due cose sono successe agli strumenti di sicurezza quando i grandi modelli di linguaggio sono diventati abbastanza capaci da usare gli strumenti. La prima è quella di cui tutti parlano: agenti IA che possono eseguire test di sicurezza, ragionare su un''applicazione come farebbe un ricercatore piuttosto che pattern-matching come uno scanner. La seconda riceve meno attenzione ma potrebbe importare di più giorno per giorno: i sistemi di IA stessi sono diventati una superficie di attacco, ed è una molto esposta. I team si sono affrettati ad auto-ospitare modelli e nel farlo hanno messo migliaia di server di inferenza, endpoint MCP e database vettoriali su internet pubblico senza alcuna autenticazione.
Questa guida copre entrambe le metà di quel cambiamento attraverso due strumenti dall''ondata di codice open-source di luglio 2026. Strix rappresenta il lato dell''agente offensivo: un penetration tester basato su IA che convalida i suoi risultati con exploit proof-of-concept funzionanti. AIMap rappresenta il lato dell''inventario difensivo: uno scanner che trova l''infrastruttura IA esposta a scala internet e punteggia quanto pericolosa sia l''esposizione. Insieme disegnano come appare il lavoro di sicurezza quando sia gli strumenti che gli obiettivi sono IA.
Il problema dei falsi positivi che gli agenti risolvono effettivamente
Per capire perché gli strumenti di sicurezza agentica hanno preso piede, devi capire il dolore specifico che affrontano. Gli strumenti di analisi statica sono economici da eseguire e catturano veri bug, ma generano risultati facendo corrispondere i modelli nel codice e una corrispondenza di modello è un''ipotesi, non una vulnerabilità confermata. Lo strumento dice "questa query del database concatena una variabile, che potrebbe essere SQL injection." Se è effettivamente una dipende dal fatto che quella variabile sia controllata dall''attaccante, se un sanitizer gira upstream, se il percorso del codice è raggiungibile. Rispondere a questo richiede una persona di tracciare la logica — e con poche centinaia di risultati per scansione, quel costo di triage è ciò che rende costoso l''strumenti di sicurezza e cosa fa sì che i team eventualmente smettano di leggere i rapporti.
L''approccio agentico inverte questo. Invece di segnalare un modello sospetto, un agente come Strix esegue l''applicazione, invia veri payload e conferma l''exploitabilità con un PoC funzionante. Se non può produrre un PoC, il risultato non appare. Ciò capovolge il triage da "investigare se è reale" a "verifica questa riproduzione", che è notevolmente più economico. Cattura anche un''intera classe di problema che l''analisi statica non può strutturalmente: difetti di business logic. Uno scanner non ha un modello di cosa la tua applicazione è supposata fare, quindi non può notare che un utente può applicare due volte un codice sconto o saltare un passo di pagamento. Un agente che ragiona sull''intenzione può.
Il trade-off è il costo e la velocità. Il test agentico esegue l''applicazione, itera e brucia token del modello, rendendolo molto più lento e costoso per esecuzione di una scansione statica che finisce in secondi. Quell''economia determina come usarlo: mantenere SAST veloce come Semgrep o Opengrep in esecuzione su ogni commit per l''ampiezza e riservare il test agentico per la profondità — valutazioni prima del rilascio, servizi di alto valore o aree dove i difetti di logica sono il vero rischio. Incorniciare questi come competitor è l''errore; rispondono a domande diverse a diversi punti di prezzo.
L''esposizione che nessuno ha pianificato
La seconda metà della storia è meno su strumenti intelligenti e più su un fallimento operativo prevedibile in scala. Eseguire un modello localmente è diventato genuinamente facile — Ollama e strumenti simili lo hanno reso un affare a un comando — e gli strumenti facili vengono distribuiti da persone che non stanno pensando all''esposizione di rete. La configurazione predefinita si lega a una porta locale; nel momento in cui qualcuno imposta OLLAMA_HOST=0.0.0.0 per raggiungerlo da un''altra macchina e quella macchina ha un IP pubblico, un''API di inferenza non autenticata è su internet.
Cosa può fare un attaccante con una? Più di quanto l''istinto "è solo una chatbot" suggerisca. Possono enumerare i tuoi modelli, il che rivela su cosa stai lavorando e talvolta trapela i fine-tune proprietari. Possono usare la tua GPU gratuitamente, eseguendo la loro stessa inferenza sulla tua elettricità e hardware — furto di risorse che si mostra come un picco di utilizzo misterioso. Dove l''endpoint fronteggia un''applicazione, potrebbero raggiungere prompt di sistema e le istruzioni che vincolano il modello. E con endpoint MCP le puntate si alzano notevolmente, perché i server MCP espongono strumenti — un endpoint MCP non autenticato può permettere a un attaccante di invocare vere azioni contro veri sistemi, non solo generare testo. I database vettoriali esposti sono ancora peggio: contengono i contenuti incorporati di qualunque documenti hai indicizzato, che per un sistema RAG è spesso i gioielli della corona.
Questa è la superficie che AIMap è costruita per inventariare. Scopre i servizi IA in una gamma, fingerprint cosa è in esecuzione e punteggi di esposizione basati su fattori come l''autenticazione mancante, l''elenco di modelli abilitato e gli inventari di strumenti raggiungibili. Usato difensivamente — puntato al tuo spazio di indirizzi — risponde a una domanda che la maggior parte delle organizzazioni non può attualmente rispondere: abbiamo infrastruttura IA esposta a internet e quanto è male? Data la velocità con cui l''IA auto-ospitata si è diffusa attraverso i team senza una revisione di sicurezza, l''onesta risposta per molti è "non sappiamo" e questo è esattamente il motivo per cui questa categoria di strumento è apparsa.
Uso degli strumenti offensivi senza causare danni
Entrambi gli strumenti portano vero rischio di abuso e essere chiari su questo è parte dell''usarli competentemente. Strix genera exploit funzionanti. AIMap esegue la scoperta su scala internet e test di attacco a livello di protocollo. Eseguire l''uno o l''altro contro i sistemi che non possiedi o per i quali non hai il permesso scritto di testare è illegale nella maggior parte delle giurisdizioni, indipendentemente dall''intenzione e "stavo solo controllando" non è una difesa.
I safeguard pratici sono poco glamour ma non negoziabili. Ambito esplicito: dichiara esattamente quali host o intervalli sono in gioco e configura lo strumento per rifiutare qualsiasi cosa, quindi una configurazione errata non può vagare. Preferisci staging a produzione: un agente che sonda un sistema dal vivo può creare record, attivare workflow o esaurire risorse — le stesse azioni che rendono il test prezioso lo rendono dirompente. Sandbox l''agente: eseguilo in un contenitore con uscita di rete vincolata, sia per limitare il raggio di esplosione sia perché un agente che scrive ed esegue codice di exploit è, strutturalmente, eseguendo codice non attendibile. Rivedi i PoC generati prima di archiviarli o rieseguirli. E ottieni l''autorizzazione per iscritto prima di qualsiasi impegno, inclusi quelli interni.
C''è una dimensione di governance troppo. Questi strumenti riducono la competenza richiesta per condurre test offensivi competenti, il che è buono per i difensori con team piccoli e altrettanto buono per gli attaccanti. Quella simmetria non è una ragione per evitare gli strumenti — i difensori traggono vantaggio dal test dei loro sistemi come farebbe un attaccante — ma significa che il livello di base di probing che ogni asset internet-facing riceve sta salendo. I fondamentali importano di più, non meno.
Un''esposizione concreta, dall''inizio alla fine
Per rendere la superficie di attacco dell''IA tangibile, cammina attraverso come un''esposizione realistica accade e cosa fa un attaccante. Uno scienziato di dati vuole testare un modello dal loro laptop contro un server in ufficio, quindi imposta OLLAMA_HOST=0.0.0.0 e riavvia il servizio. L''host per caso si trova su una VM cloud con un IP pubblico e un security group permissivo rimasto da un esperimento precedente. Nulla di questo si sente come una decisione di sicurezza — è un cambiamento di convenienza di due minuti — e nessun ticket viene depositato.
Entro giorni gli scanner automatizzati trovano la porta 11434 che risponde. Un attaccante interroga /api/tags e ottiene l''elenco completo dei modelli sulla scatola, incluso un modello internamente fine-tuned il cui nome da solo rivela il progetto che supporta. Quindi usano il server per la loro stessa inferenza: è una GPU senza limite di velocità con nessuna autenticazione, quindi eseguono carichi di lavoro su di essa gratuitamente, che il team eventualmente nota come utilizzo inspiegato e una fattura cloud confusa. Se quello stesso host fronteggia anche un''applicazione RAG, l''esposizione si approfondisce — un attaccante che può raggiungere il database vettoriale può recuperare i chunk incorporati di qualunque corpus sia stato indicizzato, che potrebbe essere documentazione interna, ticket di supporto o record dei clienti.
La variante peggiore comporta MCP. Se l''host espone un server MCP, i suoi strumenti sono invocabili e quegli strumenti esistono precisamente perché fanno qualcosa di utile — interrogare un database, chiamare un''API interna, scrivere un file. Un endpoint MCP non autenticato non è un giocattolo da chat; è un''interfaccia di procedure remota non autenticata in qualunque cosa i strumenti raggiungono.
Ogni passo di quella catena è prevenuto dai controlli che l''industria ha compreso per vent''anni: lega a localhost, richiedi l''autenticazione, restringi il security group, monitora il traffico anomalo. Ciò che rende il caso dell''IA distintivo non è la sofisticazione dell''attacco ma la velocità e l''informalità del deployment — questi servizi vengono eretti da persone che risolvono un problema immediato, fuori dal processo di revisione che catturerebbe un database esposto. Questo è il motivo per cui uno strumento di scoperta puntato ai tuoi intervalli vale un pomeriggio: la modalità di fallimento non è attaccanti intelligenti, è infrastruttura invisibile.
Dove il test agentico ancora cade corto
Sarebbe un disservizio presentare gli strumenti di sicurezza agentica come oltre dove sono, perché sovrastimandoli porta esattamente alla decisione sbagliata — trattare un''esecuzione dell''agente come sostituto di una vera valutazione. Diverse limitazioni meritano di essere nominate chiaramente.
La copertura è disomogenea e difficile da caratterizzare. Uno scanner ti dice quali regole ha eseguito; un agente esplora in base al suo giudizio, il che significa che due esecuzioni contro lo stesso target possono sondare cose diverse. Quel non-determinismo rende difficile rispondere a "cosa abbiamo effettivamente testato?" — una domanda a disagio durante un audit. Tratta i risultati degli agenti come prove di ciò che è rotto, non come prove che tutto il resto va bene.
La profondità in territorio sconosciuto è limitata. Gli agenti hanno buone prestazioni su classi di vulnerabilità ben documentate con dati di training abbondanti — iniezione, XSS, controllo dell''accesso. Si comportano molto peggio su logica genuinamente nuova, protocolli oscuri o il chaining creativo di diversi risultati individualmente benigni in un exploit serio. Quel chaining è precisamente l''abilità che distingue un tester umano esperto e rimane il gap più chiaro.
Il costo scala con la completezza. Ogni probe aggiuntivo è token del modello e tempo wall-clock. I team che scatenano un agente su un''applicazione grande senza ambito scoprire questo nella loro fattura. Limitare i servizi e i flussi che effettivamente importano non è solo un controllo di sicurezza; è un controllo dei costi.
E l''output ha ancora bisogno di giudizio. Un PoC convalidato prova l''exploitabilità nell''ambiente di test, non che il risultato sia una priorità aziendale. Severità, raggiungibilità da internet reale e cosa un attaccante guadagnerebbe sono ancora chiamate umane. L''inquadramento onesto è che gli agenti comprimono la parte noiosa del test — enumerazione, probing, convalida del primo passaggio — mentre lasciano le parti che richiedono contesto e creatività dove erano.
Cosa questo significa per i difensori
Tirando i fili insieme, poche implicazioni concrete seguono per chiunque stia gestendo sistemi nel 2026.
Inventario la tua infrastruttura IA come inventario tutto il resto. Il modello di deployment ombra — uno scienziato di dati monta un server di inferenza per un esperimento, un team crea un database vettore per un prototipo — significa che la superficie di attacco dell''IA è frequentemente non documentata. Scansionare i tuoi intervalli con uno strumento come AIMap è un esercizio di un pomeriggio che spesso scopre sorprese genuine. Rendilo ricorrente, non una tantum, perché il prossimo deployment non rivisto è sempre una settimana di distanza.
Applica controlli ordinari a sistemi straordinari-sembranti. Le correzioni per l''infrastruttura IA esposta non sono esotiche: lega i servizi a localhost, metti un proxy inverso di autenticazione davanti a qualsiasi cosa che deve essere raggiungibile, applica la politica di rete così la porta 11434 non sia mai pubblicamente instradabile, rate-limit e monitora il traffico di inferenza inaspettato. Questa è la stessa igiene che si applica a un database — il fallimento è stato trattare i servizi di IA come giocattoli esenti da esso.
Tratta gli endpoint MCP come privilegiati. Perché i server MCP espongono gli strumenti che compiono azioni, uno esposto è più vicino a un endpoint RPC non autenticato che a un''API di chat. Inventario quali strumenti ogni server espone, richiedi l''autenticazione e applica il principio del minore privilegio a ciò che quegli strumenti possono raggiungere.
Strato il tuo test per costo. Analisi statica veloce su ogni commit (Semgrep, Bearer per il rischio di flusso di dati), analisi di dipendenze e SBOM continuamente (Dependency-Track), DAST di crawling su un programma (ZAP) e test convalidato agentico dove la profondità giustifica la spesa. Ogni livello copre ciò che gli altri strutturalmente mancano, e nessuno strumento — per quanto intelligente — è completo.
La linea di fondo
L''IA ha rimodellato gli strumenti di sicurezza da entrambe le direzioni contemporaneamente. Offensivamente, agenti come Strix attaccano il problema dei falsi positivi convalidando i risultati con exploit funzionanti e ragionando sulla logica aziendale che i pattern matcher non possono modellare — potente, ma abbastanza lento ed economico che appartiene insieme a SAST veloce piuttosto che sostituirlo. Difensivamente, la corsa ad auto-ospitare modelli ha creato una superficie di attacco diffusa e in gran parte non inventariata di server di inferenza esposti, endpoint MCP e database vettoriali, che strumenti come AIMap esistono per trovare. Inventario la tua infrastruttura IA, applica i controlli noioso che già funzionano, tratta gli endpoint MCP che espongono gli strumenti come privilegiati, strato il tuo test per costo e ottieni l''autorizzazione per iscritto prima di puntare qualunque di questo a qualsiasi cosa. Gli strumenti sono genuinamente migliori di prima; la disciplina richiesta per usarli bene non è cambiata.
Riferimenti e risorse
Strumenti
Background and analysis
- 20 open-source cybersecurity tools to keep your team ready — Help Net Security
- Best Open Source AppSec Tools for 2026 — Orca Security
- Top Cybersecurity Open-Source Tools — News4Hackers
Related 1337skills cheatsheets