Construí un Agente de pentesting que aprende de sus errores : OIHK PENTESTING

Broskidev — Thu, 24 Sep 2026 02:51:23 +0000

Hace unas semanas publiqué la primera versión de OIHK-pentesting: un motor multi-agente que corre pentests autorizados con un planificador LLM, donde la frontera de seguridad vive en el motor, no en el "buen comportamiento" del modelo.

Desde entonces reconstruí la cabina entera. Este post va de lo nuevo — y de por qué la parte más difícil no fue hacer el agente más fuerte, sino hacer que se frene solo.

⚠️ Solo testing autorizado. Es una herramienta para gente con permiso escrito sobre los objetivos que apunta. El motor fuerza el scope igual — pero la responsabilidad es tuya.

Si quieres ver a OIHK en accion entra al github esta mas abajo 😈😈😈

Si preferís solo leer: escribís un objetivo, Baron lo detecta, planifica y la flota ejecuta. Así de simple.

1. Se acabaron los slash commands. Escribís el objetivo y listo.

La primera versión exponía "atajos de ataque" en la TUI. Estaba mal — el operador no tiene que memorizar maquinaria. Ahora:

$ uv run oihk start
> escanea 10.10.12.5

Baron (el copiloto interactivo) detecta el objetivo, planifica el assessment y delega los pasos de ataque él mismo. La TUI es chat; la inteligencia es suya.

2. La flota: 7 versiones de sí mismo en paralelo

Baron puede partir un plan en tareas sin solapamiento y lanzar siete subagentes reales en paralelo, cada uno un loop LLM completo ejecutando comandos reales dentro del sandbox Kali gobernado:

[Ari]   ▶ nmap -sV 10.10.12.5
[Bruma] ↳ 22/tcp open, 445/tcp open
[Ciro]  ✔ done — 3 candidatos a finding

Olas en segundo plano: lanza sin bloquear su propio turno, sigue planificando y junta reportes después con fleet_status (hasta 3 olas en vuelo).
Guards por unidad: corte por llamadas repetidas, breaker por fallos consecutivos, tope de rondas. Que una unidad crashee nunca tumba la ola.
Pre-flight de Docker: sin daemon, no hay ola.

3. AdapterOne: el agente que recuerda sus errores

La parte que más me entusiasma. Cada miss del assessment — un scan bloqueado, recon vacío, un pivot equivocado — se convierte en una lección ponderada con decay en un ledger JSONL local. En cada run futuro:

las lecciones más pesadas se inyectan en el prompt de Baron automáticamente,
puede consultarlas a mitad de run (adapterone_review),
puede grabar reglas nuevas él mismo (adapterone_confirm).

Mismo modelo, habilidad compuesta. Es RAG, pero el corpus son sus propios fracasos.

4. /power: el pedal del acelerador de tu máquina

Siete contenedores en paralelo fríen una laptop. Así que el operador tiene un presupuesto:

/power 0    # una instancia bajo demanda, spawn bloqueado
/power 30   # hasta 3 contenedores — las olas se recortan a eso
/power 100  # pool completo de 8

Bajar el presupuesto retira contenedores vivos al instante. El camino de ejecución nunca se bloquea — reutilizar la instancia viva y la primera bajo demanda siempre funcionan. Baron está instruido para no reintentar ni insistir cuando un spawn se rechaza: se adapta y sigue. Tu daemon de Docker sobrevive; tus ventiladores también.

5. Por qué el motor sigue sin confiar en el modelo

Todo lo anterior corre dentro del mismo stack de políticas que antes, porque agentes más fuertes necesitan rejas más fuertes:

Scope exacto, DNS-pinnado — declarar example.com NO autoriza sus subdominios.
Egress fail-closed — allowlist de netfilter dentro del namespace de red del propio sandbox; donde eso no se puede garantizar, el startup aborta.
Findings con evidencia obligatoria — un finding necesita una ejecución real, propia y exitosa por una tool gobernada más un registro de validación separado. Una historia convincente no prueba nada.
El agente nunca ve una shell cruda. Nunca.

Scorea 24/24 en su propio benchmark de escenarios vulnerables con el solver mock, y todo corre offline contra cualquier modelo local OpenAI-compatible.

Probalo

git clone https://github.com/Broskigx/Oihk-pentesting.git
cd Oihk-pentesting
uv sync
uv run oihk start

Licencia MIT, +1.300 tests pasando, beta temprana. Rompe fuerte — issues bienvenidas.

¿Qué querés que un agente de pentest autónomo aprenda primero de sus propios fracasos? Oihk Es tu opcion opensource y gratis

I built an autonomous multi-agent AI pentester — and why it's not another GPT wrapper

Broskidev — Thu, 27 Aug 2026 02:52:12 +0000

Most "AI pentester" projects are a single LLM in a while-loop with a shell. You
give it a target, it runs commands until it decides it found something. That's
how you get confident nonsense — a model that writes a beautiful vulnerability
report for a bug that doesn't exist.

I wanted the opposite: an engine where a finding has to be earned. So I built
OIHK — an autonomous, multi-agent
AI penetration-testing engine. It's open source (MIT) and runs locally.

Not one model in a loop — a team of agents

OIHK is a multi-agent engine. A root planner delegates to specialist agents —
recon, discovery, validation, reporting — that all share two things:

a versioned scan plan (optimistic concurrency, revision history, resume), and
an evidence ledger (immutable execution records).

Agents don't coordinate by vibes in a chat log. They claim explicit plan steps,
attach real evidence, and update state through a revisioned store. The root can't
close a run while critical work is still open.

The rule I care about most: no evidence, no finding

Here's the design decision the whole thing is built around:

An LLM writing a convincing PoC string is not a finding.

A finding requires a real, successful, governed tool execution and a
separate validation record. Only a validation agent can turn evidence into a
finding. If there's no execution record and no independent validation, it never
becomes a finding — no matter how confident the model sounds.

Safety enforced in code, not prompts

Offensive tools + autonomous agents is a scary combo if "be careful" is just a
line in a prompt. In OIHK the guardrails are actual code:

PASSIVE mode is a policy layer, not an instruction. Active tools are rejected even if the agent tries to route them through the generic shell.
Scope is exact. Declaring example.com doesn't authorize its subdomains or resolved IPs. Declared hosts are resolved once and DNS-pinned for the whole run.
Egress fails closed. The declared scope is compiled into a netfilter allowlist inside the sandbox's own per-run network namespace. On platforms that can't guarantee it, startup aborts instead of pretending to be isolated.
Hardened sandbox: read-only rootfs, dropped capabilities, no-new-privileges, non-root, no sudo surface.

Swap the model, keep the engine

OIHK is provider-agnostic. Any OpenAI-compatible endpoint works (LM Studio by
default), with per-role model routing and no hardcoded provider. You can run a
strong reasoning model as the planner and a fast one for the specialists.

It's also its own benchmark

This is my favorite part. OIHK doubles as an evaluation environment: it runs
the real engine against 16 local, deliberately vulnerable scenarios and scores
the model programmatically — never by asking a model to grade itself.

There's a deterministic offline mock solver for CI and demos:



bash
uv run oihk eval run-all --model mock

DEV Community: Broskidev