Prompts de pentesting con IA que producen evidencias, no solo hallazgos
Guía práctica para diseñar flujos de trabajo de pruebas de seguridad asistidas por IA que conviertan evidencias acotadas en hallazgos revisables mediante salidas estructuradas, puertas de validación y ejecución controlada.
Usted le pide al modelo que encuentre una vulnerabilidad
Imagine que le ha llegado una API nueva. Contiene decenas de rutas, un middleware que no conoce y código suficiente para mantener ocupado a un revisor durante días.
Prompt dado al modelo: «Revisa este repositorio y encuentra vulnerabilidades de seguridad».
Unos instantes después llega la respuesta. Menciona inyección SQL, secretos incrustados en el código, comprobaciones de autorización ausentes y deserialización insegura. Está organizada, es categórica y tiene el formato de un informe de seguridad.
Punto de decisión: ¿La enviaría al equipo de ingeniería?
Todavía no. Primero determine qué probó realmente el modelo. Quizá ningún endpoint se rastreó desde la solicitud hasta la base de datos. Ninguna entrada llegó a un sumidero peligroso. No se ejercitó ninguna decisión de autorización. No se comprobó ninguna condición de explotabilidad. La salida puede contener hipótesis útiles, pero una hipótesis todavía no es un hallazgo.
Aquí es donde las pruebas de seguridad asistidas por IA se vuelven útiles o se convierten en ruido. El reto no es lograr que un modelo suene como un pentester. Es pasar de una petición amplia a una pregunta concreta, de esa pregunta a las evidencias y de las evidencias a un resultado que otro ingeniero pueda reproducir.
Reconstruyamos la prueba decisión a decisión.
Primero, elija una pregunta que valga la pena responder
Entre las pistas generadas hay un posible problema de autorización en GET /v1/invoices/{id}.
Afirmación inicial: «El endpoint podría exponer facturas pertenecientes a otros usuarios».
Evidencia necesaria: identificar al propietario del recurso, localizar el control de autorización, comprender el acceso del atacante y observar qué ocurre cuando un usuario autenticado solicita la factura de otra cuenta.
Objetivo de la prueba: determinar si un usuario autenticado puede obtener una factura que pertenece a una cuenta diferente mediante GET /v1/invoices/{id}.
El objetivo se ha reducido, pero la investigación se ha profundizado. Ahora tiene una interfaz, un límite de propiedad, una capacidad del atacante y una condición de éxito.
El mismo cambio funciona en todos los ámbitos de la seguridad:
| Petición amplia | Pregunta que el flujo de trabajo puede responder |
|---|---|
| Revisar los intents de Android | En la actividad exportada ShareActivity, ¿puede un extra controlado por el atacante llegar a un componente privilegiado sin validación? |
| Buscar inyecciones | ¿Puede el parámetro de consulta sort llegar a una operación de consulta dinámica sin un tratamiento seguro? |
| Encontrar secretos almacenados | ¿Se escribe el valor sensible sospechoso en el almacenamiento de la aplicación y se puede recuperar bajo el modelo de atacante indicado? |
Esto es el aislamiento contextual en la práctica. En lugar de volcar un repositorio completo en el modelo, proporcione la definición de la ruta, el middleware pertinente, el handler, el código de acceso a datos, las pruebas y las evidencias observadas de solicitudes o respuestas.
Ahora el modelo tiene menos material por el que divagar y una pregunta clara que responder.
Después, decida qué contará como prueba
Supongamos que el modelo lee el handler de facturas y devuelve:
Afirmación inicial: «El endpoint es vulnerable a IDOR porque obtiene una factura por ID».
Veredicto: todavía no. Obtener un objeto por ID es un comportamiento normal de la aplicación. La pregunta decisiva es si se aplica la propiedad u otra política de autorización antes de devolver la respuesta. Ese control puede existir en un middleware, en una capa de servicio, en una consulta a la base de datos o en una función de políticas fuera del código visible.
Antes de pedir una conclusión, dé a la tarea un contrato de evidencias. Exija que el flujo de trabajo devuelva la ruta de código inspeccionada, la capacidad del atacante, el control de autorización esperado, la solicitud y la respuesta de validación y un estado de confirmed, needs_validation o not_reproduced.
La salida estructurada no hace que una afirmación sea cierta. Hace visible la prueba que falta.
task:
id: api-object-authorization-001
vulnerability_class: broken_object_level_authorization
target:
method: GET
path: /v1/invoices/{id}
owner_boundary: account_id
objective: >
Determine whether an authenticated user can retrieve an invoice that belongs
to a different account.
permitted_actions:
- Read source files listed in context.
- Inspect supplied test traffic and test fixtures.
- Generate a test request only against the approved staging target.
required_evidence:
- Authorization check location or its absence.
- Request and response identifiers for the cross-account test.
- Expected versus observed authorization result.
output_rules:
- Do not report a confirmed vulnerability without runtime or test evidence.
- Return needs_validation when execution is unavailable.
- Cite every conclusion with an evidence reference.
El contrato introduce una regla que debería sobrevivir a todas las revisiones del prompt:
Sin evidencia, no hay confirmación.
A continuación, deje que cada resultado elija el siguiente paso
El modelo rastrea la ruta. Encuentra un middleware de autenticación y una consulta a la base de datos que carga una factura por su identificador. Sigue sin encontrar una condición de propiedad.
Siguiente decisión: no genere otra explicación. Elija la siguiente prueba que pueda reducir la incertidumbre. El flujo de trabajo necesita un bucle controlado:
- Planificar: identificar la pregunta más pequeña que reduciría la incertidumbre.
- Recopilar: obtener el código fuente, la fixture, el tráfico o la salida de herramienta aprobada que sean pertinentes.
- Analizar: conectar la evidencia con el control de seguridad que se está revisando.
- Validar: reproducir una solicitud, ejecutar una prueba segura, inspeccionar una traza o solicitar una revisión humana.
- Decidir: confirmar el hallazgo, acotar la hipótesis o detenerse.
Para el endpoint de facturas, utilice dos cuentas de preproducción controladas por el tester. Haga que la cuenta A cree una factura que contenga un marcador único y no sensible. Primero confirme que la cuenta A puede obtenerla mediante el endpoint probado. Después autentíquese como la cuenta B y solicite el mismo identificador.
Pregunta de validación: ¿qué resultado demostraría el problema?
Si la cuenta B recibe el marcador único de la cuenta A, la prueba demuestra un acceso entre cuentas, pero solo si las facturas son privadas y las cuentas no tienen ninguna relación de compartición. Una denegación muestra que la ruta probada aplicó el límite en este caso. Si falta la referencia de base, la respuesta no es clara, la compartición es intencionada o el entorno de pruebas no está disponible, el resultado sigue siendo needs_validation.
La traza del código fuente y la respuesta en tiempo de ejecución responden a preguntas distintas. La primera muestra dónde parece faltar el control. La segunda muestra cómo se comporta el sistema en ejecución. Un flujo de trabajo fiable conserva ambas y nunca sustituye una por otra.
Cada bucle debe cambiar el estado de la investigación. Si solo produce otra versión de la misma sospecha, el sistema está generando lenguaje en lugar de probar el objetivo.
Ahora, aplique el mismo método a otras preguntas de seguridad
El caso de las facturas nos da un camino completo, pero un flujo de trabajo de pentesting con IA no puede diseñarse únicamente en torno a la autorización. Llevemos el mismo razonamiento a tres investigaciones distintas.
Un intent de Android es solo el principio
El modelo encuentra una actividad de Android exportada llamada ShareActivity. También ve un extra de intent entrante y una llamada a startActivity.
Punto de decisión: ¿es eso suficiente para reportar una redirección de intents?
No. El flujo de trabajo todavía tiene que conectar las piezas. Debe confirmar que se puede acceder al componente desde el exterior, identificar qué extras controla un atacante, rastrear esos valores hasta startActivity, startService o sendBroadcast, e inspeccionar cualquier validación o restricción de componentes aplicada antes de la llamada.
El siguiente paso es una prueba controlada en tiempo de ejecución desde una aplicación distinta. Para confirmar la redirección de intents, la entrada manipulada debe hacer que la aplicación víctima realice una acción que la aplicación de prueba no podría invocar directamente. Por ejemplo, podría llegar a un componente interno no exportado o a una operación protegida.
Abrir otra actividad exportada no demuestra una evasión de seguridad. Si la actividad de entrada no está exportada, el intent anidado está restringido o no se produce ningún efecto protegido, acote la afirmación o márquela como not_reproduced.
La API peligrosa era una pista. La alcanzabilidad, el control del atacante y el comportamiento observado determinan si se convierte en un hallazgo.
Un parámetro de consulta no es automáticamente una inyección
A continuación, el modelo observa que el parámetro de consulta sort llega a una función que construye consultas. Etiqueta la ruta como «posible inyección SQL».
Siguiente pregunta: ¿pasa el valor a formar parte del comando SQL o sigue siendo un dato? Una lista de permitidos que asigne name o created_at a nombres de columna fijos cambia la conclusión. Insertar directamente el valor en la consulta justificaría una prueba de validación segura en el entorno aprobado.
El flujo de trabajo rastrea el valor desde el handler HTTP hasta el constructor de consultas y registra cualquier validación o transformación. Después ejecuta pruebas pareadas y no destructivas sobre datos propiedad del tester. Para confirmar la inyección, la entrada controlada por el atacante debe cambiar el comportamiento de la consulta mientras la solicitud de referencia se mantiene estable. Un error de la base de datos por sí solo no basta: una entrada malformada puede causar un error sin permitir la inyección. La concatenación de cadenas sin una entrada del atacante alcanzable sigue siendo evidencia estática, no una explotación demostrada.
Un valor sensible debe llegar realmente al almacenamiento
Por último, el modelo encuentra código que escribe valores en las preferencias compartidas, en una base de datos local o en una caché. Informa de «datos sensibles almacenados de forma insegura».
Evidencia que falta: el flujo de trabajo debe identificar el valor. Una API de almacenamiento no demuestra que se escriban a través de ella contraseñas, tokens, datos personales o material criptográfico. Después debe rastrear la ruta de escritura o ejercitar el flujo de la aplicación correspondiente e inspeccionar el almacenamiento resultante bajo el modelo de atacante indicado.
Si un valor sensible propiedad del tester aparece en el disco, registre su ubicación, los pasos de creación, la protección y las condiciones de recuperación. Indique también si la extracción requirió una compilación depurable, run-as, acceso a copias de seguridad, root, acceso físico o instrumentación en tiempo de ejecución.
Los datos recuperados del almacenamiento privado solo tras obtener acceso root no respaldan la misma afirmación de riesgo que los datos expuestos en un almacenamiento legible externamente. Si la evidencia muestra solo una utilidad genérica de almacenamiento, la afirmación sigue siendo una hipótesis.
Estos ejemplos usan herramientas y evidencias distintas, pero siguen la misma progresión: acotar la pregunta, rastrear el control del atacante, identificar el control esperado, probar de forma segura y conservar el resultado observado.
Una pista se convierte en hallazgo en la puerta de validación
La cuenta A obtiene correctamente su factura marcada. La cuenta B, sin ninguna relación de compartición, obtiene a continuación el mismo marcador privado a través del mismo endpoint. El flujo de trabajo registra ambas identidades, la referencia de propiedad, las solicitudes, las respuestas, la ruta de código y la divulgación observada entre cuentas.
Solo ahora la pista puede convertirse en un hallazgo confirmado.
Cada afirmación necesita puertas distintas:
| Afirmación | Qué debe demostrar el flujo de trabajo |
|---|---|
| El valor sensible se almacena localmente | Recuperar un valor propiedad del tester desde la ubicación de almacenamiento indicada y documentar los requisitos previos de acceso. |
| El endpoint carece de autorización a nivel de objeto | Establecer el acceso del propietario y luego demostrar el acceso de un segundo principal controlado por el tester sin relación de compartición. |
| La entrada del usuario llega a un sumidero peligroso | Rastrear el control del atacante y usar pruebas seguras pareadas para demostrar el comportamiento del sumidero relevante para la seguridad. |
| Ejecución remota de código | Producir un marcador de ejecución único e inofensivo en un entorno autorizado; un fallo por sí solo es insuficiente. |
Una API sospechosa, una comprobación que parece faltar, un endpoint inusual o una función peligrosa pueden orientar la siguiente prueba. Ninguno es automáticamente una vulnerabilidad digna de un informe.
Si la validación no está disponible: dígalo. Needs_validation es más útil que un falso positivo categórico, porque indica al revisor qué sigue sin conocerse.
Antes de dar herramientas al modelo, fije los límites
La investigación funciona, así que surge la tentación de dar más acceso al modelo: más herramientas, más objetivos, quizá credenciales de producción.
Pregunta de seguridad: ¿cuál es la acción más dañina que este flujo de trabajo podría realizar si malinterpretara la tarea o siguiera contenido malicioso?
«Tenga cuidado» no es un límite de seguridad. La capa de ejecución debe imponer el acceso de solo lectura al código fuente, objetivos en una lista de permitidos, identidades sintéticas, límites de frecuencia, entornos de preproducción aprobados y aprobación humana antes de las acciones que cambien el estado.
Los archivos del repositorio, los tickets, las páginas web, los registros y las respuestas del objetivo son entradas no confiables. Pueden contener instrucciones destinadas a redirigir un sistema de IA. Por tanto, la inyección de prompts y la autonomía excesiva son riesgos de diseño del sistema, no problemas que se resuelvan solo con una redacción ingeniosa.
El modelo puede proponer una acción. La capa de ejecución decide si está permitida.
Una prueba exitosa sigue siendo solo una prueba
Pregunta de fiabilidad: ¿demuestra una investigación de facturas exitosa que la arquitectura de prompts es fiable?
No. Demuestra únicamente que un flujo de trabajo gestionó un caso.
Construya un conjunto de evaluación con vulnerabilidades confirmadas, falsos positivos conocidos, componentes limpios y casos incompletos en los que el resultado correcto es needs_validation. Ejecute esos casos siempre que cambien el modelo, el prompt, la herramienta, la regla de selección de contexto o el esquema de salida.
Después pregunte:
- ¿Identificó el problema conocido?
- ¿Adjuntó la evidencia correcta?
- ¿Rechazó el falso positivo conocido?
- ¿Se detuvo cuando no había prueba en tiempo de ejecución?
- ¿Podría un revisor reproducir la conclusión?
Esto convierte la edición de prompts en ingeniería. Un cambio se gana su lugar al mejorar un resultado medido, no al producir una prosa más persuasiva.
¿En qué confiaría ahora?
Vuelva a la primera respuesta: una lista pulida de posibles vulnerabilidades generada a partir de una revisión amplia del repositorio.
Compárela ahora con la investigación de la factura. El segundo resultado tiene un objetivo acotado, un modelo de atacante, una traza de código, dos identidades controladas, una solicitud y una respuesta capturadas, un fallo de autorización observado y un estado que superó una puerta de validación definida.
Decisión final: ¿qué resultado enviaría al equipo de ingeniería?
La IA puede ayudar a los equipos de seguridad a navegar por grandes bases de código, organizar evidencias, generar planes de prueba enfocados y decidir qué inspeccionar a continuación. No elimina la necesidad de un objetivo, una prueba, un control o un revisor.
El objetivo no es una lista más larga de posibles vulnerabilidades. Es un camino corto y defendible a través del objetivo:
Alcance → pregunta → evidencia → prueba → resultado observado → conclusión.
Esa es la diferencia entre un modelo capaz de describir las pruebas de seguridad y un flujo de trabajo que deja algo que otro ingeniero puede reproducir, cuestionar, corregir y verificar.