GitLost no significa que cualquier repositorio privado de GitHub pueda robarse desde un issue público. Sí muestra una combinación peligrosa para los agentes de IA: datos privados, entrada no confiable y una salida pública dentro del mismo flujo.

Agente de IA con frontera de confianza entre issues públicos y repositorios privados

Noma Labs publicó GitLost el 6 de julio. El objetivo fue GitHub Agentic Workflows, una función en preview que permite describir automatizaciones de repositorio en Markdown y ejecutarlas con un agente dentro de GitHub Actions. GitHub habla de tokens de solo lectura por defecto, sandboxing, safe outputs y un escaneo de amenazas antes de publicar resultados.

En la prueba de Noma, un issue público logró guiar al agente para leer contenido de un repositorio privado y pegarlo en un comentario público. Según Noma y The Hacker News, el atacante no necesitaba credenciales robadas ni acceso al repo privado. El riesgo venía de la arquitectura: el agente leía input público, tenía lectura amplia sobre repositorios privados y podía responder en un canal público.

Qué ocurrió

Agentic Workflows permite escribir workflows en lenguaje natural. La CLI gh-aw los compila a GitHub Actions, y el agente puede revisar issues, pull requests, fallos de CI o tareas de mantenimiento.

Eso suena a productividad. En seguridad, también es una cuenta de servicio con una interfaz en lenguaje natural.

El flujo probado por Noma se activaba cuando se asignaba un issue. Leía el título y el cuerpo, y respondía con un comentario. Además, tenía acceso de lectura a otros repositorios de la organización. El issue parecía una petición normal de negocio. Cuando el workflow se ejecutó, el agente extrajo contenido de un repo público y de uno privado, y lo publicó en el issue abierto.

No hace falta convertir la prueba en un tutorial. El punto defensivo es otro: un filtro no es una frontera de seguridad. Si el único límite es que el modelo decida si una petición suena sospechosa, tarde o temprano fallará.

El alcance es limitado, pero importante

GitLost necesita varias condiciones: un workflow agentic activo, input público o controlado por un atacante, un token que pueda leer repos privados y una salida visible desde fuera. No es una fuga universal.

Pero muchos flujos empresariales empiezan a parecerse a eso. Un agente lee tickets, pull requests, eventos de Sentry, mensajes de soporte o comentarios. Busca contexto interno. Luego publica una respuesta. La utilidad nace de conectar zonas de confianza; el riesgo también.

La etiqueta read-only puede engañar. Un token de solo lectura no puede hacer push, pero sí puede leer información sensible. Si el agente puede enviar texto a un canal público, la lectura ya puede bastar para exfiltrar datos.

La trifecta letal

La idea de Simon Willison funciona bien aquí: datos privados, contenido no confiable y comunicación externa. En GitLost, los datos privados son el contenido del repositorio, el contenido no confiable es el issue público y la comunicación externa es el comentario público.

Quita una pieza y el riesgo cambia. Un issue público sin acceso a repos privados es menos peligroso. Un análisis privado sin salida pública es más difícil de convertir en fuga. Un bot que comenta en público pero no lee repos privados tiene menos que perder.

Qué revisar antes de activar agentes

Haga tres preguntas: qué puede leer el agente, quién puede escribir en su contexto y dónde puede publicar resultados.

Si las respuestas son repositorios privados, cualquier usuario que abra un issue y comentarios públicos, detenga el flujo. No es una simple automatización; es una ruta de exfiltración.

Use tokens por repositorio o por propósito. Evite acceso de lectura a toda la organización por comodidad. Separe agentes públicos y privados. El agente que responde a issues públicos no debería ser el mismo que analiza repositorios sensibles.

Añada aprobación humana cuando un resultado privado vaya a salir de la frontera. Registre el issue que inició el run, los repos leídos, el token usado, el output propuesto y quién lo aprobó.

Qué deben mejorar los proveedores

Las plataformas de agentes necesitan etiquetas de confianza visibles. El contenido de issues públicos, PR externos, logs, páginas web y herramientas MCP debe conservar su origen. Una política debería poder decir: este texto puede ayudar al análisis, pero no puede autorizar lectura privada ni escritura pública.

También hacen falta permisos comprensibles. Read-only no basta si el agente puede leer datos privados y hablar en público. Autonomous no basta si el administrador no ve qué herramientas, repositorios, outputs y rutas de red están disponibles.

GitLost no es una razón para abandonar la automatización con IA. Es una razón para dejar de tratar a los agentes como chats. Un agente en un workflow de desarrollo es un actor con credenciales. La regla práctica es sencilla: no una input público, datos privados y output público en un agente desatendido.