Saltar al contenido
Nuevo

DeepSeek V4.1 Flash gratis por 7 días: 10M tokens al día tras una recarga de $10 o más. Hasta el 30/11.

Cómo funciona

Arma tu hackbot, parte 1: arquitectura

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.

Intermedio3 min de lecturaPor NotHoly

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.

Qué es un hackbot, y qué no es

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.

Las cuatro partes

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 del agente

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.

Guardrails que lo mantienen en scope

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.

Por qué corre en tu máquina

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.

Qué armar y qué reutilizar

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.

Lo siguiente en esta serie

La parte dos codea el loop con tool calling, aprobación y notas, usando el Model Context Protocol después en la parte tres.

Fuentes

  1. NotHoly API: chat completions
  2. NotHoly API: list models
  3. OWASP Top 10 for LLM Applications 2025
  4. Model Context Protocol

Más en Agentes de IA para seguridad

Agentes de IA para seguridad

Arma tu hackbot, parte 2: codea el agente

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.

Intermedio3 min de lectura

Agentes de IA para seguridad

Arma tu hackbot, parte 3: herramientas MCP y CLI

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.

Intermedio3 min de lectura