Cómo diseñar un pre-submit security agent con amenaza localizada, triage determinista y fixes revisables

Paso 1 — Define exactamente qué evento dispara la revisión. Empieza en un punto donde el cambio sea pequeño y todavía reversible: pre-commit, pull request, configuración antes de desplegar o tool call antes de ejecutar. El agente necesita recibir un diff, no todo el sistema por defecto. Define también qué tipos de archivos o acciones están dentro de alcance y cuáles pasan por otros controles. El disparador debe ser idempotente: revisar dos veces el mismo contenido no puede crear efectos nuevos. Guarda un identificador del artefacto y de la revisión para que los reintentos reutilicen resultados cuando la evidencia no haya cambiado.

Paso 2 — Construye contexto localizado y estructural. Añade solo la información necesaria para entender el riesgo: símbolos afectados, dependencias, llamadas relevantes, permisos, reglas del repositorio y un modelo de amenaza específico del componente. Evita volcar documentos completos si el cambio toca una función pequeña. Cuando necesites ampliar contexto, hazlo por relaciones verificables como imports, call graph o ownership. Etiqueta cada pieza con procedencia y versión. Esa estructura permite que el agente explique por qué pidió información adicional y facilita reproducir la revisión más tarde. El objetivo es reducir ruido sin perder la conexión causal entre cambio y riesgo.

Paso 3 — Separa detector y triage. Usa una primera capa rápida para proponer candidatos y una segunda para decidir si justifican interrumpir al desarrollador. El triage puede combinar reglas deterministas, análisis estático y otro agente con un prompt distinto. Exige evidencia mínima: ruta de datos, condición vulnerable, escenario de explotación o una prueba que falle. Un hallazgo que solo diga “podría ser inseguro” no debería bloquear automáticamente. Asigna severidad y confianza, pero no uses una cifra como criterio único. La regla de bloqueo debe considerar impacto, precisión histórica de la categoría y posibilidad de revisión inmediata.

Paso 4 — Genera el fix como un artefacto separado. Si el sistema puede proponer una corrección, entrégala como diff y nunca como escritura silenciosa al branch principal. Incluye explicación breve, pruebas afectadas y supuestos. Ejecuta tests y análisis sobre el parche antes de ofrecerlo. Si el fix cambia comportamiento fuera del área inicial, aumenta el nivel de revisión. Conserva el hallazgo original aunque el parche se acepte, vinculado al commit que lo resolvió. Así el sistema puede demostrar que la alerta no desapareció por un cambio de posición o porque el detector dejó de verla en una ejecución posterior.

Paso 5 — Diseña estados y una salida de emergencia. Cada finding necesita estados como open, fixed, falsepositive, acceptedrisk y superseded, con actor y motivo. Permite que una persona mantenga un hallazgo abierto aunque el agente crea que se resolvió. Si el servicio de IA falla, define qué ocurre: las categorías críticas pueden bloquear; otras pueden permitir con marca pendiente y una revisión posterior. Esa política debe estar acordada antes del incidente. El agente nunca debería improvisar si la ausencia de su propia revisión significa detener producción o degradar con seguridad. La resiliencia también forma parte del control.

Paso 6 — Mide el sistema por resultados, no por actividad. Registra precisión por categoría, falsos positivos, tiempo de triage, tiempo hasta fix, porcentaje de sugerencias aceptadas, vulnerabilidades que reaparecen y carga humana. Revisa periódicamente las reglas que generan ruido y usa patrones repetidos para mejorar librerías o templates. Ejecuta un corpus de regresión cada vez que cambies modelo o prompt. En Goatify, el mismo patrón puede proteger publicaciones, campañas o automatizaciones: cambio pequeño, contexto localizado, verificación, propuesta reversible y estado auditable. La seguridad agentic deja de ser una demo cuando el control se puede medir y reproducir.