Pentester autónomo con IA: OIHK multi-agente

En pocas palabras: OIHK, publicado el 27 de agosto de 2026 por broskigx bajo licencia MIT, no es un LLM iterando en un loop: es un equipo multi-agente con una regla grabada en código —sin evidencia de ejecución real, no hay hallazgo—, y así elimina las vulnerabilidades inventadas.

Un desarrollador que firma como broskigx publicó el 27 de agosto de 2026 en dev.to el código de OIHK, un pentester autónomo con IA open source (licencia MIT) que corre local y no es un solo modelo iterando en un loop. Es un equipo de agentes con una regla dura grabada en código: sin evidencia de ejecución real, no hay hallazgo.

La diferencia suena a detalle, pero es el corazón de todo. La mayoría de los proyectos de “AI pentester” son un LLM con acceso a una shell corriendo comandos hasta que decide que encontró algo. ¿Y qué encontró? Muchas veces un reporte de vulnerabilidad hermoso sobre un bug que no existe.

OIHK es un motor de penetration testing autónomo y multi-agente que audita objetivos sin supervisión humana durante la corrida. Un planner raíz delega en agentes especialistas (reconocimiento, descubrimiento, validación y reporte) que comparten un estado revisionado y registros de ejecución inmutables. Solo el agente de validación puede transformar evidencia real en un hallazgo confirmado.

¿Qué es un pentester autónomo?

Un pentester autónomo es un sistema de software que ejecuta una auditoría de seguridad ofensiva de punta a punta sin que un humano tenga que ir aprobando cada paso. Descubre la superficie de ataque, prueba vectores, valida lo que encuentra y arma el reporte. La diferencia con un LLM suelto está en cómo llega a esas conclusiones.

Ponele que le das un objetivo a un “AI pentester” común. Arranca a tirar comandos, ve outputs, razona sobre ellos y en algún momento te escribe: “encontré un SQL injection acá”. El problema es que el modelo pudo haber alucinado la mitad. Escribió una prueba de concepto convincente para algo que nunca ejecutó.

OIHK ataca eso desde la arquitectura. En vez de un modelo en un while-loop con una shell, hay un planner raíz que reparte trabajo entre especialistas: uno hace recon, otro discovery, otro validación, otro el reporte. Todos comparten dos cosas concretas: un almacén de estado con historial de revisiones (concurrencia optimista, resume si se corta) y registros de ejecución inmutables. Los agentes no se coordinan “por vibra” en un chat log, reclaman pasos explícitos del plan, adjuntan evidencia real y actualizan el estado a través de ese store versionado.

Un detalle que me gusta: el raíz no puede cerrar una corrida mientras haya trabajo crítico abierto. No hay forma de que declare “listo, terminé” dejando validaciones colgadas.

¿Por qué no es solo otro wrapper de ChatGPT?

La diferencia entre un pentester IA de verdad y un wrapper de GPT está en la estructura: uno tiene roles especializados con responsabilidades explícitas y estado auditable, el otro es un modelo único que itera y guarda todo en su ventana de contexto. Esa distinción arquitectónica es lo que baja los falsos positivos.

Pensalo así. Cuando toda la lógica vive en un solo LLM que conversa consigo mismo, no hay separación de poderes. El mismo modelo que “cree” haber encontrado el bug es el que lo reporta. Nadie lo audita. Es juez y parte.

Acá viene lo interesante: al partir el trabajo en agentes con contratos claros, el que descubre no es el que valida. El agente de discovery puede sospechar de una vulnerabilidad, pero necesita que otro agente, con otras reglas, confirme con evidencia dura. Y como el estado pasa por un store revisionado en vez de un log de chat improvisado, podés reconstruir exactamente qué hizo cada uno y por qué. Eso, para cualquiera que haya intentado debuggear por qué un agente “decidió” algo raro, es oro.

¿Cuál es la regla de oro: sin evidencia, sin hallazgo?

La regla central de OIHK es que un hallazgo solo existe si hay tres cosas: ejecución real y exitosa de una herramienta gobernada, un registro de esa ejecución que es inmutable, y una validación independiente hecha por el agente de validación. Un LLM escribiendo una prueba de concepto convincente no es un hallazgo, por más seguro que suene.

Esta es la decisión de diseño alrededor de la cual está construido todo el proyecto. Según la publicación original del autor, la regla que más le importa es exactamente esa: “no evidence, no finding”.

¿Por qué es tan importante la validación de evidencia en pentesting? Porque la alucinación en seguridad no es un error simpático, es un desastre operativo. Un equipo que recibe un reporte con diez “vulnerabilidades críticas” fabricadas pierde horas persiguiendo fantasmas, y peor, empieza a desconfiar de la herramienta entera. Si no hay registro de ejecución y no hay validación separada, en OIHK eso nunca escala a hallazgo. No importa cuánta confianza muestre el modelo en su respuesta.

