La IA está ampliando tu superficie de ataque. ¿La estás poniendo a prueba?

El mercado está inundado de promesas. Un proveedor encabeza una clasificación. Otro recauda cientos de millones con una presentación. Mientras tanto, tus desarrolladores lanzaron tres servicios generados por IA antes del almuerzo. Esta es la conversación que la industria no está teniendo y hacia la que llevamos años avanzando.

Esta conversación está teniendo lugar ahora mismo en todos los equipos de seguridad.

Alguien hace una demostración de un asistente de programación con IA. La velocidad es innegable y el equipo queda asombrado. Aun así, mantiene la cautela y, a veces, el escepticismo.

El código que antes tomaba un sprint ahora se escribe en una tarde. El liderazgo está muy entusiasmado. También lo están los desarrolladores que sobrevivirán a esta era. Y seguridad, si es sincera, no sabe muy bien si las herramientas que tiene están preparadas para lo que viene.

Narrador: No lo están.

El benchmark del que nadie quiere hablar

BaxBench no es un informe de amenazas, sino una medición. Cuando los investigadores evaluaron código de backend generado por LLM en tareas del mundo real, el 62 % estaba roto o era inseguro. Y de todo el código que funcionaba correctamente, aproximadamente la mitad seguía siendo explotable.

Léelo otra vez: la IA escribe código funcional y la mitad sigue siendo explotable.

Eso no significa que debas dejar de usar asistentes de programación con IA; esa posibilidad ya quedó atrás. Significa que debemos precisar qué entendemos por seguro en un mundo donde la generación de código se aceleró de forma permanente.

El análisis estático en el momento de creación —ya sea una herramienta SAST en el IDE o recomendaciones de seguridad asistidas por IA durante el ciclo de desarrollo— es un primer paso necesario, pero no el punto de llegada. Puede decirte qué hay en el código, pero no si ese código es realmente explotable de la manera en que lo haría un atacante. Incluso con los enfoques estáticos multimodales más recientes, que combinan análisis de taint y razonamiento con LLM, estas herramientas solo pueden predecir qué podría ser explotable en el código; no pueden demostrar el comportamiento real en tiempo de ejecución bajo condiciones de ataque reales.

Para eso, necesitas probar desde afuera y en tiempo de ejecución, tal como lo haría un atacante real.

La segunda superficie de ataque que nadie mapeó

Mientras la industria debatía la seguridad del código generado por IA, una segunda superficie de ataque se iba formando silenciosamente.

Los agentes de IA no funcionan de forma aislada. Llaman a API, a menudo privilegiadas y, en muchos casos, sin documentar. Son API creadas antes de que alguien imaginara que se invocarían de manera autónoma y a gran escala. Gartner proyecta que, para 2028, los agentes de IA serán los principales consumidores de API empresariales. Para 2029, se espera que más del 50 % de los ataques exitosos contra agentes de IA exploten fallas de control de acceso (BOLA/IDOR), precisamente el tipo de vulnerabilidad cuya validación históricamente ha sido difícil para el análisis estático.

No es una predicción audaz; es una descripción de decisiones de arquitectura que tu organización ya tomó.

BodySnatcher lo hizo concreto. Con CVE-2025-12420, un atacante sin autenticar, con solo la dirección de correo electrónico de la víctima, podía hacerse pasar por un administrador de ServiceNow, eludir MFA y SSO, ejecutar flujos de trabajo de agentes de IA y crear cuentas de puerta trasera con privilegios completos. Números de Seguro Social, registros financieros, propiedad intelectual confidencial: todo listo para ser robado... Todo expuesto.

La técnica no era compleja: no hubo un zero-day ni una ingeniosa inyección de prompts. La vulnerabilidad estaba ahí, sin probar, detrás de un agente en el que la organización confiaba por completo. La conclusión del investigador fue precisa: «Los agentes de IA amplifican significativamente el impacto de las fallas de seguridad tradicionales».

La velocidad de entrega superó la capacidad de validación. La respuesta no puede ser frenar. Debemos cambiar radicalmente lo que significa hacer pruebas.

No son vulnerabilidades nuevas; son las mismas de siempre, que ya eran difíciles de detectar, solo que ahora la nueva arquitectura las amplifica.

Por qué en realidad es una sola historia

Esto es lo que creo que se pasa por alto cuando se tratan estos dos problemas por separado: ambos comparten la misma causa raíz. La velocidad de entrega simplemente superó por completo la capacidad de validación. Los asistentes de programación con IA generan código más rápido de lo que cualquier proceso de seguridad podría manejar, y los agentes de IA invocan API más rápido de lo que cualquier inventario podría registrar. En ambos casos, hay algo en producción que nunca se ha sometido sistemáticamente a ataques: no revisado, no analizado, sino *atacado*, como lo haría un agente malicioso real.

Creemos que la respuesta no puede ser frenar. Debemos cambiar lo que significa hacer pruebas.

