Por qué la CLI de NotHoly, no un asistente genérico

Un asistente de terminal que se niega a leer un disassembly o a bosquejar un payload sirve de poco para trabajo de seguridad. Uno que corre tus comandos en su propio servidor es peor, porque el tráfico a tu objetivo sale de una dirección que nadie puso en alcance. La CLI de NotHoly no hace ninguna de las dos. Corre en tu máquina, actúa solo con tu aprobación, y el modelo detrás acepta el trabajo en vez de darte un sermón. La metodología está en el caso de uso de pentest; esto es sobre la herramienta.

#Corre donde están tus herramientas

notholy abre un agente en tu proyecto. Lee y busca archivos, los edita y escribe, y corre un comando, y alcanza el lookup de CVE, la base de conocimiento y la búsqueda web. Cada comando y cada escritura corren en tu máquina, bajo tu usuario, y el modo por defecto pregunta antes de cada uno. El modo plan es solo lectura, auto-edit escribe sin preguntar pero aún pregunta para correr un comando, y yolo no pregunta nada y debe activarse en cada corrida. Los servidores de NotHoly nunca corren nada contra tus objetivos. Las notas del proyecto van en NOTHOLY.md, y el contenido de los archivos y la salida de los comandos se tratan como dato, nunca como instrucción al agente, así que un README plantado no puede redirigirlo. Los slash commands cambian el modelo, el modo y el esfuerzo de reasoning a media sesión, /cost muestra lo que la corrida gastó, y las sesiones quedan en ~/.notholy/sessions con permiso solo del dueño.

#Alcance que puedes imponer

notholy engage registra lo que una prueba puede tocar y revisa cada comando contra eso antes de correr. Le das un nombre, un alcance de hosts, comodines, IPs y CIDRs, una referencia a tu autorización, y una ventana de tiempo. Un comando en alcance pasa por la aprobación normal. Un objetivo fuera de alcance te hace escribir el host y registra la excepción, y yolo queda apagado mientras un engagement está activo. Cada decisión va a un log.jsonl con el comando, los objetivos, el código de salida y un hash de la salida, cada línea encadenada a la anterior, así que el registro es a prueba de manipulación. Las reglas viven fuera del repo, así que un repositorio no planta su propio alcance. La doc del agente de terminal tiene las flags.

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

#Haz pipe, o dirige otros agentes

Para una respuesta única, notholy "..." lee la entrada estándar, así que las herramientas que ya corres pueden alimentarlo.

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

notholy connect y notholy run apuntan Claude Code, Codex u OpenCode a los modelos de NotHoly y registran un servidor MCP local con las herramientas de CVE, advisory y base de conocimiento, así que un agente que ya usas gana esos datos sin una clave en su configuración. connect respalda la config de la herramienta primero y --undo la restaura, y la clave queda en el login de la propia CLI en vez del archivo de la herramienta. Una sesión larga se compacta antes de pasar el tamaño de contexto del modelo, con un resumen que guarda el objetivo, las decisiones y los hallazgos.

#Dónde no encaja

El guardián de engagement lee el texto de un comando y no resuelve DNS, así que atrapa un error, no un desvío decidido. No es un sandbox, y un comando aún puede llegar a un host que no nombra. yolo corre todo sin preguntar y puede cambiar archivos y correr comandos que no leíste, así que guárdalo para un directorio de borrador. Un comando que apruebas corre con tus propios permisos, así que lee la tarjeta antes de permitir. La CLI necesita un login, así que está atada a una cuenta y a un correo. El modelo puede equivocarse como cualquier modelo, y la salida es un borrador para revisar, no un resultado para confiar. Tampoco reemplaza los juicios: el alcance, la autorización y la decisión de correr son tuyos.

Mantén los comandos, los archivos y el riesgo en tu máquina, y deja que el modelo lea. Instala la CLI, luego pon un saldo pequeño en precios.