Los equipos de seguridad recurren a agentes de IA para encontrar vulnerabilidades, generar parches y reducir el retraso acumulado de hallazgos de seguridad. Sin embargo, un análisis más rápido también puede crear una vía más rápida hacia la exposición de datos, la escalada de privilegios o un cambio de código inseguro. Un artículo de orientación publicado el 16 de julio de 2026 por Google Cloud y Mandiant establece un modelo operativo útil: combinar las capacidades de la IA con controles deterministas, ejecución aislada y criterio humano.
La urgencia es clara. El artículo cita la inteligencia sobre amenazas de Mandiant de 2026, que muestra que las vulnerabilidades pueden explotarse antes de que exista un parche disponible. Eso no significa que todos los equipos de seguridad deban dar a un agente acceso amplio a sus repositorios. Significa que el flujo de trabajo debe diseñarse para aplicar la velocidad a tareas controladas y verificables.
1. Empieza con un filtro de datos y modelado de amenazas
Antes de que un agente vea una instrucción o un archivo fuente, define exactamente qué datos puede procesar. Prueba el flujo de trabajo en un entorno que no sea de producción y que contenga datos sintéticos. Elimina los secretos, la información personal y cualquier otro material sensible antes de que llegue al modelo. Las implementaciones en producción necesitan un diseño por capas: un motor de políticas determinista debe actuar como primera barrera, mientras que un modelo de protección independiente o un control equivalente puede inspeccionar las instrucciones y las salidas para detectar intentos de inyección o contenido sensible.
Trata el código como una entrada no fiable, incluso cuando el repositorio sea interno. Las instrucciones maliciosas pueden ocultarse en comentarios, documentación o dependencias de terceros. Un agente que siga esas instrucciones podría ignorar un hallazgo o intentar exponer variables de entorno. Por tanto, la incorporación de repositorios debe incluir saneamiento de entradas, revisión de dependencias y un registro claro de los archivos suministrados al agente.
2. Aísla cada carga de trabajo del agente
Ejecuta el análisis en un entorno estrictamente aislado y sin privilegios, con permisos limitados dinámicamente. El agente no debe compartir credenciales, volúmenes con capacidad de escritura ni acceso amplio a la red con los servicios de producción. Utiliza entornos de corta duración que puedan destruirse después de cada revisión y restringe las conexiones a los sistemas necesarios para la prueba aprobada.
Este aislamiento limita los daños si un agente alucina un comando destructivo, entra en un bucle recursivo o es manipulado mediante una inyección de instrucciones. También facilita la auditoría del flujo de trabajo: cada ejecución tiene un alcance definido, un estado inicial conocido y un punto final claro.
3. Asigna al agente una identidad limitada
Los agentes de IA pueden necesitar abrir una solicitud de extracción o confirmar un cambio propuesto, pero no deben operar como la cuenta personal de un desarrollador. Crea una identidad de máquina distinta para cada flujo de trabajo y vincúlala a un responsable humano identificado. Utiliza tokens temporales, emitidos justo a tiempo, limitados a un repositorio y, cuando sea posible, a una sola rama en revisión.
Revisa la cadena de suministro que rodea al agente con el mismo cuidado que el propio agente. Las habilidades, los complementos y los servidores del Model Context Protocol de terceros pueden introducir dependencias manipuladas o actualizaciones inseguras. Fija las versiones aprobadas, verifica mediante hashes u otro mecanismo las herramientas entrantes y exige una revisión antes de cambiar una integración. El marco de orquestación también necesita evaluación, porque el envenenamiento de la memoria de sesión y las debilidades de los bucles recursivos pueden afectar a todo el flujo de trabajo.
4. Haz que las acciones sean observables y comprobables
Registrar la respuesta final no es suficiente. Registra las entradas del agente, las llamadas a herramientas, las salidas, la identidad, la versión del modelo y los puntos finales de destino. Supervisa el movimiento de los datos durante la ejecución para que el contexto interno no pueda fluir silenciosamente hacia un servicio externo no aprobado. Los registros centralizados y resistentes a la manipulación deben permitir que un revisor reconstruya qué vio el agente, qué intentó hacer y qué cambió.
Utiliza validación determinista siempre que sea posible. Si un agente afirma haber encontrado una vulnerabilidad, exige un arnés de pruebas reproducible que pueda ejecutarse en el entorno aislado. Establece tiempos de espera y límites de iteración para que un intento de prueba fallido no consuma una cantidad ilimitada de capacidad de cómputo o presupuesto de API. Una ejecución satisfactoria demuestra que se produjo una condición técnica; no prueba automáticamente que el problema sea explotable o tenga una prioridad alta.
5. Dirige cada tarea a la herramienta adecuada
Mantén los controles convencionales SAST y DAST para la cobertura de referencia. Los agentes de IA son más útiles cuando sus fortalezas coinciden con el objetivo. La orientación de Google Cloud identifica el código con memoria insegura, como C y C++, como un candidato sólido para auditorías asistidas por agentes, porque la corrupción de memoria puede producir un fallo observable u otro resultado binario. En cambio, las omisiones de autorización y los fallos de lógica de negocio suelen requerir un conocimiento de los límites de confianza y de la intención empresarial que un agente no puede inferir de forma fiable únicamente a partir del código fuente.
No dirijas un escáner autónomo a todos los repositorios a la vez. Empieza con un alcance pequeño y de gran impacto, define el oráculo esperado para el éxito y mide la carga de revisión. Los agentes pueden reducir el esfuerzo necesario para encontrar problemas candidatos, pero no ofrecen una cobertura exhaustiva y pueden pasar por alto vulnerabilidades nuevas.
6. Mantén la corrección detrás de una solicitud de extracción
Para problemas localizados de nivel sintáctico, un asistente del IDE puede proponer un cambio específico que un desarrollador revise antes de confirmarlo. Los cambios más amplios deben gestionarse mediante un ejecutor de CI/CD que cree una solicitud de extracción en lugar de modificar directamente la rama principal.
Ejecuta la suite normal de regresión y el arnés de pruebas determinista original contra el parche propuesto. Si la prueba de concepto sigue funcionando, la corrección no ha cerrado la condición demostrada. Si el parche supera las pruebas, un ingeniero humano aún debe revisar la alcanzabilidad, la arquitectura y el impacto empresarial antes de fusionarlo. Esto es especialmente importante cuando una corrección técnicamente válida podría debilitar la lógica de autorización o introducir una nueva regresión.
7. Añade controles posteriores al despliegue
El código generado por IA merece la misma disciplina de reversión que cualquier otro cambio importante. Mantén una ruta automatizada de vuelta a una versión conocida y correcta, fija las versiones de las API de los modelos cuando el flujo de trabajo dependa de un comportamiento reproducible y planifica migraciones controladas cuando una versión fijada llegue al final de su vida útil. Conserva registros de auditoría inmutables que muestren la versión del modelo, los resultados de la validación y el ingeniero que aprobó el cambio.
La regla práctica es sencilla: deja que la IA acelere el descubrimiento y la preparación, pero mantén el acceso, la ejecución, la fusión y el aislamiento dentro de límites deterministas. Esta combinación ofrece a los equipos de seguridad un flujo de trabajo de vulnerabilidades más rápido sin convertir al agente de gestión de vulnerabilidades en un operador privilegiado de producción.
Fuente: Google Cloud y Mandiant, «Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management», publicado el 16 de julio de 2026.