Agentic Autofix: seis gates para aceptar un parche de seguridad

El 15 de octubre de 2026 GitHub anunció la disponibilidad general de Agentic Autofix para alertas de code scanning. Al asignar una alerta a Copilot, una sesión explora archivos relacionados, genera una propuesta, vuelve a ejecutar CodeQL, itera si es necesario y abre un pull request en borrador. También puede agrupar hasta 25 alertas de la rama por defecto en una sola asignación. Es un cambio importante para equipos con backlog de vulnerabilidades: la unidad de automatización ya no es una sugerencia aislada, sino una investigación que atraviesa el repositorio y entrega un cambio revisable.

La noticia tenía un día calendario en America/Lima al consultarla el 16 de octubre. El anuncio prueba el contrato de producto y su fecha, no la calidad de cada parche ni un ahorro medido. La distinción central es esta: si la consulta que originó una alerta deja de encontrar su patrón, existe evidencia de remediación para ese detector. Todavía no existe evidencia suficiente de que la causa quedó corregida, que otra ruta no conserva el riesgo, que la compatibilidad se mantiene o que el cambio merece producción. El pull request en borrador es una frontera deliberada: el agente prepara evidencia; el equipo conserva la decisión.

Una remediación agéntica opera con dos oráculos distintos. El primero es estático: la consulta de CodeQL describe una propiedad peligrosa y comprueba si el cambio elimina el flujo detectado. El segundo es el contrato real del software: tests, tipos, interfaces, comportamiento de negocio, observabilidad y expectativas de operación. El primer oráculo puede ser fuerte sin abarcar al segundo. Por ejemplo, reemplazar una construcción de comando vulnerable puede cerrar una ruta de inyección y, al mismo tiempo, romper argumentos legítimos, observabilidad o soporte multiplataforma. Ningún rerun de una sola consulta demuestra por sí solo esas propiedades.

La documentación de GitHub hace explícito el límite: Agentic Autofix funciona en modalidad best effort y revalida con la suite de code scanning. No puede confirmar el cierre de alertas originadas por consultas personalizadas, la suite security-extended o herramientas de terceros. Además, las suites no son intercambiables: la default prioriza alta precisión, mientras security-extended añade consultas de menor precisión y severidad que pueden producir más falsos positivos. Antes del piloto, cada alerta necesita conservar proveedor, consulta, suite, configuración y revisión de reglas. Sin esa procedencia, «CodeQL pasó» puede describir un análisis diferente del que encontró el problema.

Los gates no exigen el mismo costo para todos los repositorios. Un servicio interno de bajo impacto puede usar una batería corta; una librería compartida, autenticación o pagos necesitan pruebas negativas, compatibilidad y revisión especializada. Lo no negociable es que cada gate tenga dueño, artefacto verificable y criterio de bloqueo antes de encender asignaciones masivas.

Imagine un servicio que recibe el nombre de un archivo y construye un comando de conversión mediante concatenación. CodeQL detecta que una entrada no confiable llega a un intérprete. El agente reemplaza la cadena por una llamada con argumentos separados, vuelve a ejecutar la consulta y abre un pull request. El gate de procedencia pasa porque se usaron la misma consulta y configuración. El gate de causa también parece pasar: una prueba con separadores de shell ya no ejecuta un segundo comando.

La revisión descubre dos efectos fuera del detector. En Windows, la biblioteca elegida interpreta las comillas de otra manera; en Linux, el proceso ya no hereda una variable requerida por el conversor. Un test de integración multiplataforma falla y una ruta legítima deja de procesar nombres con espacios. El parche no era inútil: eliminó una vulnerabilidad real. Pero todavía no era aceptable porque el segundo oráculo —el contrato operativo— no pasó. El equipo ajusta la API, incorpora casos negativos y positivos, y conserva el fix en un PR pequeño.

Este ejemplo es hipotético y no describe un cliente, incidente o resultado de Wasyra. Su propósito es mostrar por qué el estado correcto del agente es «candidato validado contra un detector», no «vulnerabilidad resuelta». Esa etiqueta reduce automatización teatral: obliga a exponer qué se comprobó y qué continúa bajo responsabilidad humana.

