Los Agentes de IA Encuentran Vulnerabilidades Zero-Day Más Rápido de lo que los Equipos de Seguridad Pueden Gestionarlas
Una startup de seguridad acaba de reportar 21 vulnerabilidades desconocidas previamente en FFmpeg, una de las bibliotecas multimedia más integradas en internet.
Lo incómodo no fue solo la cantidad de errores.
Fue cómo se encontraron.
Un agente autónomo de seguridad IA escaneó aproximadamente 1,5 millones de líneas de código C, produjo entradas reproducibles para pruebas de concepto y detectó vulnerabilidades zero-day confirmadas por unos 1.000 dólares en cómputo. En la misma semana, Google parcheó un récord de 429 errores de seguridad en Chrome tras cambiar su programa de recompensas para manejar un aluvión de reportes generados por IA.
Esto no es una pequeña mejora de productividad. Es un nuevo ritmo operativo para el descubrimiento de vulnerabilidades.
Para los CISOs, la pregunta ya no es si la IA puede ayudar a encontrar problemas de seguridad. Claramente puede. La pregunta más difícil es si la organización tiene gobernanza capaz de seguir el ritmo cuando la IA aumenta el volumen, velocidad y ambigüedad de los hallazgos de seguridad.
El cuello de botella de los zero-day se está moviendo
Durante años, el cuello de botella en la gestión de vulnerabilidades fue el descubrimiento.
Encontrar un error significativo requería experiencia humana escasa, tiempo y profundo conocimiento del código. Esa limitación moldeaba cómo los equipos de seguridad pensaban sobre el riesgo. Podías priorizar basándote en CVEs conocidos, avisos de proveedores, actividad de exploits y exposición de activos porque el flujo de nuevos hallazgos era ruidoso pero algo acotado.
La IA cambia esa limitación.
Si un agente autónomo puede escanear un gran proyecto open source y producir docenas de hallazgos plausibles rápidamente, el factor limitante cambia del descubrimiento a la validación, priorización, asignación, divulgación y remediación.
Eso suena operativo. En realidad es gobernanza.
¿Quién puede ejecutar investigación autónoma de vulnerabilidades contra código interno? ¿Qué sistemas pueden analizar? ¿Qué ocurre cuando el agente encuentra un error en una dependencia de terceros, un flujo de trabajo orientado al cliente o un sistema regulado? ¿Quién revisa la prueba de concepto antes de almacenarla, compartirla o escalarla? ¿Cómo se evita que código sensible, secretos o detalles de exploits se peguen en herramientas de IA no gestionadas durante el proceso?
La mayoría de las empresas aún no tienen respuestas claras.
Los hallazgos de seguridad generados por IA crean un problema de confianza
La IA no solo encuentra problemas. Crea trabajo.
Algunos hallazgos serán reales. Algunos serán duplicados. Algunos tendrán bajo impacto. Algunos serán sutilmente erróneos. Algunos incluirán artefactos de prueba de concepto que crean riesgo si se manejan mal. Algunos parecerán urgentes porque el agente escribe con confianza, incluso cuando la explotabilidad no está clara.
Eso crea un nuevo problema de confianza dentro del equipo de seguridad.
Si cada ingeniero, equipo rojo, proveedor e investigador externo puede usar IA para generar informes de seguridad a escala, las operaciones de seguridad necesitan una forma de separar la señal del ruido automatizado sin agotar a las personas responsables de la revisión.
Aquí es donde muchos programas de gobernanza de IA siguen siendo demasiado limitados. Se centran en si los empleados pueden usar ChatGPT, Claude, Gemini o Copilot. Eso importa, pero no es suficiente.
El problema mayor es que la IA se está convirtiendo en parte del flujo de trabajo de seguridad. Ejecuta pruebas, genera informes, escribe código de prueba de concepto, resume vulnerabilidades, sugiere correcciones y a veces toca código fuente sensible o contexto de producción.
Ese flujo de trabajo necesita visibilidad.
La IA en la sombra ahora incluye herramientas de seguridad en la sombra
Los equipos de seguridad suelen hablar de la IA en la sombra como un problema de usuarios de negocio: empleados que pegan datos de clientes en herramientas no aprobadas, equipos de marketing que usan apps de IA, analistas que suben hojas de cálculo, etc.
Pero el mismo patrón está surgiendo dentro de los equipos técnicos.
Un desarrollador usa un agente para auditar un repositorio. Un analista de seguridad usa un modelo para resumir código sospechoso. Un equipo rojo pide a una herramienta de IA que mutile cargas útiles de exploits. Un ingeniero sube logs para acelerar el análisis de causa raíz. Un contratista usa su asistente de IA preferido para revisar un problema de dependencia.
Ninguno de estos comportamientos es automáticamente malicioso. De hecho, muchos son útiles.
Pero si ocurren fuera de flujos de trabajo aprobados, crean exactamente el tipo de punto ciego que la gobernanza de IA debería reducir.
El riesgo no es solo la fuga de datos. Es la autoridad no gestionada:
- Herramientas de IA que reciben código fuente, credenciales, logs o detalles de arquitectura
- Agentes que generan material de exploits sin reglas claras de manejo
- Hallazgos que entran en colas de tickets sin procedencia ni puntuación de confianza
- Equipos que actúan sobre recomendaciones generadas por IA sin revisión
- Contexto sensible de remediación almacenado en cuentas personales de IA
Por eso el ejemplo de FFmpeg importa más allá de la seguridad open source. Muestra qué pasa cuando el descubrimiento de vulnerabilidades se vuelve barato y autónomo. El mismo patrón aparecerá en entornos empresariales, pero con código privado, sistemas internos y datos regulados involucrados.
Las políticas no seguirán el ritmo de los agentes
Una política en PDF que diga "no subir datos sensibles a herramientas de IA" no gestionará este problema.
Los equipos de seguridad necesitan controles que operen donde ocurre el trabajo.
Eso significa saber qué herramientas de IA se están usando, qué identidades las están accediendo, qué tipos de datos circulan por ellas y qué flujos de trabajo involucran código, registros, tickets, vulnerabilidades o contexto del cliente.
También significa crear caminos establecidos en lugar de prohibiciones generales.
Si los empleados creen que las herramientas aprobadas son más lentas que el asistente de IA que ya usan, evitarán la política. La solución no es bloquear cada experimento. Es ofrecer formas seguras y monitorizadas de usar IA para el trabajo de seguridad, con límites claros sobre datos, acciones, retención y revisión.
Para agentes de seguridad autónomos específicamente, las empresas deben definir:
- Objetivos aprobados: qué bases de código, sistemas y entornos pueden probar los agentes
- Límites de datos: qué código fuente, registros, secretos y datos de clientes pueden compartirse
- Revisión humana: quién valida los hallazgos antes de la escalada o remediación
- Manejo de artefactos: cómo se almacenan el código de prueba de concepto y las entradas de explotación
- Reglas de divulgación: cuándo los hallazgos involucran software de terceros o código abierto
- Registros de auditoría: qué agente ejecutó, bajo qué autoridad, contra qué activo y con qué resultado
Sin esa estructura, el trabajo de seguridad potenciado por IA se convierte en otra forma de IA oculta.
La pregunta del CISO cambia
La pregunta antigua era: "¿Están nuestros equipos usando herramientas de IA?"
La mejor pregunta es: "¿Qué flujos de trabajo impulsados por IA influyen ahora en decisiones de seguridad, cambios de código, manejo de vulnerabilidades o riesgos en producción?"
Ese es el nivel donde debe operar la gobernanza.
Que agentes de IA encuentren 21 vulnerabilidades zero-day en una biblioteca importante es impresionante. También es una advertencia. El sistema de seguridad empresarial alrededor de la IA debe madurar tan rápido como las propias herramientas.
De lo contrario, el próximo cuello de botella no será encontrar vulnerabilidades.
Será saber qué hallazgos generados por IA confiar, qué flujos de trabajo de IA tocaron datos sensibles y qué riesgos creó accidentalmente su organización al intentar avanzar más rápido.
Aona ayuda a los equipos a cerrar esa brecha dando a los líderes de seguridad visibilidad del uso real de IA, la deriva entre políticas y comportamientos, y los flujos de trabajo donde la IA empieza a tocar datos sensibles, código y decisiones empresariales.
Si su programa de gobernanza de IA todavía trata esto como un problema de acceso a herramientas, es hora de ampliar la perspectiva.
