Cuando el agente de IA de tu CI/CD se convierte en el atacante: Microsoft revela cómo un prompt injection en la GitHub Action de Claude Code exponía los secrets de tu pipeline

Los equipos de desarrollo que usan GitHub Actions con agentes de inteligencia artificial tienen un nuevo vector de riesgo que entender. El 5 de junio de 2026, Microsoft Threat Intelligence publicó en su blog de seguridad el análisis completo de una vulnerabilidad que sus investigadores descubrieron y divulgaron responsablemente en la GitHub Action oficial de Claude Code de Anthropic: mediante técnicas de prompt injection, un atacante externo podía instruir al agente de IA para que leyera el entorno del runner de CI/CD — incluyendo API keys, cloud credentials y tokens de GitHub — y los exfiltrara a través de los logs del workflow, un comentario en el repositorio o una llamada web. Todo ello con un simple comentario HTML invisible para el revisor humano pero legible por el modelo. El parche está disponible desde el 5 de mayo en Claude Code 2.1.128. Pero la lección que deja este incidente va mucho más allá de una GitHub Action concreta: cualquier agente de IA que procese contenido no confiable de GitHub mientras tiene acceso a secrets y capacidad de actuar externamente es un riesgo de seguridad de primer orden.

‍

¿Qué descubrió Microsoft y cómo funcionó el ataque?

Los hechos documentados por Microsoft Threat Intelligence (Microsoft Security Blog, 5 junio 2026), GBHackers, CybersecurityNews y Decrypt son los siguientes:

• La vulnerabilidad: la GitHub Action de Claude Code incluía un tool llamado Read para que el agente de IA leyera archivos del repositorio. A diferencia del tool Bash (que sí estaba correctamente sandboxeado), el tool Read no estaba sujeto al mismo entorno de aislamiento y podía acceder a ficheros del sistema del runner, incluyendo /proc/self/environ — el fichero que contiene todas las variables de entorno del proceso, donde los runners de GitHub Actions almacenan las API keys, tokens y credentials inyectados como secrets.
• El vector de prompt injection: un atacante sin ningún acceso especial al repositorio — solo con capacidad de abrir un issue o enviar un pull request — podía insertar una instrucción maliciosa dentro de un comentario HTML (<!-- instrucción -->). El comentario HTML es completamente invisible cuando el issue se renderiza en el navegador, pero el modelo de IA lee el markdown en bruto y ve las instrucciones.
• El payload y la técnica de evasión: el equipo de Microsoft construyó un payload que le pedía al modelo hacer una “revisión de compliance” (para no activar los filtros de seguridad de Claude, que bloquean peticiones directas de imprimir API keys), leer /proc/self/environ, y después “recortar los 7 primeros caracteres del resultado”. Este paso adicional era clave: el prefijo ANTHR de ANTHROPIC_API_KEY son exactamente 7 caracteres, lo que permitía evadir tanto los filtros del modelo como el GitHub Secret Scanner — que detecta patrones de API keys conocidas pero no fragmentos recortados.
• Exfiltración: con el secret en mano, el agente podía enviarlo a través de un fetch web a un servidor externo, escribirlo en los logs del workflow (visibles públicamente en repositorios públicos) o incluirlo en un comentario de GitHub. El atacante recupera la API key sin ningún acceso directo al repositorio ni a los secrets.
• Alcance de los secrets en riesgo: ANTHROPIC_API_KEY fue el ejemplo documentado, pero los runners de GitHub Actions pueden contener el GITHUB_TOKEN, cloud credentials (AWS, Azure, GCP), tokens de terceros (npm, Docker, Terraform) y cualquier otro secret inyectado en el workflow.
• Divulgación responsable: Microsoft reportó la vulnerabilidad a Anthropic vía HackerOne el 29 de abril de 2026. Anthropic publicó el parche en Claude Code 2.1.128 el 5 de mayo, bloqueando el acceso del tool Read a ficheros sensibles de /proc/.
• Segunda vulnerabilidad relacionada: de forma independiente, el investigador RyotaK de GMO Flatt Security documentó otra vulnerabilidad en Claude Code GitHub Actions (parcheada en v1.0.94) que permitía a un atacante externo no autenticado exfiltrar secrets, robar tokens OIDC y hacer push de código malicioso a repositorios downstream mediante la combinación de un fallo en checkWritePermissions con técnicas de prompt injection.