¿Cómo se garantiza la seguridad en un pentester autónomo con IA?

La seguridad de un pentester autónomo con IA se garantiza poniendo los guardrails en código real, no en instrucciones del prompt. Combinar herramientas ofensivas con agentes autónomos es peligroso si el único freno es un “portate bien” escrito en lenguaje natural. En OIHK las barreras son ejecutables, no sugerencias.

Estos son los controles que describe el autor:

• Modo PASSIVE como capa de política: no es una instrucción que el agente pueda ignorar. Las herramientas activas se rechazan aunque el agente intente colarlas por la shell genérica.
• Scope exacto con DNS pinning: declarar un dominio no autoriza sus subdominios ni las IPs que resuelva. Los hosts declarados se resuelven una vez y quedan fijados por DNS durante toda la corrida.
• Egress que falla cerrado: el scope declarado se compila en un allowlist de netfilter dentro del namespace de red propio de cada corrida, adentro del sandbox. En plataformas donde no se puede garantizar el aislamiento, el sistema aborta al arranque en lugar de fingir que está aislado.
• Sandbox endurecido: rootfs de solo lectura, capabilities eliminadas, no-new-privileges, ejecución sin root y sin superficie de sudo.

¿Por qué esto importa contra un prompt injection? Porque si alguien logra manipular al agente para que intente algo fuera de scope, el código no lo deja. La política vive en una capa que el modelo no puede sobrescribir hablando. Es la diferencia entre una cerradura y un cartel que dice “no pasar”.

¿Se puede cambiar el modelo IA sin reescribir el motor?

Sí. OIHK es agnóstico de proveedor: funciona con cualquier endpoint compatible con la API de OpenAI, con LM Studio como opción por default, sin ningún proveedor hardcodeado en el código. Y rutea modelos distintos según el rol de cada agente.

Esto abre una puerta práctica. Podés poner un modelo de razonamiento fuerte como planner, el que decide la estrategia general, y uno más rápido y barato para los especialistas que ejecutan tareas concretas. Optimizás costo y latencia sin tocar el motor.

El otro punto, quizás el más importante para muchos equipos, es la privacidad. Al correr local contra un endpoint tuyo, no le estás mandando el mapa de vulnerabilidades de tu infraestructura a una nube de terceros. Si vas a hostear el modelo o el objetivo en tu propia infraestructura, un VPS o servidor cloud en donweb.com te deja tener todo el pipeline puertas adentro. Para auditorías de seguridad, mantener la evidencia sin salir de tu perímetro no es un lujo, es sentido común.

¿Cómo se prueban y validan las herramientas de pentesting autónomo?

OIHK se valida a sí mismo funcionando como su propio entorno de evaluación: corre el motor contra 16 escenarios locales deliberadamente vulnerables y lo puntúa de forma determinista, nunca pidiéndole al modelo que se califique solo. Esa parte, dice el autor, es su favorita.

La lógica tiene sentido. Si le pedís a un LLM que evalúe su propio desempeño, tenés el mismo problema del juez y parte que veíamos antes. El modelo tiende a validar sus propias conclusiones. Al medir contra objetivos reales, con resultados verificables, el scoring deja de ser una opinión y pasa a ser un hecho.

Para CI/CD y demos hay un solver offline determinista que no necesita ni siquiera un modelo real. Se corre así:

uv run oihk eval run-all --model mock

Eso te da una corrida reproducible sin gastar tokens ni depender de la variabilidad de un LLM. Ideal para meter el motor en un pipeline de integración continua y detectar si un cambio rompió algo.

¿Cuáles son los casos de uso prácticos?

El pentesting autónomo sirve para auditoría continua, para poner security gates en el pipeline de CI/CD, para validar remediaciones después de un fix y para documentar hallazgos con evidencia auditable. La combinación de evaluación determinista y ejecución gobernada lo hace encajar en flujos de DevSecOps.

• Gate de seguridad en CI/CD: con el solver offline determinista podés bloquear un deploy si el motor detecta una regresión de seguridad, sin depender de una corrida cara ni no reproducible.
• Validación post-remediación: arreglaste un bug, corrés el motor de nuevo y confirmás con evidencia real que la vulnerabilidad ya no se reproduce.
• Auditoría con datos puertas adentro: al correr local, encaja en equipos con requisitos de compliance que no pueden mandar información sensible a la nube.
• Documentación auditable: como cada hallazgo tiene su registro de ejecución inmutable, el reporte no es la palabra del modelo, es una traza que podés revisar.

Eso sí: esto no reemplaza a un pentester humano. Un profesional entiende el contexto de negocio, encadena vulnerabilidades de formas creativas y sabe cuándo un hallazgo técnico “menor” es en realidad la llave de todo el castillo. La herramienta autónoma es un multiplicador para tareas repetibles y verificables, no un sustituto del criterio.

