Por que a CLI da NotHoly, não um assistente genérico

Um assistente de terminal que recusa ler um disassembly ou rascunhar um payload serve de pouco para trabalho de segurança. Um que roda os seus comandos no próprio servidor é pior, porque o tráfego ao seu alvo sai de um endereço que ninguém colocou no escopo. A CLI da NotHoly não faz nenhum dos dois. Ela roda na sua máquina, age só com a sua aprovação, e o modelo por trás aceita o trabalho em vez de te dar sermão. A metodologia está no caso de uso de pentest; aqui é sobre a ferramenta.

#Ela roda onde as suas ferramentas estão

notholy abre um agente no seu projeto. Ele lê e busca arquivos, edita e escreve, e roda um comando, e alcança o lookup de CVE, a base de conhecimento e a busca web. Todo comando e toda escrita rodam na sua máquina, sob o seu usuário, e o modo padrão pergunta antes de cada um. O modo plan é só leitura, auto-edit escreve sem perguntar mas ainda pergunta para rodar um comando, e yolo não pergunta nada e tem que ser ligado a cada rodada. Os servidores da NotHoly nunca rodam nada contra os seus alvos. As notas do projeto vão no NOTHOLY.md, e o conteúdo dos arquivos e a saída dos comandos são tratados como dado, nunca como instrução ao agente, então um README plantado não consegue redirecioná-lo. Os slash commands trocam o modelo, o modo e o esforço de reasoning no meio da sessão, /cost mostra o que a rodada gastou, e as sessões ficam em ~/.notholy/sessions com permissão só do dono.

#Escopo que você consegue impor

notholy engage registra o que um teste pode tocar e checa cada comando contra isso antes de rodar. Você dá um nome, um escopo de hosts, wildcards, IPs e CIDRs, uma referência à sua autorização, e uma janela de tempo. Um comando no escopo passa pela aprovação normal. Um alvo fora do escopo faz você digitar o host e registra a exceção, e yolo fica desligado enquanto um engajamento está ativo. Cada decisão vai para um log.jsonl com o comando, os alvos, o código de saída e um hash da saída, cada linha encadeada à anterior, então o registro é à prova de adulteração. As regras ficam fora do repo, então um repositório não planta o próprio escopo. A doc do agente de terminal tem as flags.

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

#Faça pipe, ou dirija outros agentes

Para uma resposta única, notholy "..." lê a entrada padrão, então as ferramentas que você já roda podem alimentá-lo.

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

notholy connect e notholy run apontam Claude Code, Codex ou OpenCode para os modelos da NotHoly e registram um servidor MCP local com as ferramentas de CVE, advisory e base de conhecimento, então um agente que você já usa ganha esses dados sem uma chave na configuração. O connect faz backup da config da ferramenta primeiro e --undo restaura, e a chave fica no login da própria CLI em vez do arquivo da ferramenta. Uma sessão longa é compactada antes de passar o tamanho de contexto do modelo, com um resumo que guarda o objetivo, as decisões e os achados.

#Onde não encaixa

O guarda de engajamento lê o texto de um comando e não resolve DNS, então ele pega um erro, não um desvio decidido. Não é um sandbox, e um comando ainda pode chegar a um host que ele não nomeia. yolo roda tudo sem perguntar e pode mudar arquivos e rodar comandos que você não leu, então guarde isso para um diretório de rascunho. Um comando que você aprova roda com as suas próprias permissões, então leia o cartão antes de permitir. A CLI precisa de login, então está ligada a uma conta e a um e-mail. O modelo pode errar como qualquer modelo, e a saída é um rascunho para conferir, não um resultado para confiar. Ela também não substitui as decisões de juízo: o escopo, a autorização e a decisão de rodar são suas.

Mantenha os comandos, os arquivos e o risco na sua máquina, e deixe o modelo ler. Instale a CLI, depois ponha um saldo pequeno em preços.