Agentes de IA para seguridad
Por qué automatizar recon y pruebas en la API de NotHoly
Pon en tu pipeline un modelo que no rechaza, con CVE, advisory y lectura de páginas públicas sin coste de tokens. Tus herramientas hacen lo activo.
El diseño de un pequeño agente de bug bounty: un LLM, un set de herramientas, memoria y guardrails, en un loop que corre en tu máquina bajo tu aprobación.
Un hackbot es un pequeño programa que pone un modelo de lenguaje en un loop con herramientas, para que corra parte de tu recon y tus pruebas por sí solo y pare por tu aprobación antes de que algo toque un objetivo. Este es el primero de tres posts que arman uno. Este es el diseño. La parte dos escribe el código, y la parte tres lo conecta a herramientas compartidas y al editor. Si los agentes son nuevos para ti, lee primero qué son los agentes de IA y el uso de herramientas.
Un hackbot automatiza el medio aburrido y repetible del loop: correr un comando de recon, leer su salida, decidir el siguiente comando, llevar notas. No es un atacante autónomo, y no deberías armar uno. El valor es un asistente incansable que propone pasos y registra lo que hizo, contigo sosteniendo las decisiones y el teclado para cualquier cosa que mande tráfico.
| Parte | Rol | En este armado |
|---|---|---|
| Modelo | Lee la salida, planea, llama herramientas | La API de NotHoly compatible con OpenAI |
| Herramientas | Lo que de verdad puede hacer | Comandos de shell que permites, más llamadas de investigación |
| Memoria | Lo que recuerda entre pasos | La lista de mensajes, más un archivo de notas en disco |
| Guardrails | Lo que no puede hacer | Chequeo de scope y aprobación antes de cada comando |
El modelo no actúa por su cuenta. Lee, planea y pide llamar una herramienta. Tu código decide si corre esa herramienta. Esta división es todo el diseño: el modelo es el cerebro, tu código son las manos, y las manos piden permiso.
El loop es corto. Mandas al modelo el objetivo y las herramientas que puede llamar. El modelo responde con texto o con un pedido de llamar una herramienta. Si pide una herramienta, tu código la corre, después de tu aprobación para cualquier cosa que toque un objetivo, y manda el resultado de vuelta. El modelo lee el resultado y decide el siguiente paso. Esto se repite hasta que el modelo dice que terminó o tú lo paras.
El modelo que usas es tu elección del catálogo. Lista los modelos con GET /v1/models y elige uno que soporte tool calling y un contexto bastante grande para tus notas. El código nunca fija un nombre de modelo; lee uno de la configuración, para que puedas cambiar sin tocar el loop.
Importan dos guardrails. El primero es el scope: antes de que corra cualquier comando, chequea su objetivo contra el scope del programa y rechaza o pausa en cualquier cosa fuera de él. El segundo es la aprobación: un comando que manda tráfico espera tu sí. No son extras opcionales; son la razón por la que la cosa es segura de correr.
Un tercer guardrail es más callado e igual de importante. La salida de las herramientas es dato, no instrucciones. Una página o un resultado de scan puede contener texto que se lee como un comando para el modelo, y un loop ingenuo lo seguirá. El OWASP Top 10 para Aplicaciones de LLM llama a esto prompt injection, su riesgo número uno. Tu loop tiene que tratar cada resultado de herramienta como entrada no confiable y nunca dejar que amplíe lo que el agente puede hacer.
El agente corre en tu máquina para que cada request salga de tu dirección, cada comando sea tuyo de aprobar y cada log sea tuyo de guardar. El modelo corre en la API de NotHoly, que hace inferencia y nada más: nunca escanea ni manda tráfico a un objetivo. Esa división es lo que hace al agente usable para bug bounty. El tráfico sale de donde el programa lo espera, y puedes probar qué enviaste.
Arma el loop y los guardrails tú mismo, porque son pequeños y porque necesitas entenderlos. Para las herramientas, reutiliza lo que existe: el shell que ya tienes, las herramientas de investigación que expone la CLI de NotHoly y, después, las herramientas compartidas de MCP. No escribas un framework. El próximo post es como cien líneas de Python.
La parte dos codea el loop con tool calling, aprobación y notas, usando el Model Context Protocol después en la parte tres.
Agentes de IA para seguridad
Pon en tu pipeline un modelo que no rechaza, con CVE, advisory y lectura de páginas públicas sin coste de tokens. Tus herramientas hacen lo activo.
Agentes de IA para seguridad
Un agente de bug bounty en Python con tool calling sobre la API de NotHoly: propone comandos de recon, espera tu aprobación, lee la salida y toma notas.
Agentes de IA para seguridad
Dale a tu agente herramientas compartidas por MCP, suma un chequeo de scope con notholy engage y corre todo desde la CLI de NotHoly o tu editor.