Qué está confirmado y qué queda pendiente

Confirmado (según la publicación del autor del 27/08/2026):

• Es open source con licencia MIT y corre local.
• Arquitectura multi-agente con planner raíz y especialistas de recon, discovery, validation y reporting.
• Regla “sin evidencia, no hay hallazgo” aplicada por un agente de validación separado.
• Guardrails en código: modo PASSIVE, DNS pinning, egress fail-closed con allowlist netfilter y sandbox endurecido.
• Provider-agnostic con routing de modelos por rol y 16 escenarios de evaluación con scoring determinista.

Pendiente o no informado: la fuente no da métricas de desempeño publicadas ni benchmarks comparativos contra otras herramientas, tampoco número de adopción, madurez en producción ni roadmap con fechas. Tomá el proyecto como lo que es hoy: una propuesta arquitectónica interesante y verificable, todavía sin un track record independiente que la respalde. Habría que ver cómo rinde en objetivos reales fuera de sus propios escenarios de test.

Errores comunes al evaluar un pentester autónomo

• Confiar en el reporte sin mirar la evidencia. Un hallazgo bien redactado no es un hallazgo real. Antes de accionar sobre cualquier salida de una herramienta IA, verificá que exista un registro de ejecución detrás. Justamente por esto OIHK separa validación de descubrimiento.
• Creer que un prompt de “sé cuidadoso” alcanza como control de seguridad. Si el freno vive en el prompt, un injection lo puede sortear. Los límites de scope y egress tienen que estar en código, como acá con el allowlist de netfilter y el DNS pinning.
• Dejar que el modelo se autoevalúe. Pedirle a un LLM que califique su propio trabajo infla los números. La medición tiene que ser determinista y contra objetivos verificables, no una nota que el propio modelo se pone.
• Asumir que autónomo significa “sin humanos nunca más”. El sistema audita solo durante la corrida, pero el alcance, la autorización y la interpretación final siguen siendo tarea de una persona. Correr esto contra un objetivo sin permiso es, además de una mala idea, ilegal.

Preguntas Frecuentes

¿Qué es un pentester autónomo?

Es un sistema de software que ejecuta una auditoría de seguridad ofensiva completa (descubrir, probar, validar y reportar) sin aprobación humana en cada paso. OIHK, publicado el 27/08/2026, lo implementa como un motor multi-agente open source que corre local, con un planner que delega en especialistas.

¿Cuál es la diferencia entre un pentester IA y un LLM en loop?

Un LLM en loop es un solo modelo con una shell corriendo comandos hasta que decide que encontró algo, y puede alucinar vulnerabilidades. Un pentester IA real como OIHK usa varios agentes con roles separados, estado revisionado y una regla que exige evidencia de ejecución real antes de declarar un hallazgo.

¿Por qué importa la validación de evidencia en pentesting?

Porque sin ella el sistema puede reportar vulnerabilidades que no existen, haciendo perder tiempo y confianza al equipo de seguridad. OIHK solo convierte algo en hallazgo si hubo ejecución real de una herramienta gobernada más un registro de validación independiente, no por la confianza que muestre el modelo.

¿Se puede usar cualquier modelo de IA con OIHK?

Sí. OIHK es agnóstico de proveedor y acepta cualquier endpoint compatible con la API de OpenAI, con LM Studio por default. Rutea modelos por rol, así podés usar uno potente como planner y uno rápido para los agentes especialistas, optimizando costo y latencia.

¿Reemplaza a un pentester humano?

No. Automatiza tareas repetibles y verificables con evidencia auditable, pero no reemplaza el criterio de un profesional para entender el contexto de negocio, encadenar vulnerabilidades de forma creativa y decidir el alcance y la autorización de la auditoría. Es un multiplicador, no un sustituto.

Conclusión

Lo que hace distinto a OIHK no es que use IA para pentesting, eso ya lo intentaron muchos. Es que puso el escepticismo en la arquitectura. La regla “sin evidencia, no hay hallazgo”, los guardrails en código en vez del prompt y la evaluación determinista contra 16 escenarios reales atacan el problema más molesto de estas herramientas: que suenan seguras cuando están alucinando.

Si estás en DevSecOps o armás herramientas de seguridad, vale la pena mirar el proyecto aunque sea por las ideas de diseño: separar descubrimiento de validación, versionar el estado de los agentes y hacer que el egress falle cerrado son patrones que sirven mucho más allá del pentesting. Ahora, ojo con la expectativa. Es un proyecto nuevo, sin benchmarks independientes ni track record en producción. Probalo en tus propios escenarios, con autorización explícita, y sacá tus conclusiones antes de meterlo en cualquier flujo serio.

Fuentes

• dev.to (broskigx) – I built an autonomous multi-agent AI pentester and why it’s not another GPT wrapper, publicación original del autor, 27/08/2026.