‍

Por qué los agentes de IA en CI/CD son una superficie de ataque de nuevo orden

El incidente de la GitHub Action de Claude Code no es una anomalía aislada — es la primera documentación pública de una clase de vulnerabilidades que afectará a todos los equipos que estén integrando agentes de IA en sus pipelines de desarrollo. Microsoft lo deja explícito: “començamos esta investigación después de observar intentos de prompt injection en repositorios públicos usando workflows de GitHub asistidos por IA de múltiples proveedores”. No es un problema de Claude Code. Es un problema de cómo están siendo desplegados los agentes de IA en entornos CI/CD de alta confianza.

1. Los runners de CI/CD son entornos de alta confianza con acceso privilegiado. Un runner de GitHub Actions puede tener acceso a cloud credentials de producción, tokens de deploy, claves SSH, y acceso a la infraestructura completa que el pipeline gestiona. Cuando un agente de IA con acceso a estos entornos procesa contenido no confiable (issues, PRs, comentarios de cualquier usuario), el trust boundary colapsa.
2. El prompt injection es el vector de ataque definitivo contra agentes de IA. A diferencia de los exploits de software tradicionales, el prompt injection no requiere vulnerabilidades en el código: aprovecha la propia capacidad del modelo de entender y seguir instrucciones en lenguaje natural. Cualquier agente que procese texto no confiable puede ser redirigido hacia acciones maliciosas con las instrucciones adecuadas.
3. Los mecanismos de evasión son simples y efectivos. La técnica del comentario HTML invisible es la más simple: el revisor humano aprueba el issue o PR sin ver las instrucciones, pero el modelo las ejecuta. Más sofisticadas son las instrucciones disfrazadas de tareas legítimas (“compliance review”) que evitan los filtros de seguridad del propio modelo.
4. La proliferación de agentes de IA en CI/CD es rápida y adelanta a las prácticas de seguridad. Claude Code, GitHub Copilot, Cursor, Devin y otros agentes de IA para desarrollo se están integrando en pipelines sin los mismos controles de seguridad que aplicaríamos a cualquier otro sistema con acceso a producción. Es el mismo patrón que vimos con las extensiones de VS Code (TeamPCP/Nx Console) el mes pasado: la confianza en la herramienta precede a la auditoría de seguridad.

‍

Cómo funciona el ataque: del issue de GitHub al secret exfiltrado

1. El atacante crea un issue o PR con payload oculto. Dentro del cuerpo del issue, en un comentario HTML (<!-- >), el atacante inserta instrucciones en lenguaje natural diseñadas para que el modelo de IA las ejecute. El texto visible del issue parece completamente normal.
2. El workflow de CI/CD procesa el issue con el agente. Muchos equipos configuran GitHub Actions para que el agente de IA revise issues, clasifique bugs, genere respuestas automáticas o ejecute tareas de triaje cuando se abre un nuevo issue o PR.
3. El agente lee las instrucciones ocultas y las ejecuta. El modelo ve el markdown en bruto, incluyendo el contenido del comentario HTML. Las instrucciones le piden hacer algo que parece razonable (una revisión, una comprobación) pero que en realidad incluye leer /proc/self/environ.
4. El tool Read accede al entorno del runner. Sin el sandboxing adecuado, el tool Read del agente puede acceder a /proc/self/environ y leer todas las variables de entorno del proceso, incluyendo los secrets inyectados por GitHub Actions.
5. El modelo launderú el output para evadir filtros. Las instrucciones incluyen un paso de limpieza del output (recortar caracteres, reformatear) que evita que el GitHub Secret Scanner detecte el patrón de la API key.
6. Los secrets llegan al atacante. El agente exfiltra el valor a través de un comentario público en el issue, los logs del workflow o una llamada a un servidor externo. El atacante recupera la API key sin haber tenido acceso a los secrets del repositorio en ningún momento.

