Agenti di IA per la sicurezza
Perché automatizzare recon e test sulla API di NotHoly
Metti nella pipeline un modello che non rifiuta, con CVE, advisory e lettura di pagine pubbliche senza costo di token. I tuoi strumenti fanno l'attivo.
Un'IA che esegue exploit sul proprio server mette l'IP del fornitore sul tuo target, nasconde i passaggi e tiene i tuoi file. In un pentest non regge.
Drael esegue sul proprio server il codice scritto dal suo modello, e lo vende come funzione di punta. Per il lavoro di sicurezza è un difetto di progettazione. Il target vede l'indirizzo di Drael, che nel tuo perimetro non compare; i passaggi intermedi ti restano nascosti, e i termini fanno rispondere te del risultato.
Dati raccolti il 9 e il 10 novembre 2026 dal sito di Drael, dalla sua documentazione sui tool e dalle sue pagine legali, e dai prezzi di NotHoly. Non abbiamo aperto un account Drael né usato la sua sandbox: tutto ciò che segue è citato dalle sue pagine pubbliche.
La home page lo dice in una frase: "It writes the scanner, the exploit, the fix nothing else will, and the sandbox behind it is real: the network is a flag on the call, not a permanent no." In sostanza: scrive lo scanner, l'exploit e la fix, e la sandbox dietro è vera, con la rete che si accende con un flag nella chiamata. Il tool è run_code. Esegue Python o bash in un container sull'infrastruttura di Drael, dentro un ciclo lato server che arriva a dieci turni del modello.
Proprietà di run_code |
Valore nella documentazione di Drael |
|---|---|
| Dove gira | Sul server di Drael, un container per esecuzione |
| Rete | Spenta di default, accesa con network nella chiamata |
| Durata | 30 secondi di default, 5 minuti al massimo |
| Ciclo lato server | Fino a 10 turni; "You never see the intermediate turns" (i turni intermedi non li vedi mai) |
| File | "Files persist across calls in the same session" (i file restano da una chiamata all'altra nella stessa sessione) |
| Concorrenza | "One run at a time" per account, cioè un'esecuzione alla volta |
Il container protegge l'host di Drael dal tuo codice. Non fa nulla per l'host all'altro capo del flag network, che riceve gli stessi pacchetti da un indirizzo di Drael.
Di Drael. La sua pagina sulla privacy lo dice a proposito dei fetch: "A page you ask it to fetch sees a request from our server." La pagina che gli fai scaricare vede una richiesta dal server di Drael. Il codice che gira nel suo container con la rete accesa esce dalla stessa parte.
| Passaggio | Su Drael | Su NotHoly |
|---|---|---|
| Leggere una pagina pubblica | web_fetch, dal server di Drael, "including sites behind bot protection" (anche siti dietro protezione anti-bot) |
read_url, solo pagine pubbliche, attraverso un'uscita protetta contro SSRF |
| Mandare traffico a un host | run_code con network acceso, dal container di Drael |
Nessun tool lato server lo fa; la CLI lo esegue sulla tua macchina, dal tuo IP, dopo la tua approvazione |
Raggiungere un .onion |
web_fetch via Tor |
La ricerca elenca i risultati e non apre mai il .onion |
| Gestire un file | Allegato a un workspace sul server dove gira il codice del modello | I file caricati vengono analizzati in una sandbox gVisor e mai eseguiti |
| Vedere ogni passaggio | Fino a 10 turni lato server che non vedi | Ogni comando arriva a te per l'approvazione |
Il blue team del cliente lavora su un elenco di indirizzi sorgente. Il traffico da un indirizzo fuori da quell'elenco è un incidente, e come tale verrà gestito.
Le regole d'ingaggio dicono da dove parte un test. NIST SP 800-115, Appendice B, elenca gli IP autorizzati e non autorizzati nella sezione 4 e le sedi da cui il test è autorizzato nella sezione 2.3, con le firme nella sezione 7. PTES chiede un Permission to Test firmato e un'approvazione separata quando sono coinvolte terze parti.
Gli indirizzi di Drael non puoi dichiararli come tuoi, e il suo operatore non è parte del tuo accordo. I suoi stessi termini non lo nominano nemmeno, quindi non potresti aggiungerlo ai documenti neanche volendo.
Leggi come il 18 USC 1030 negli Stati Uniti e l'articolo 154-A del codice penale brasiliano ruotano attorno all'autorizzazione. Se un'autorizzazione che elenca i tuoi indirizzi copra anche il traffico partito da quelli di qualcun altro è una domanda per il tuo avvocato, e non vuoi fargliela dopo che il SOC del cliente ha aperto un ticket.
Un report deve dire cosa è stato inviato, quando, da dove e cosa è tornato indietro. La documentazione di Drael dice "You never see the intermediate turns". Quello che ricevi è il resoconto del modello su ciò che ha fatto. La OWASP LLM Top 10 chiama questa classe di problemi LLM06, Excessive Agency: un ciclo che compie azioni di rete senza alcun punto di controllo.
Anche i dati restano lì. La pagina sulla privacy elenca ciò che viene conservato: "Your conversations, image prompts, the code you ran and your instructions" (conversazioni, prompt per le immagini, il codice eseguito e le tue istruzioni), più "The files your code wrote, in that conversation's workspace, for up to three days after it was last used." Cioè i file scritti dal tuo codice, fino a tre giorni dopo l'ultimo uso del workspace. Il conteggio riparte a ogni utilizzo. NIST SP 800-115 chiede regole documentate per conservare e distruggere i dati di test (sezione 7.4). Su Drael l'output dei sistemi di un cliente sta su un disco gestito da un venditore di cui non conosci il nome. Se lo cancelli, la stessa pagina dice che le copie nei backup "leave as backups are rotated", cioè spariscono con la rotazione dei backup, secondo un calendario che non indica.
Tu. I termini di Drael dicono che eseguire una risposta o agire in base a essa "is your decision and your risk" (è una tua decisione e un tuo rischio), e che "If someone makes a claim against the operator because of how you used Drael or what you did with an answer, you take responsibility for it, including the reasonable cost of defending it." Se qualcuno avanza una pretesa contro l'operatore per come hai usato Drael, te ne fai carico tu, costi ragionevoli di difesa compresi.
Il traffico, quindi, lo manda il server di Drael, e i termini passano a te il conto, spese di difesa dell'operatore incluse. La responsabilità di Drael si ferma a tre mesi di canoni. Gli stessi termini aggiungono che "Nothing Drael says is legal, medical, financial or security advice." Niente di ciò che Drael dice vale come consulenza, nemmeno di sicurezza. Il resto è nella nostra lettura dei termini.
NotHoly tiene l'inferenza dalla nostra parte e l'esecuzione dalla tua. Nessun tool lato server fa scansioni, exploit o traffico attivo verso terzi. La CLI esegue i comandi sulla tua macchina, ciascuno con la tua approvazione, dall'indirizzo già elencato nelle tue regole d'ingaggio, e la traccia resta nella cronologia della tua shell e nella tua cattura di pacchetti.
Gestire e contenere l'ambiente, così, tocca a te, che è quello che un tester fa comunque. I tuoi prompt passano lo stesso dall'inferenza sul nostro lato: il contenuto dell'API non viene registrato, solo i metadati, e la cronologia della chat viene salvata a meno che tu non scelga una chat effimera. Come si incastra con il lavoro reale lo trovi in pentesting, red team e nella pagina dell'harness.
La sandbox lato server di Drael va bene per chi lavora da solo, vuole che il modello esegua il proprio codice e scarichi pagine senza mettere in piedi una macchina, e non manda quel traffico verso i sistemi di qualcun altro. NotHoly va bene per il lavoro con un perimetro firmato: inferenza dalla nostra parte, esecuzione dalla tua, ogni comando lanciato dal tuo indirizzo dopo che l'hai approvato, con la traccia nella cronologia della shell e nella cattura dei pacchetti. In cambio l'ambiente lo gestisci e lo contieni tu, che è comunque quello che fa un tester.
L'IP del posto in cui gira il codice. Con Drael è il server di Drael. Con una CLI sulla tua macchina è il tuo.
Sì, se esegue da una sede elencata nelle tue regole d'ingaggio e puoi registrare ogni comando. Uno strumento ospitato che manda il traffico in proprio richiede prima l'approvazione scritta del cliente.
Fino a tre giorni dopo l'ultimo uso, secondo la sua pagina sulla privacy, e il codice eseguito resta nella tua cronologia.
I termini di Drael mettono a tuo carico le pretese legate al tuo uso, compresi i costi ragionevoli di difesa dell'operatore.
No. L'infrastruttura non tocca i target, e i file caricati vengono analizzati senza essere eseguiti.
L'esecuzione lato server è la funzione con cui Drael si presenta, ed è il motivo per cui su un cliente non si può usare. Nasconde i passaggi, trasmette da un indirizzo fuori dal tuo perimetro, conserva l'output e scarica su di te la responsabilità. Noi abbiamo deciso di non costruirla. Se il tuo lavoro ha un perimetro firmato, leggi come la CLI gestisce l'approvazione, aggiungi US$ 5 dai prezzi di NotHoly e tieni i pacchetti sul tuo indirizzo. Perché i professionisti non portano un incarico su Drael applica lo stesso test al resto del prodotto.
Agenti di IA per la sicurezza
Metti nella pipeline un modello che non rifiuta, con CVE, advisory e lettura di pagine pubbliche senza costo di token. I tuoi strumenti fanno l'attivo.
Agenti di IA per la sicurezza
Il progetto di un agente di bug bounty: un LLM, dei tool, memoria e guardrail, in un loop che gira sulla tua macchina sotto la tua approvazione.
Agenti di IA per la sicurezza
Un agente di bug bounty in Python con tool calling sull'API NotHoly: propone comandi di recon, aspetta l'approvazione, legge l'output e tiene le note.