La respuesta corta
Un agente de IA puede ampliar la revisión de código si se utiliza como investigador y autor de propuestas, no como autoridad para desplegar. La ruta segura separa cinco estados: posible hallazgo, reproducción controlada, parche propuesto, pruebas independientes y aprobación. Ninguno debe convertirse automáticamente en el siguiente solo porque el modelo lo afirma.
Google describió el 18 de septiembre de 2026 un sistema de agentes para revisar código de infraestructura y proponer correcciones antes de que el cambio llegue a producción. La señal es relevante, pero no convierte el patrón en una garantía universal. El SSDF de NIST y las guías de CISA sitúan la revisión, las pruebas y la gestión de vulnerabilidades dentro de un ciclo de desarrollo seguro; el repositorio abierto Mantis añade advertencias explícitas sobre aislamiento, resultados no deterministas y verificación manual.
Define qué puede leer y qué no puede tocar
Antes de elegir un modelo, delimita el entorno. El agente necesita una copia concreta del código, reglas de compilación, pruebas y un modelo de amenazas actualizado. No necesita credenciales de producción, secretos reales, acceso de escritura al repositorio principal ni conectividad libre hacia sistemas internos.
Las guías de desarrollo seguro de CISA y NCSC recomiendan proteger el entorno de desarrollo, controlar los activos y aplicar seguridad a lo largo del ciclo de vida. Mantis lleva esa precaución al uso de agentes: recomienda un entorno aislado y restringido porque el código generado o ejecutado puede ser inestable. La frontera debe aplicarse mediante permisos y red, no mediante una frase en el prompt.
- Copia inmutable del commit o versión que se va a analizar.
- Secretos sustituidos por valores de prueba sin utilidad fuera del entorno.
- Red saliente bloqueada o limitada a destinos necesarios y registrados.
- Cuenta sin permisos de despliegue ni escritura sobre ramas protegidas.
- Límites de tiempo, memoria, disco y procesos para cada ejecución.
Exige evidencia antes de aceptar un hallazgo
Una descripción convincente no demuestra que exista una vulnerabilidad. El hallazgo debe señalar archivo, ruta de ejecución, condición necesaria, impacto posible y una forma controlada de reproducirlo. Si falta una de esas piezas, su estado es pendiente de investigación, no confirmado.
El proyecto Mantis advierte que no reproducir un caso no basta para declararlo falso y que reproducirlo tampoco prueba que sea explotable en todos los contextos. NIST pide revisar y analizar el código para identificar vulnerabilidades y confirmar que se han resuelto. La consecuencia práctica es mantener la incertidumbre visible hasta que una prueba y una persona cualificada la reduzcan.
- Ubicación exacta y versión del código analizado.
- Flujo de entrada hasta el punto vulnerable, con sus precondiciones.
- Caso de prueba mínimo ejecutado en el entorno aislado.
- Resultado observado y resultado esperado.
- Nivel de confianza separado de la gravedad potencial.
Separa el agente que encuentra del que corrige
Usar el mismo contexto para detectar, justificar y aprobar un parche favorece que el sistema defienda su primera hipótesis. Google recomienda separar los agentes y sus reglas para reducir ese sesgo, mientras que NIST y CISA insisten en funciones definidas, revisión y comprobaciones dentro del proceso de desarrollo.
La separación no exige varios proveedores ni una plataforma compleja. Puede ser una secuencia con contextos distintos: un analizador propone el hallazgo; un paso determinista comprueba rutas, tipos y dependencias; otro proceso intenta reproducirlo; un agente diferente redacta el parche; y el pipeline habitual vuelve a ejecutar pruebas. La decisión final permanece fuera de cualquiera de esos agentes.
- Descubrimiento: busca señales y formula una hipótesis verificable.
- Triage: elimina duplicados y comprueba alcance y versión.
- Reproducción: ejecuta el caso mínimo en una caja aislada.
- Corrección: genera una diferencia pequeña vinculada al hallazgo.
- Validación: ejecuta controles independientes antes de pedir aprobación.
Haz que el parche compita con las pruebas
Un parche puede cerrar el caso concreto y romper otra ruta. Por eso debe atravesar los mismos controles que un cambio humano y algunos adicionales: compilación limpia, análisis estático, tests existentes, prueba de regresión para el fallo, comprobación de dependencias y revisión de la diferencia. Si el agente modifica las pruebas para conseguir que pasen, ese cambio necesita una revisión separada.
El SSDF de NIST recomienda revisar o analizar el código y probar el software ejecutable para identificar vulnerabilidades, además de comprobar que cada una se ha solucionado. La guía Secure by Design de CISA combina salvaguardas automatizadas, análisis y revisiones rigurosas. El agente puede acelerar partes del trabajo, pero no sustituye la diversidad de controles.
- Prueba que falla antes del parche y pasa después.
- Suite existente sin regresiones ni tests desactivados.
- Diferencia mínima, explicable y limitada al alcance aprobado.
- Análisis estático y de componentes ejecutado con reglas vigentes.
- Revisión específica si cambian permisos, autenticación, cifrado o registros.
Mantén aprobación humana y despliegue gradual
La persona revisora necesita más que un resumen del agente. Debe ver el hallazgo, la reproducción, el diff, las pruebas y los límites del análisis. También debe poder rechazar la propuesta sin perder la evidencia y enviar el caso a seguridad cuando el impacto o la incertidumbre superen el criterio acordado.
Las guías de CISA y NCSC asignan responsabilidades a desarrolladores, responsables del sistema y propietarios del riesgo. Mantis exige verificación manual por un especialista antes de reportar hallazgos. Para producción, el paso adicional es un despliegue gradual con observabilidad y una reversión ensayada. Aprobar un pull request no demuestra que el comportamiento real sea seguro bajo toda carga o configuración.
- Revisor distinto de quien configuró el agente para ese caso.
- Ramas protegidas y controles obligatorios que el agente no puede omitir.
- Despliegue canario o entorno previo cuando el sistema lo permita.
- Señales de error, seguridad y rendimiento observadas después del cambio.
- Procedimiento probado para retirar el parche y conservar la evidencia.
Mide calidad, no cantidad de alertas
Un agente que produce muchas alertas puede aumentar el trabajo y ocultar los casos importantes. El piloto debe medir la utilidad del conjunto: cuántos hallazgos se confirman, cuánto tarda la revisión, qué parches se aceptan sin cambios, qué regresiones aparecen y cuántas propuestas se descartan por falta de evidencia.
No existe un umbral universal que convierta el piloto en seguro. El riesgo del producto, la madurez de las pruebas y la capacidad de revisión cambian entre equipos. Conviene fijar el criterio antes de empezar y conservar una cola pequeña; si la revisión humana no absorbe los casos, ampliar el escaneo solo crea deuda de seguridad.
- Hallazgos confirmados frente a falsos positivos y casos inconclusos.
- Tiempo de triage y revisión por hallazgo útil.
- Parches aceptados, modificados y rechazados.
- Regresiones detectadas antes y después del despliegue.
- Cobertura por repositorio, componente y clase de debilidad.
Un piloto de diez días
Empieza con un repositorio no crítico que tenga pruebas fiables y una persona responsable. Durante la primera mitad, el agente solo analiza y documenta: no abre pull requests ni ejecuta código fuera de la caja de pruebas. El equipo compara sus hallazgos con incidencias conocidas y ajusta el modelo de amenazas y las reglas de salida.
En la segunda mitad puede proponer parches para uno o dos hallazgos confirmados. Cada cambio pasa por el pipeline normal y por revisión humana. El cierre debe decidir qué clases de hallazgo merece seguir buscando, qué permisos conservar, cuánto cuesta revisar y qué condición detendría el servicio.
- Días 1 y 2: alcance, copia del código, permisos y aislamiento.
- Días 3 y 4: modelo de amenazas y formato obligatorio de evidencia.
- Día 5: revisión de hallazgos sin generar cambios.
- Días 6 a 8: reproducción y parches para casos confirmados.
- Días 9 y 10: pruebas, revisión, métricas y decisión de continuidad.
Checklist antes de permitir un parche
La utilidad del agente depende menos de que escriba código rápido que de que el proceso limite sus errores. Si el equipo no puede reconstruir qué versión se analizó, qué prueba confirmó el problema y quién aprobó el cambio, todavía no existe una cadena de evidencia suficiente.
AUTOINTELLIA puede ayudar a diseñar un piloto que conecte agentes, repositorios y pruebas sin conceder acceso directo a producción. La primera entrega debería ser un control verificable y reversible, no un sistema autónomo que cierre alertas por volumen.
- El agente trabaja sobre una versión identificada y sin secretos reales.
- Cada hallazgo incluye evidencia reproducible y conserva su incertidumbre.
- La reproducción se ejecuta en un entorno aislado y observado.
- El parche es pequeño y pasa controles independientes del modelo.
- Una persona cualificada revisa el diff, las pruebas y el riesgo.
- El despliegue es gradual, observable y reversible.
- Las métricas premian correcciones útiles, no el número de alertas.
