Ejecuta un workflow agéntico de GitHub Actions y verifica fugas

El comportamiento en el límite es la prueba

Estás decidiendo si un agente de código puede ejecutarse en GitHub Actions con trabajo real. El agente puede ser competente y aun así filtrar un secreto si el límite es descuidado. La prueba útil es si el artefacto compilado, los permisos y la ruta de fallo se mantienen dentro del límite que declaraste, incluso cuando el agente solo está redactando una nota de triaje o resumiendo un issue.

GitHub Agentic Workflows alcanzó disponibilidad general el 28 de octubre de 2026. La versión GA añadió Actions Runner Controller, Docker-in-Docker, opciones adicionales de motor y enrutamiento de modelos, pronósticos de gasto y opciones extra de aislamiento. Trata las nuevas opciones como perillas adicionales, no como confianza adicional. Esas opciones amplían la superficie, por lo que el preflight siguiente mantiene la superficie lo suficientemente pequeña para inspeccionarla.

Cinco comprobaciones mantienen la superficie pequeña

Ejecuta estas comprobaciones antes de que el workflow toque trabajo real. Cada paso debería tomar un minuto si la configuración es honesta.

• Fija el artefacto compilado. El compilador gh-aw verifica la fuente del workflow y escribe un lockfile con extensión .lock.yml. Commitea ese archivo y haz que el workflow se ejecute a partir de él. Si el runner puede obtener un archivo fuente más nuevo, el artefacto que revisaste no es el artefacto que se ejecutó.
• Confirma que el job del agente es de solo lectura. Por defecto, los agentes de GitHub Agentic Workflows operan en modo de solo lectura y se ejecutan en un contenedor aislado protegido por Agent Workflow Firewall. Configura el job del agente en modo de solo lectura y verifica que aún se ejecute en ese sandbox predeterminado. Un alcance de escritura en el job del agente es una señal de alerta a menos que puedas nombrar la salida exacta que necesita.
• Acota cada job de salida. Da a cada job de salida solo el permiso que necesita para escribir su artefacto. Si un job puede actualizar una rama, un paquete o tocar un secreto, pregúntate qué haría si el agente se equivocara.
• Alimenta entradas malformadas y de inyección de prompt. Ejecuta el workflow contra un cuerpo de issue malformado y un issue que le dice al agente que ignore sus instrucciones. El paso es un fallo acotado: sin escritura, sin escalado, sin secreto en el log.
• Fija una versión revisada. Verifica la versión de gh-aw instalada y confirma que es actual y revisada. Las versiones 0.83.3 a 0.85.3 del repositorio fuente de GitHub Agentic Workflows fueron retiradas tras una vulnerabilidad de seguridad. Una versión antigua fijada es una fuga que puedes programar.

La lista es corta porque los modos de fallo son cortos. Si el artefacto es mutable, el permiso es amplio o la ruta de entrada no está probada, el workflow no está listo para trabajo real.

Una ejecución puntual no es suficiente

No ejecutes las comprobaciones una vez y declares el workflow seguro. Coloca las entradas de prueba en un directorio de fixtures, nombra el fallo esperado antes de la ejecución y haz que la pipeline falle cuando el agente escriba fuera de la ruta de salida esperada. Una ejecución manual puntual es una conversación. Una comprobación repetible es una prueba.

Para un workflow de triaje, la escritura esperada suele ser estrecha: una etiqueta, un comentario o una transferencia. Eso hace la comprobación de permisos más fácil, porque el job de salida solo debería necesitar el alcance mínimo para producir ese artefacto. Si el agente puede hacer más de lo que el workflow necesita, la capacidad extra es un incidente futuro con una mejor interfaz.

Mantén el preflight cerca de la definición del workflow. Vuelve a ejecutar las comprobaciones tras un cambio de artefacto, un cambio de versión o un nuevo permiso de salida. Si un cambio se aplica sin una nueva ejecución, mantén el workflow fuera del trabajo real.

La licencia y la disponibilidad son parte del límite

GitHub Agentic Workflows está disponible en github.com para usuarios de GitHub Free, Team y Enterprise. El mismo preflight se aplica tanto si estás probando en un repo pequeño como si lo ejecutas en toda una organización. No lo saltees porque el entorno parezca descartable.

Si el workflow usa el motor predeterminado GitHub Copilot CLI, se requiere una licencia de Copilot. Ponlo en el mismo preflight que los permisos, porque una ruta de acceso ausente también es un modo de fallo. El agente debería fallar de forma visible, no caer silenciosamente en algo que no revisaste.