Usa este bucle de 4 pasos para verificar la corrección automática de un agente de IA antes de publicarla
La corrección automática de un agente es un parche propuesto hasta que un nuevo escaneo específico de la vulnerabilidad, la suite de regresión, la revisión del diff y el registro de CI la aprueben.
Un agente de código devuelve un diff para una vulnerabilidad. El diff parece plausible. El escaneo pasa. Aun así, no deberías fusionarlo basándote solo en esa evidencia. La corrección automática de un agente es un parche propuesto hasta que un nuevo escaneo específico de la vulnerabilidad pasa y tu revisión normal y la suite de regresión siguen aprobándolo.
StackHawk lanzó públicamente Wingman el 15 de septiembre de 2026. Wingman está disponible en Claude Code, Cursor, GitHub Copilot, Codex y Antigravity. La herramienta se inicia automáticamente cuando un agente de código marca una funcionalidad como completa, se configura, arranca la aplicación en ejecución y la prueba como un atacante.
Envía los hallazgos al mismo agente que escribió el código, permite que ese agente parchee la falla y ejecuta un segundo escaneo para verificar la reparación antes de que se abra una pull request. El precio es de $10 por usuario al mes, con aplicaciones ilimitadas y 50 escaneos por usuario al mes. Desde su primer lanzamiento, Wingman ha remediado más de 7.500 fallas de seguridad para usuarios de acceso anticipado en más de cinco agentes de código de IA, y el 98% de las correcciones permanecieron resueltas sin regresiones.
Wingman informa al pipeline de integración continua si un commit está limpio, y cada prueba está vinculada al commit que verificó. Los detalles del producto importan menos que el proceso. Cuando los agentes corrigen automáticamente vulnerabilidades, el peligro es una corrección exitosa que no solicitaste.
Una corrección automática es una propuesta de parche
Un escaneo de vulnerabilidades previo a la PR es útil, pero no aprueba una fusión por sí solo. El agente puede abordar el problema sin resolverlo por completo. Sin un objetivo definido, las verificaciones posteriores pueden fallar. Tu trabajo es tratar la salida como una solicitud de cambio, no como una reparación terminada.
Mantén esta lista de verificación en la descripción de la PR. Cada elemento es una verificación de sí/no, y cada uno bloquea un modo de fallo diferente.
- Identifica la vulnerabilidad. La PR nombra el endpoint, parámetro o componente afectado, y la clase de falla.
- Verifica que un nuevo escaneo independiente de esa vulnerabilidad haya pasado. Un segundo escáner o un conjunto de reglas diferente verificó el mismo objetivo en el mismo commit.
- Verifica que la suite completa de regresión haya pasado y que el diff haya sido revisado. La suite normal está en verde, y una persona verificó si el parche corrige, oculta o desplaza la falla.
- Verifica que el commit y el resultado del escaneo estén registrados en CI antes de la fusión. El pipeline muestra el nuevo escaneo, el resultado de regresión y el commit en un solo lugar.
El nuevo escaneo debe apuntar a la falla
El primer escaneo encontró un problema. El segundo escaneo debe responder a una pregunta más estrecha: ¿ese problema ha desaparecido? Un escaneo puede pasar mientras el problema sigue sin resolverse. El nuevo escaneo debe apuntar a la misma ruta, parámetro o componente, y debe usar un escáner, conjunto de reglas o sonda manual diferente al que produjo el hallazgo.
Si el agente usó una corrección del mismo producto, el nuevo escaneo no debe dar por sentado que la verificación propia de ese producto sea suficiente. En seguridad de código con IA, el agente es a la vez autor y primer revisor. Una verificación independiente separa la autoría de la revisión.
La suite de regresión y la revisión del diff detectan efectos secundarios
Un parche de seguridad puede ser correcto en un sentido estricto y aun así romper la aplicación. Puede cambiar la autenticación, alterar la forma de una respuesta o añadir una dependencia que ralentice la compilación. La suite completa de regresión es la parte del proceso que pregunta si la corrección encaja con el sistema, no solo con el ticket.
La revisión del diff es donde una persona verifica la intención. ¿El agente eliminó el comportamiento vulnerable o añadió un bypass? ¿Parcheó el endpoint o deshabilitó una funcionalidad? Una breve revisión de las líneas modificadas puede descubrir una corrección que parece plausible pero que en realidad es un workaround.
El registro de CI hace la fusión auditable
Sin un registro, la decisión de fusión existe en un hilo de chat o en la memoria de una persona. El registro de CI debe mostrar el commit, el resultado del nuevo escaneo, el resultado de regresión y la aprobación de la revisión. Si el pipeline indica que el commit está limpio, esa afirmación debe estar vinculada al commit exacto que se fusionó.
Ese registro también facilita la revisión del próximo incidente. Si una vulnerabilidad reaparece, puedes ver si la corrección original fue verificada, si la suite marcó una regresión o si la fusión ocurrió antes de que existiera la evidencia. Fusiona solo cuando el registro de CI muestre que el nuevo escaneo, la suite de regresión y la revisión humana coinciden todos en el mismo commit.
