Dentro de GitHub Agentic Workflows: una arquitectura de seguridad para agentes de CI/CD

¿Qué es esto?

El 11 de junio de 2026, GitHub llevó GitHub Agentic Workflows a versión preliminar pública. El producto permite describir una automatización en Markdown escrito en lenguaje natural —clasificar incidencias, analizar fallos de CI, actualizar documentación— y compilarla en YAML estándar de GitHub Actions, gobernado por un agente de código (Claude, Codex o Copilot). Para quien se dedica a la defensa, lo relevante no es la funcionalidad, sino la arquitectura publicada junto a ella.

El artículo de ingeniería que la acompaña, Under the hood: Security architecture of GitHub Agentic Workflows (Landon Cox y Jiaxiao Zhou, 9 de marzo de 2026), expone un modelo de amenazas y un diseño en capas que parten de que el agente no es de confianza por defecto. Es un ejemplo concreto y ya desplegado de cómo ejecutar un agente susceptible de inyección de prompts dentro de un entorno de CI/CD de altos privilegios sin entregarle las llaves —y un contraste útil con la fuga de secretos de la GitHub Action de Claude Code divulgada por Microsoft una semana antes.

Cómo funciona

GitHub Actions ejecuta todo en un único dominio de confianza por defecto: la VM del runner contiene el GITHUB_TOKEN, las credenciales de la nube, los tokens de publicación y las claves de API de terceros, todo visible para cada proceso. Aceptable para automatización determinista, peligroso para un agente no determinista que debe ingerir incidencias, PR y contenido web no confiables. El diseño responde con cuatro principios.

Defensa en profundidad, en tres capas. Una capa sustrato (la VM del runner más contenedores de confianza) aporta aislamiento, mediación de llamadas al sistema y fronteras de comunicación impuestas por el kernel. Una capa de configuración compila el workflow y decide qué componentes se cargan, cómo se conectan y qué tokens van a cada contenedor. Una capa de planificación divide el workflow en etapas con intercambios de datos explícitos, cuya instancia principal es el subsistema «safe outputs» (salidas seguras).

No confiar secretos a los agentes. El objetivo declarado es un acceso nulo del agente a los secretos. El agente se ejecuta en un contenedor dedicado con salida de red filtrada; los servidores MCP corren tras una pasarela MCP de confianza que es la única que posee el material de autenticación MCP; y los tokens de API del LLM residen en un proxy de API aislado, de modo que el agente enruta el tráfico del modelo sin ver jamás el token. Para dar a un agente de código el acceso a archivos que necesita sin los secretos que no necesita, el sistema de archivos del host se monta en solo lectura en /host, ciertas rutas se superponen con tmpfs vacíos, y el agente se ejecuta en una jaula chroot. Esto cierra directamente la clase de fallo tras el hallazgo de Claude Code, donde una herramienta de lectura de archivos alcanzaba /proc/self/environ y extraía la clave ANTHROPIC_API_KEY del runner.

Poner en cola y verificar todas las escrituras. Durante su ejecución, el agente lee el estado de GitHub a través de un servidor MCP de solo lectura y solo puede almacenar en búfer sus cambios mediante un servidor MCP «safe outputs». Una vez que el agente termina, las escrituras en búfer pasan por análisis deterministas que filtran qué operaciones se permiten (p. ej. crear incidencias pero no borrarlas), limitan el volumen (p. ej. como máximo tres PR por ejecución), moderan el contenido y eliminan secretos y URL no deseadas. La versión preliminar pública añade un filtro de integridad, permisos de solo lectura por defecto, el cortafuegos Agent Workflow Firewall y un trabajo dedicado de detección de amenazas que examina los cambios propuestos antes de aplicarlos.

Registrarlo todo. La actividad de red se registra en el cortafuegos, los metadatos de petición/respuesta del modelo en el proxy de API, y las invocaciones de herramientas en la pasarela y servidores MCP, con instrumentación adicional que audita acciones sensibles como el acceso a variables de entorno. El resultado es una reconstrucción forense de extremo a extremo —y, como señala GitHub, cada frontera observable es también un lugar donde una futura política de control de flujo de información podrá imponerse.

Por qué importa

La CI/CD es el objetivo de mayor valor donde un agente puede situarse: contiene tokens de publicación y credenciales de la nube, y sus salidas alimentan directamente la producción. La divulgación de Microsoft del 5 de junio demostró que el escenario no es hipotético —un único comentario de incidencia manipulado, más una herramienta que escapaba al saneamiento del entorno, bastaron para llevarse una clave de API viva. La lección arquitectónica: la inyección de prompts se trata como inevitable, así que al agente se le niegan los secretos, se le niega la autoridad de escritura directa y se le niega cualquier salida no supervisada. Esto coincide exactamente con la regla de dos para agentes de Meta y con cortar la pata de exfiltración de la trifecta letal: incluso totalmente secuestrado, el agente aquí casi no tiene nada que robar ni un canal limpio para enviarlo.

Defensas

El diseño se generaliza a cualquier agente ejecutado en automatización, no solo al de GitHub:

1. No otorgue a los agentes secretos permanentes. Enrute las credenciales del modelo y las herramientas a través de un proxy o pasarela que el agente no pueda leer. Mantenga GITHUB_TOKEN, claves de la nube y tokens de publicación fuera del entorno de proceso del agente.
2. Haga que las escrituras sean «solo propuesta». Almacene en búfer cada cambio de estado y ejecute controles deterministas (lista blanca de operaciones, límites de volumen, moderación de contenido, eliminación de secretos/URL) antes de cualquier commit o merge.
3. Restrinja la salida de red. Coloque al agente tras un cortafuegos con lista blanca; fuerce el MCP a través de una pasarela; trate todo canal saliente como una posible vía de exfiltración.
4. Por defecto, mínimo privilegio. Permisos de solo lectura hasta que una tarea demuestre necesitar más, acotados por workflow y por entorno.
5. Registre en cada frontera de confianza. Los registros del cortafuegos, el proxy y MCP, más la auditoría de accesos al entorno, dan el rastro forense para detectar comportamientos anómalos y validar la política.
6. Trate las descripciones de herramientas y las entradas en lenguaje natural como código no confiable. Fije las versiones, verifique la procedencia y nunca deje que el contenido de incidencias/PR/web se interprete como instrucciones.

Estado

Elemento	Referencia	Fecha	Notas
Artículo sobre arquitectura de seguridad	GitHub (Cox y Zhou)	2026-03-09	Modelo de amenazas + cuatro principios
Versión preliminar pública	GitHub Changelog	2026-06-11	Filtro de integridad, AWF, safe outputs, trabajo de detección de amenazas
Divulgación que lo motiva	Microsoft Threat Intelligence	2026-06-05	La herramienta Read de la Claude Code Action filtró ANTHROPIC_API_KEY; corregido en Claude Code 2.1.128

El encuadre correcto no es «GitHub resolvió la inyección de prompts» —explícitamente no lo hizo, y reserva los controles de flujo de información para trabajo futuro. Es que la forma segura de desplegar un agente susceptible de inyección de prompts en una tubería privilegiada consiste en diseñar para el compromiso: sin secretos, sin escrituras directas, sin salida libre y con un rastro de auditoría completo. Si este trimestre va a conectar un agente a su propia CI/CD, ese es el listón que conviene copiar.