Cómo evitamos que un pentester autónomo se vuelva peligroso

Un agente que sabe encontrar vulnerabilidades es útil contra tu propio sitio y peligroso contra el de cualquier otro. Esa es la tensión de fondo de AI Hackers: corre pruebas de penetración autónomas contra la superficie de un cliente y entrega un reporte, sin un operador conduciendo cada paso. Lo interesante de construirlo no fue enseñarle a atacar. Fue enseñarle a no hacerlo cuando no debe.

Este texto es sobre esa parte: cómo garantizamos que el agente solo toque lo que le autorizaste, y nada más.

La autorización es la primera pregunta, no la última

Antes de cualquier trabajo contra un objetivo, el flujo hace una sola pregunta y no continúa sin respuesta: ¿el dominio pertenece a un cliente que lo autorizó, y qué alcance exacto optó por incluir? Si la respuesta es no, o si no está confirmada, el agente no crea la carpeta del objetivo y no corre el flujo. No hay una segunda ruta que se salte esto.

Cuando la respuesta es sí, la confirmación se documenta antes de recolectar un solo dato: quién autorizó, cuándo, qué pidió, y el alcance en concreto: dominios, IPs, aplicaciones, acciones. Todo lo que no está en esa lista está fuera de alcance hasta que el cliente lo agregue de forma explícita. El alcance controla el trabajo, no la curiosidad del agente.

Tres niveles de lo que puede hacer

Dentro del alcance confirmado, el trabajo está dividido por qué tan invasivo es.

El primer nivel es no destructivo por definición: sin escrituras, sin inicios de sesión, sin cambios de estado, sin peticiones que alteren nada. Una vez confirmada la propiedad del objetivo, el agente corre toda la superficie no destructiva sin volver a preguntar, porque esa es la parte que un cliente espera de una evaluación completa. Enumerar, mapear, leer: eso procede solo.

El segundo nivel necesita opt-in explícito para cada cosa: agregar un apex nuevo tras confirmar propiedad, usar una cuenta desechable para un flujo de registro. Nunca se agrega un dominio de terceros ni un SaaS, aunque aparezca en el mapa.

El tercer nivel son los límites duros que se sostienen sin importar qué autorice el cliente: nada destructivo, nada de pruebas de carga o denegación de servicio, nada que pueda degradar un servicio en producción, nunca iniciar sesión con credenciales filtradas. Si el trabajo requiere cruzar uno de esos límites, el agente se detiene y escala a un operador humano. Un cliente no puede autorizarnos a tumbarle su propio sitio.

Por qué esto importa más que la ofensiva

Un pentester autónomo sin estos frenos es una herramienta que apunta a donde sea que la mandes, y eso lo vuelve imposible de operar de forma responsable. El valor no está en que el agente sepa encontrar una inyección; está en que puedas dejarlo correr sabiendo exactamente qué va a tocar y qué no. La restricción es lo que lo hace desplegable frente a un cliente real.

Pruébalo contra tu propio dominio

Construimos AI Hackers para los clientes de iNBest que quieren una evaluación de seguridad continua sin montar un equipo de red team. Está en línea y puedes probarlo con un sitio que sea tuyo.

Entra a aihackers.inbest.cloud, envía el dominio que quieres evaluar con el alcance que autorizas (los dominios y aplicaciones que sí quieres que toquemos), y un correo de contacto. Recibes de vuelta un identificador para seguir el estado de la evaluación, y el reporte cuando termina. Todo el trabajo se queda dentro del alcance que definiste y en el nivel no destructivo.

Estamos afinando el producto y nos sirve el detalle: dinos si el reporte fue accionable, si el alcance se sintió claro, si algo te preocupó. Escríbenos a hello@inbest.cloud. Si encuentras algo que el agente debió detectar y no lo hizo, eso es justo lo que queremos oír.