GitHub Agentic Workflows pasó a disponibilidad general el 28 de octubre de 2026. Antes de que un repo lo prenda, cerrá tres cosas: quién puede habilitar salidas con escritura, qué triggers le pasan texto no confiable a un agente y el presupuesto de AI credits. Por defecto el agente sólo lee y toda escritura pasa por safe outputs.
¿Qué lanzó GitHub el 28 de octubre de 2026?
GitHub anunció ese día la disponibilidad general de Agentic Workflows, un proyecto open source de GitHub Next. Sirve para automatizar tareas que piden razonamiento, como triage de issues, análisis de fallas de CI, actualización de documentación y escritura de tests. Ese trabajo lo hacen coding agents que corren dentro de GitHub Actions.
La automatización se escribe en Markdown, en lenguaje natural, y un compilador la convierte en YAML estándar de Actions. Para el gobierno de la plataforma eso pesa. Como son Actions, reutilizan los runner groups y las restricciones de policy que ya tenés.
Cada workflow puede usar GitHub Copilot u otro coding agent. La página de arquitectura de seguridad nombra a Copilot, Claude Code, OpenAI Codex, Google Gemini y Pi. Está disponible en github.com para GitHub Free, Team y Enterprise. El motor por defecto, Copilot CLI, exige licencia de Copilot.
Desde la public preview se sumó soporte para runners self-hosted de Actions Runner Controller con Docker-in-Docker. El proveedor de modelo se elige por workflow, y hay un model router que optimiza según tipo de tarea y dificultad. Los agentes también pueden correr en una micro-VM de Cloud Hypervisor o NVX, con enclaves que evitan fugas de datos en workflows entre repositorios.
GitHub dice que instalás la extensión del CLI y disparás el primer workflow en minutos. Con esa velocidad, conviene tener la policy resuelta antes de que el primer repo lo pruebe.
¿Qué permisos tiene por defecto un agentic workflow?
Por defecto, un agentic workflow tiene permisos de sólo lectura. La referencia de permisos dice que las escrituras pasan por safe outputs, que suman un job extra. GitHub da cuatro razones para esa separación: deja un audit trail, achica el blast radius si el agente se porta mal, soporta gates de aprobación de compliance y defiende contra prompt injection.
Hay detalles que cambian lo que tiene que mirar quien revisa. El compilador agrega por su cuenta actions: read, para chequear que el workflow generado esté al día. Con copilot-requests: write pasa otra cosa. Lo agrega el autor, a propósito, para inferencia de Copilot facturada a la organización, y el compilador nunca lo pone por defecto.
El punto de control real es el bloque de safe outputs. La referencia cataloga muchos tipos de escritura, desde agregar un comentario hasta crear un pull request o hacer push a la rama de un PR. Un workflow que puede subir código tiene un riesgo distinto del de uno que sólo pone labels. La misma referencia documenta patrones de labels bloqueados y un staged mode para safe outputs. Leelos antes de que salga el primer workflow con escritura.
Encima de los permisos, el anuncio lista más capas. Los agentes leen contenido de GitHub respetando las reglas del integrity filter y corren en un contenedor sandbox detrás del Agent Workflow Firewall. Un job dedicado de threat detection escanea todos los cambios propuestos antes de aplicarlos. El modelo de amenazas de la documentación asume un adversario capaz de comprometer contenedores y otros componentes de usuario no confiables, pero no el hardware.
¿Por qué importa la prompt injection en un agente de CI?
Importa porque un agente de CI lee texto escrito por gente de afuera de tu equipo. Un paper de arXiv enviado el 8 de mayo de 2026 llama a esta falla Agentic Workflow Injection. Ocurre cuando contexto no confiable de un evento, como el cuerpo de un issue, la descripción de un PR o un comentario, termina en el prompt del agente o en un input que el agente consume.
Los autores describen dos patrones. En Prompt-to-Agent, el contenido no confiable llega directo al prompt. En Prompt-to-Script, la influencia del atacante viaja por la salida del modelo o del agente hasta scripts que corren después. Con esa definición, un step común que consume salida del agente también es superficie de ataque.
Aplicaron su herramienta, TaintAWI, a 13.392 agentic workflows reales de 10.792 repositorios. Reportó 519 vulnerabilidades potenciales, y 496 se confirmaron explotables bajo el modelo de amenazas del paper, con una precisión del 95,6 %. De esas, 343 eran zero-days desconocidos. Priorizaron 187 para disclosure, recibieron 26 respuestas de maintainers y 24 casos estaban aceptados o corregidos al cierre del paper.
La conexión con este release está en los triggers. Todo workflow que arranca por un issue, un PR o un comentario recibe texto no confiable. La propia página de arquitectura de GitHub nombra la prompt injection entre las amenazas que sus capas buscan frenar.
¿De qué depende el costo de Agentic Workflows?
Depende de dos cosas que nombra el anuncio: el gasto en AI credits y la licencia de Copilot que pide el motor por defecto, Copilot CLI. Para los credits, el comando gh aw forecast dejó de ser experimental con el GA. Incluye los credits de threat detection y da rangos mensuales, así que el escaneo de seguridad entra en la estimación.
Dos decisiones de facturación le tocan al dueño de la plataforma. Una es el motor, porque cada workflow puede usar otro agente en vez de Copilot. La otra es copilot-requests: write, que el autor activa para inferencia facturada a la organización. La documentación tiene páginas de cost management sobre billing, rate limiting y auditoría de workflows.
Controles para definir antes de que un repo lo active
| Control | Qué ofrece la documentación | Decisión del dueño de la plataforma |
|---|---|---|
| Permisos por defecto | Sólo lectura, escrituras vía safe outputs. Existe el atajo read-all |
Mantener sólo lectura. Revisar cualquier read-all como un cambio más |
| Salidas con escritura | Comentarios, labels, creación de PR, push a la rama de un PR, staged mode | Habilitar primero comentarios y labels. Lo que sube código pasa por revisión de plataforma |
| Permiso de facturación | copilot-requests: write es opt-in, nunca default del compilador |
Definir quién puede agregarlo |
| Gasto | gh aw forecast con credits de threat detection y rangos mensuales |
Correrlo antes de habilitar y anotar el rango |
| Triggers | Issues, descripciones de PR y comentarios, la entrada que describe el paper de arXiv | Listar cada workflow con agente que se dispara por ese input |
| Aislamiento | Sandbox, Agent Workflow Firewall, micro-VM, enclaves | Exigir enclaves en workflows entre repositorios |
| Runners | Runner groups y policies existentes, ARC con Docker-in-Docker | Correr los agentic workflows en un runner group dedicado |
Qué revisar esta semana
Dale a la revisión cinco días hábiles y un único responsable.
Para el martes, hacé el inventario. Buscá cada workflow de la organización que llama a un agente de IA y marcá los que se disparan por issues, pull requests o comentarios. Esos encajan con el patrón del paper.
Para el miércoles, escribí la policy por defecto. Los agentic workflows quedan en sólo lectura. Agregar copilot-requests: write necesita aprobación de plataforma. Cualquier safe output que cree un PR o haga push a una rama recibe la misma revisión que una deploy key.
Para el jueves, elegí un piloto de bajo riesgo en un repo interno. Entre los ejemplos de GitHub Next hay uno de triage, que sirve para arrancar. Corré gh aw forecast y anotá el rango mensual antes de ponerlo en marcha.
Para el viernes, leé las páginas de safe rollout y de compiler controls de la documentación. Decidí si los workflows entre repositorios tienen que usar enclaves. Ningún repo pasa del piloto hasta tener esa decisión.
Fuentes
- github.blog/changelog/2026-10-28-github-agentic-workflows-generally-…, consultada el 30 de octubre de 2026.
- github.github.com/gh-aw/introduction/architecture, consultada el 30 de octubre de 2026.
- github.github.com/gh-aw/reference/permissions, consultada el 30 de octubre de 2026.
- github.github.com/gh-aw/reference/safe-outputs, consultada el 30 de octubre de 2026.
- arxiv.org/abs/2605.07135, consultada el 30 de octubre de 2026.