Empiece con un carril estrecho: una o dos familias de consultas de alta precisión, repositorios con tests confiables, componentes sin datos críticos y un grupo de revisores de seguridad y dominio. Aunque el producto permita hasta 25 alertas por pull request, el piloto debería favorecer cambios pequeños. Agrupar reduce sesiones, pero también mezcla causas, amplía el diff y vuelve ambiguo qué cambio cerró, rompió o encareció cada ruta. La unidad de aprendizaje es un fix atribuible, no el volumen de alertas movidas.

Defina exclusiones antes de habilitar a nivel organización: código generado, criptografía, autenticación, migraciones de datos, APIs públicas y componentes sin pruebas pueden requerir revisión manual desde el inicio. GitHub aplica controles en cascada: la empresa permite, la organización habilita y el repositorio puede excluirse según la política superior. Quienes tienen acceso de escritura pueden asignar alertas una vez habilitado el repositorio. Por eso la decisión no es solo técnica; también determina quién puede consumir sesiones, crear propuestas y llenar la cola de revisión.

Presupueste dos recursos: AI Credits de Code Security y minutos de GitHub Actions. El costo útil no es por sesión iniciada, sino por remediación aceptada que permanece estable después del merge. Registre alertas asignadas, PRs abiertos, PRs aceptados, tiempo humano de revisión, reintentos, fallos de CI, rollbacks y alertas reabiertas. Sin denominadores separados, una caída en tiempo de generación puede esconder un aumento mayor en revisión o regresiones.

Separe velocidad, calidad y cobertura. Para velocidad, mida tiempo desde asignación hasta PR y desde PR hasta decisión; el segundo revela la carga humana. Para calidad, use aceptación sin reescritura sustancial, fallos nuevos de CI, rollbacks, incidentes y reapertura de la alerta. Para cobertura, registre cuántas alertas elegibles pertenecen a consultas que el mecanismo puede revalidar y cuántas quedan fuera por suite, proveedor, rama o política. No convierta la tasa de cierre en objetivo único: un equipo puede mejorarla seleccionando solo fixes triviales.

Ejecute una muestra paralela con remediación humana comparable o, como mínimo, conserve la línea base histórica por familia de consulta. La comparación debe controlar severidad, lenguaje, tamaño del repositorio y edad de la alerta. Revise falsos negativos operativos: cambios que pasan el detector y CI pero fallan después del despliegue. Ningún proveedor ha publicado en las fuentes consultadas un benchmark que demuestre su tasa para su código, sus consultas o sus controles; cualquier umbral de adopción debe salir de su propio piloto.

Un agente con acceso al repositorio recibe contexto potencialmente sensible y puede modificar múltiples archivos para resolver una alerta. Las instrucciones personalizadas ayudan a orientar el cambio, pero no sustituyen permisos mínimos, protección de rama, revisión obligatoria, secretos fuera del entorno y límites de red. También existe riesgo de deuda invisible: un parche puede añadir una dependencia, duplicar validaciones, degradar rendimiento o trasladar el problema a otra capa. El diff, los logs de la sesión y la evidencia de cada gate deben conservarse para auditoría sin copiar secretos al sistema de observabilidad.

Adopte cuando el piloto demuestre tres cosas simultáneas: reduce tiempo total hasta una decisión, mantiene o mejora la calidad después del merge y no crea una cola de revisión que desplace trabajo más valioso. Escale por familias de consultas y clases de repositorio, no con un interruptor global. Detenga o reduzca alcance cuando aumenten reescrituras, regresiones, rollbacks, sesiones fallidas o costo por fix estable. La disponibilidad general significa que el producto está listo para uso soportado; no significa que su organización ya tenga el contrato de aceptación listo.

La conclusión práctica es sobria: deje que el agente investigue, proponga y reúna evidencia, pero haga que la organización defina qué significa «arreglado». Si necesita diseñar ese carril —permisos, evaluaciones, CI, revisión y observabilidad—, el servicio de agentes a medida de Wasyra puede convertir los seis gates en un flujo acorde con su riesgo, sin confundirlo con el producto Agents Wasyra.