‍

Lecciones clave: la “Agents Rule of Two” de Microsoft y el checklist de hardening

Microsoft Threat Intelligence introdujo en su análisis un principio de diseño de seguridad para workflows de IA que los equipos de DevSecOps deberían adoptar inmediatamente: la “Agents Rule of Two”. Un workflow de IA nunca debería tener simultáneamente las tres capacidades siguientes:

• 1. Procesamiento de input no confiable (issues, PRs, comentarios de GitHub, cualquier contenido generado por usuarios externos).
• 2. Acceso a secrets sensibles (API keys, cloud credentials, tokens de deploy, claves SSH).
• 3. Capacidad de actuar externamente o modificar estado (tools como Bash, WebFetch, GitHub MCP, escritura en archivos, push a repositorios).

Si un workflow tiene dos de estas tres capacidades, el riesgo es gestionable. Si tiene las tres simultáneamente, el trust boundary ha colapsado y el agente puede ser weaponizado.

Checklist de hardening inmediato para equipos con agentes de IA en GitHub Actions:

• Actualizar Claude Code GitHub Action a la versión 1.0.94 o superior (parche de RyotaK) y usar Claude Code 2.1.128 o superior (parche de Microsoft). Verificar la versión del action en el archivo .github/workflows/ del repositorio.
• Aplicar la Agents Rule of Two: si el workflow procesa issues o PRs de usuarios externos, eliminar el acceso a secrets de producción o deshabilitar los tools que permiten acciones externas.
• Principio de mínimo privilegio en cada token: cada API key y credential del workflow debe estar limitada a los permisos mínimos que ese workflow necesita. Un agente que clasifica issues no necesita cloud credentials.
• Separar workflows de triaje de workflows con acceso privilegiado: usar repositorios separados o jobs separados para la parte que procesa contenido de usuarios y la parte que tiene acceso a producción.
• Monitorizar comportamiento anómalo del agente: configurar alertas si el agente intenta acceder a archivos fuera del directorio de trabajo, hace llamadas web a dominios no esperados, o genera outputs inusualmente largos en workflows de triaje.
• Auditar todos los workflows de GitHub Actions que usen agentes de IA — no solo Claude Code, sino también GitHub Copilot, Cursor, Devin y cualquier otro — contra la Agents Rule of Two.

‍

La ciberseguridad como prioridad estratégica

El incidente de la GitHub Action de Claude Code llega exactamente cuando la adopción de agentes de IA en pipelines de desarrollo está acelerándose a máxima velocidad. Los equipos de ingenieria están integrando agentes de IA para revisar PRs, clasificar bugs, generar documentación y automatizar tareas de mantenimiento — y en muchos casos lo están haciendo en los mismos workflows que tienen acceso a producción. La investigación de Microsoft no dice que los agentes de IA no deban usarse en CI/CD: dice que su integración requiere los mismos controles de seguridad que aplicaríamos a cualquier otro sistema con acceso privilegiado. El patrón es el mismo que con las extensiones de VS Code (TeamPCP/Nx Console), los paquetes npm comprometidos (TanStack) y las vulnerabilidades en herramientas de desarrollo que hemos documentado este mes: la velocidad de adopción de herramientas de desarrollo supera sistemáticamente la velocidad de auditoría de seguridad.

‍

Apolo Cybersecurity: seguridad de agentes de IA y pipelines CI/CD

En Apolo Cybersecurity ayudamos a equipos de desarrollo a auditar la seguridad de sus workflows de GitHub Actions con agentes de IA: evaluación de workflows contra la Agents Rule of Two, revisión de permisos y accesos de tokens en CI/CD, detección de vectores de prompt injection en workflows que procesan contenido de usuarios, hardening de entornos de runners, y revisión de las versiones de Claude Code GitHub Action, GitHub Copilot y otros agentes de IA integrados en pipelines de producción.

Si tu equipo usa Claude Code, Copilot o cualquier otro agente de IA en tus GitHub Actions y esos workflows tienen acceso a secrets de producción, este lunes por la mañana es el momento de revisar si la Agents Rule of Two se cumple en tu arquitectura.

‍