Las pruebas dinámicas no son un vestigio de los viejos tiempos, anteriores a la IA; son la disciplina que la era de la IA realmente necesita. En un mundo posterior a la IA, se convierten en una base, una base fundamental.

Así que la pregunta no es si deberías hacer pruebas dinámicas, sino si estas son lo suficientemente inteligentes y pueden seguir el ritmo de lo que ahora está en producción: código generado por IA, a la velocidad de la IA, detrás de API que los agentes invocan más rápido de lo que cualquier inventario manual puede registrar.

Las pruebas dinámicas modernas también deben funcionar con IA: ser lo bastante rápidas para el pipeline, lo bastante inteligentes para distinguir la explotabilidad real del ruido y estar diseñadas específicamente para una superficie de ataque que no existía hace apenas dos años.

Señal, no ruido

Este es el verdadero problema del código generado por IA a gran escala: no solo crea más código, sino también más hallazgos, más alertas y más cosas que parecen requerir atención. Imagina todo eso procesándose con herramientas de seguridad diseñadas para un mundo mucho más lento.

Los desarrolladores se ven abrumados por este ruido y deben decidir en qué invertir su tiempo. La mayoría de las veces, terminan guiándose por la intuición, la experiencia o la presión constante de las fechas límite.

La fatiga por alertas no es nueva, pero en la era de la programación con IA se acumula: los desarrolladores ya no revisan los hallazgos de un solo sprint; revisan resultados que antes le habrían tomado todo un trimestre a un equipo. Si todos los hallazgos tienen la misma prioridad, no se corrige nada. Al menos, no con confianza.

La ecuación empieza a cambiar cuando se establece una correlación. Cuando un hallazgo estático y uno dinámico apuntan a la misma causa raíz (cuando el código indica que hay una vulnerabilidad y las pruebas en tiempo de ejecución demuestran que es explotable), ya no tienes dos problemas que clasificar. Tienes una corrección prioritaria y confiable en la que los desarrolladores realmente confían.

El ruido disminuye. La señal se agudiza.

Esa precisión importa más que nunca en la era de la IA. Una tasa de falsos positivos del 0,08 % no es una especificación del producto; es lo que ocurre cuando la seguridad deja de ser un costo para los desarrolladores y se convierte en un acelerador. La IA escribe el código, tú demuestras qué está realmente roto y los desarrolladores lanzan más rápido y con confianza, en lugar de más lento y con ansiedad.

✔️ SAST con tecnología de LLM que identifica patrones de código generado por IA y los riesgos asociados, hoy, en el IDE y en el pipeline.

✔️ DAST inteligente que prueba activamente aplicaciones y API en ejecución para confirmar la explotabilidad real, en especial BOLA, IDOR y fallas de autorización específicas de agentes.

✔️ Hallazgos correlacionados que vinculan señales estáticas con confirmación dinámica: una corrección priorizada, no una cola de problemas por clasificar.

✔️ Descubrimiento de API que revela los endpoints que tus agentes de IA invocan de forma autónoma, incluidos los que no están documentados.

✔️ Cobertura continua integrada en el pipeline de entrega, no una evaluación trimestral.

Qué son (o deberían ser) realmente las pruebas de penetración con IA

Muchos proveedores están adoptando ahora la etiqueta «pruebas de penetración con IA». Algunos solo quieren decir que usan LLM para crear cargas de ataque; otros, que generan informes de hallazgos con «agentes» (también cuestionamos aquí el concepto de autonomía). Solo unos pocos se refieren a algo mucho más interesante.

Lo que esta disciplina realmente exige, lo que la era de la IA específicamente exige, es un enfoque capaz de probar código generado por IA para detectar fallas lógicas propias de la IA, rastrear las API que invocan los agentes (incluidas las que no están documentadas), correlacionar los hallazgos dinámicos con el contexto y la inteligencia a nivel de código para separar la señal del ruido, y hacer todo esto de forma continua en lugar de como un ejercicio aislado y puntual.

Por cierto, esto no debería ser una lista de funciones ni una hoja de ruta: debería ser el estándar. Y la industria todavía no ha podido expresarlo claramente. Precisamente por eso este es el momento de hacerlo. Y eso es lo que haremos.

Llevamos años trabajando para alcanzar este estándar, y los resultados que vemos con nuestros clientes en producción siguen validando el enfoque.

Las pruebas de seguridad verdaderamente diseñadas para la era de la IA no solo encuentran más problemas y más rápido. Correlacionan predicciones estáticas con pruebas dinámicas y ofrecen correcciones que los desarrolladores pueden implementar con confianza, no con ansiedad.

El debate sobre la seguridad de la IA ha estado dominado por dos preguntas supuestamente distintas: ¿podemos proteger los modelos de IA? ¿Y podemos usar la IA para encontrar vulnerabilidades? Ambas son válidas, pero ninguna basta por sí sola.

La pregunta más urgente es más sencilla: ¿quién está probando o atacando el código y las API que la IA crea y ejecuta?

Si la respuesta no eres tú, puedes tener la certeza de que alguien más (o alguna OTRA COSA) lo hará.