Vai al contenuto
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after a top-up of $10 or more. Until Nov 30.

How it works

Perché la CLI di NotHoly e non un assistente generico

L'agente gira sulla tua macchina con la tua approvazione, il modello accetta il lavoro di sicurezza, e un engagement controlla ogni comando.

Intermedio3 min di letturaDi NotHoly

Un assistente da terminale che rifiuta di leggere un disassembly o abbozzare un payload serve a poco per il lavoro di sicurezza. Uno che esegue i tuoi comandi sul proprio server è peggio, perché il traffico al tuo bersaglio esce da un indirizzo che nessuno ha messo nello scope. La CLI di NotHoly non fa nessuna delle due. Gira sulla tua macchina, agisce solo con la tua approvazione, e il modello dietro accetta il lavoro invece di farti la ramanzina. La metodologia è nel caso d'uso di pentest; qui si parla dello strumento.

Gira dove sono i tuoi strumenti

notholy apre un agente nel tuo progetto. Legge e cerca file, li modifica e li scrive, esegue un comando, e raggiunge il lookup CVE, la base di conoscenza e la ricerca web. Ogni comando e ogni scrittura girano sulla tua macchina, sotto il tuo utente, e la modalità di default chiede prima di ognuna. La modalità plan è di sola lettura, auto-edit scrive senza chiedere ma chiede ancora per eseguire un comando, e yolo non chiede nulla e va impostato a ogni esecuzione. I server di NotHoly non eseguono mai nulla contro i tuoi bersagli. Le note del progetto vanno in NOTHOLY.md, e il contenuto dei file e l'output dei comandi sono trattati come dato, mai come istruzione all'agente, così un README piazzato non può dirottarlo. Gli slash command cambiano il modello, la modalità e lo sforzo di reasoning a metà sessione, /cost mostra quanto ha speso l'esecuzione, e le sessioni stanno in ~/.notholy/sessions con permesso solo al proprietario.

Scope che puoi imporre

notholy engage registra cosa un test può toccare e controlla ogni comando contro quello prima che parta. Gli dai un nome, uno scope di host, wildcard, IP e CIDR, un riferimento alla tua autorizzazione, e una finestra temporale. Un comando nello scope passa dall'approvazione normale. Un bersaglio fuori scope ti fa digitare l'host e registra l'eccezione, e yolo è spento finché un engagement è attivo. Ogni decisione va in un log.jsonl con il comando, i bersagli, il codice di uscita e un hash dell'output, ogni riga concatenata alla precedente, così il registro è a prova di manomissione. Le regole stanno fuori dal repo, così un repository non piazza il proprio scope. La doc dell'agente da terminale ha i flag.

bash
notholy engage init --name acme-q4 --scope "*.acme-staging.test,10.20.0.0/24" --auth "contract 2026-117"

Fai pipe, o guida altri agenti

Per una risposta singola, notholy "..." legge lo standard input, così gli strumenti che già usi possono alimentarlo.

bash
git diff | notholy "review this diff for injection bugs"

notholy connect e notholy run puntano Claude Code, Codex o OpenCode ai modelli di NotHoly e registrano un server MCP locale con gli strumenti di CVE, advisory e base di conoscenza, così un agente che già usi guadagna quei dati senza una chiave nella sua configurazione. connect fa prima un backup della config dello strumento e --undo la ripristina, e la chiave resta nel login della CLI stessa invece che nel file dello strumento. Una sessione lunga viene compattata prima di passare la dimensione di contesto del modello, con un riassunto che tiene l'obiettivo, le decisioni e i reperti.

Dove non si adatta

Il guardiano dell'engagement legge il testo di un comando e non risolve il DNS, quindi coglie un errore, non un aggiramento deciso. Non è un sandbox, e un comando può ancora raggiungere un host che non nomina. yolo esegue tutto senza chiedere e può cambiare file ed eseguire comandi che non hai letto, quindi tienilo per una cartella di prova. Un comando che approvi gira con i tuoi permessi, quindi leggi la scheda prima di permettere. La CLI ha bisogno di un login, quindi è legata a un account e a una e-mail. Il modello può sbagliare come qualsiasi modello, e l'output è una bozza da controllare, non un risultato da fidarsene. Non sostituisce nemmeno i giudizi: lo scope, l'autorizzazione e la decisione di eseguire sono tuoi.

Tieni i comandi, i file e il rischio sulla tua macchina, e lascia che il modello legga. Installa la CLI, poi ricarica un saldo piccolo su prezzi.

Fonti

  1. NotHoly, Terminal agent
  2. NotHoly, CLI commands
  3. NotHoly, Connect and run
  4. NIST glossary, rules of engagement
  5. PTES, Pre-engagement Interactions

Altro su Strumenti di sicurezza

Strumenti di sicurezza

Il toolkit del bug bounty e la NotHoly CLI

Un toolkit di bug bounty per chi inizia, più la NotHoly CLI nel terminale con lo scope registrato così i comandi restano dentro il programma.

Base3 min di lettura

Strumenti di sicurezza

Perché l'estensione VS Code di NotHoly per la review

Review del file o del git diff nel tuo editor, con tutto il contesto. Il modello accetta la domanda di sicurezza e crea da un reperto un test o una regola.

Intermedio3 min di lettura

Strumenti di sicurezza

Le basi di Nmap nel tuo laboratorio

Nmap mappa le porte aperte sulla tua macchina. Impara connect scan e SYN scan, rilevamento dei servizi e file di output, poi abbina ogni porta al suo processo.

Base13 min di lettura