Cualquier equipo de seguridad de aplicaciones puede orientar un agente de IA construido sobre un modelo de propósito general hacia sus propios sistemas web con un esfuerzo mínimo. El modelo redacta los ataques, pero las garantías que permiten ejecutarlos contra producción sin riesgos y obtener resultados aprovechables viven en el harness que rodea al modelo. Ahí está la verdadera ingeniería del pentesting con IA. La intrusión en Hugging Face que OpenAI hizo pública en julio dejó al descubierto las consecuencias de que ese harness ceda, incluso dentro de una evaluación diseñada precisamente para contener a los agentes.
Por qué cada control exige una ingeniería rigurosa
A continuación se repasan las distintas fases del ataque y el papel que pueden desempeñar los agentes de IA en cada una de ellas.
Alcance
Un agente de pentesting toma miles de decisiones sobre dónde dirigir su siguiente petición, y el modelo evalúa cada una contra una regla redactada en lenguaje natural. El perímetro real de una aplicación web a menudo se extiende más allá de un solo dominio mediante redirecciones y llamadas a servicios externos. Hacer cumplir el alcance implica código que inspecciona cada petición antes de que salga, y la guía de OWASP para 2026 canaliza las acciones privilegiadas a través de un motor de políticas determinista que las verifica en el momento de la ejecución, fuera del modelo.
Credenciales
Descubrir credenciales expuestas forma parte de lo que hace un pentest, por lo que el agente encuentra con regularidad claves válidas fuera de su encargo. Cuáles puede usar, para qué y cuándo interviene una persona son decisiones de política que el código que rodea al modelo aplica en cada intento.
Inyección de prompts
Cada página y cada respuesta de API que el agente lee, incluidos campos ocultos, metadatos y comentarios que el usuario nunca ve, pueden contener texto escrito por cualquiera que pueda publicar en la aplicación. Basta una sola reseña de producto para introducir instrucciones maliciosas. OWASP sitúa la inyección de prompts como el principal riesgo para las aplicaciones basadas en LLM y señala que hoy no existe una prevención fiable. La cuestión de diseño no es si el modelo será engañado, sino cuánto daño puede causar cuando lo sea. Eso depende de dos factores: cuán restringida está cada acción y qué acciones requieren inspección adicional y aprobación humana. Ninguno de los dos es sencillo. OWASP advierte que la fatiga de aprobaciones degrada el criterio de los revisores a escala, de modo que derivar todo a una persona solo desplaza el punto de fallo más adelante.
Prueba
En octubre de 2026, Google dejó de aceptar informes de vulnerabilidades de productos en su programa de recompensas por errores de código abierto tras un aumento de envíos automatizados, la mayoría de los cuales, según la compañía, no eran válidos. Un hallazgo que un desarrollador no puede reproducir es solo otro ticket para cerrar. Generar uno que merezca actuar requiere ejecutar el exploit, capturar a qué llegó y empaquetar el resultado para que cualquiera pueda repetirlo, todo ello dentro de los límites que imponen los demás controles.
Nada de esto se construye una sola vez. Cada actualización del modelo puede cambiar el comportamiento del agente, y cada versión modifica la aplicación cuya seguridad se prueba. Y en torno a los controles se sitúan los sistemas de los que depende un agente en producción, como las pruebas disparadas por cambios, el enrutamiento de hallazgos a los desarrolladores responsables del código, el control estricto de qué datos de clientes llegan al proveedor del modelo y la conexión de lo que el agente encuentra en la aplicación con el resto del entorno.
En todo ello se repite el mismo patrón: el modelo razona qué probar y el código determinista decide qué se ejecuta, lo registra y lo detiene cuando es necesario.
Cómo Pentera Apps implementa el harness
Esta separación entre razonamiento y ejecución es el enfoque con el que construimos Pentera Apps. En lugar de permitir que un modelo de IA envíe peticiones directamente a una aplicación, Pentera Apps combina una IA que decide qué probar con un harness determinista que controla qué se ejecuta. Cada acción queda registrada y cualquier prueba puede pausarse o detenerse en cualquier momento. Es la misma disciplina de seguridad que Pentera aplica a las pruebas en producción desde hace casi una década, en miles de clientes de todo el mundo.
El harness también genera la prueba. Cada hallazgo se entrega con un script de exploit reproducible, una puntuación CVSS 3.1 y su correspondiente mapeo CWE, de modo que los desarrolladores pueden reproducir el ataque por sí mismos en lugar de confiar en él. Una vez aplicada la corrección, el mismo ataque exacto puede volver a ejecutarse para confirmar que la vía está cerrada. Las pruebas se ejecutan a demanda o según una programación, y próximamente se incorporarán las pruebas disparadas por cambios en CI/CD, para que la validación se mantenga alineada con el desarrollo.
Los sistemas que lo rodean siguen la misma disciplina. Solo llegan al LLM datos mínimos y redactados, sin retención y sin entrenamiento con datos de clientes, y los datos permanecen en la región del cliente. Cada prueba comienza con el contexto del reconocimiento de las superficies de ataque del cliente, los hallazgos de su stack de seguridad y señales de inteligencia de amenazas en tiempo real. Ese contexto permite a Pentera rastrear un exploit en una aplicación web hacia la red, la nube y la identidad en una única plataforma.
En el pentesting con agentes, el harness determina los resultados. Pentera Apps lo incorpora de serie, para que los equipos de seguridad obtengan hallazgos validados sin tener que construirlo ellos mismos.
Nota: este artículo ha sido redactado y aportado por Assaf Regev, AVP de Marketing de Producto en Pentera. Los equipos de seguridad pueden solicitar acceso anticipado a Pentera Apps, Agentic Web App Pentesting.
Deja una respuesta