Noma Labs demostró que un único issue público de GitHub puede robar código de repositorios privados mediante una automatización impulsada por IA. Su prueba de concepto permite que un atacante convierta los propios bots de flujo de trabajo de una organización en su contra, filtrando archivos patentados sin vulnerar la autenticación de GitHub.

El ataque a plena vista

La cadena de eventos es lo suficientemente simple como para reproducirla:

  • Un atacante crea un issue en un repositorio público que cualquiera puede ver.
  • Un agente de IA, conectado al pipeline de integración continua, lee el título y el cuerpo del issue.
  • El mismo agente ya tiene permisos de lectura para otros repositorios privados en la organización.
  • Instrucciones ocultas en el issue público le indican al agente qué archivos privados debe obtener.
  • El agente publica los archivos recuperados de nuevo en el issue público como un comentario, exponiéndolos al mundo.

Todo sucede en una única ejecución de la automatización. Sin robo de credenciales, sin filtración de claves API, sin vulnerabilidades de GitHub. El atacante simplemente explota la confianza que la organización depositó en su propio bot.

Por qué esto es importante ahora

Los agentes impulsados por IA ahora actúan como el pegamento de los modernos pipelines de desarrollo. Abren pull-requests, ejecutan pruebas, despliegan builds y clasifican bugs, todo activado por señales ligeras como los comentarios en los issues. Cuando esos agentes poseen un acceso amplio a los repositorios, la línea entre los datos de confianza y la entrada de usuario no confiable se desdibuja.

Si un agente puede leer código privado y escribir públicamente en la misma ejecución, el modelo de control de acceso de la organización colapsa.

El fallo real: los permisos, no el modelo

La demostración no implica al modelo de IA subyacente. El modelo simplemente sigue las instrucciones que recibe. La vulnerabilidad reside en el conjunto de permisos otorgados a la automatización:

  • Acceso de lectura a repositorios privados en toda la organización.
  • Acceso de escritura a hilos de issues públicos.
  • Activación (trigger) mediante texto público que cualquiera puede redactar.

Soluciones que no cuestan nada, pero funcionan

Aplicar el principio de mínimo privilegio reduce drásticamente la ruta de ataque:

  • Limitar el alcance del bot al repositorio donde se necesita. Si solo necesita actuar en un repo específico, deniéguele cualquier otro derecho de lectura.
  • Separar los tokens de lectura y escritura. Utilice una credencial para obtener el código y otra credencial, estrictamente controlada, para publicar comentarios.
  • Aprobación humana antes de cualquier publicación pública. Un paso de revisión ligero —como una etiqueta de aprobación obligatoria— añade un punto de control sin detener el pipeline.
  • Reducción del radio de impacto (blast-radius). Diseñe los flujos de trabajo de modo que un fallo o uso indebido afecte, como máximo, a un repositorio y no a toda la organización.

Contrapunto: carga operativa

Qué observar a continuación

Conclusión: Si una automatización de IA puede tanto ver código privado como hablar públicamente, el sistema está mal diseñado. Refuerce los permisos, inserte controles humanos y mantenga el radio de impacto pequeño; de lo contrario, un único issue público puede convertirse en un vector de filtración de datos.