GitLost: Hicimos que el agente de IA de GitHub filtrara repos privados

Naturaleza de la vulnerabilidad

• GitHub Agentic Workflows estaban configurados para:
  • Leer títulos y cuerpos de issues públicas.
  • Responder mediante comentarios públicos.
  • Tener acceso de lectura a otros repos de la organización, incluidos los privados.
• Los atacantes podían inyectar instrucciones en issues públicas que hacían que el agente leyera repos privados y pegara el contenido de vuelta como comentarios públicos.
• Varios comentaristas subrayan que el fallo clave es una frontera de confianza ausente entre el contenido no confiable de issues y el acceso a repos privados.

¿Quién tiene la culpa?

• Una postura: esto es principalmente una mala configuración del usuario.
  • Los investigadores concedieron explícitamente al agente acceso org-wide a repos y le permitieron procesar issues públicas no confiables.
  • Analogía: darle secretos a un trabajo de CI y luego ejecutarlo en PRs públicas.
• Otra postura: esto es un fallo de diseño de GitHub.
  • Los usuarios razonables esperan que un agente en un repo público no filtre repos privados ajenos.
  • Los permisos son demasiado gruesos y GitHub no hace que la configuración segura sea fácil ni obvia.

Prompt injection y guardrails (no) solucionables

• Muchos argumentan que el prompt injection es inherente a los LLM: la entrada del usuario son instrucciones, así que no hay una forma sólida de separar “código” de “datos.”
• Comparaciones con SQL injection:
  • Similar en que la entrada no confiable cambia el comportamiento.
  • Pero a diferencia de SQL, no existe un equivalente de las prepared statements; los guardrails son solo más texto de entrada y pueden ser anulados.
• Algunos lo ven más como ingeniería social: solo puedes mitigar mediante procesos y control de acceso, no “arreglar” el modelo.

Permisos, arquitectura y mitigaciones

• Una visión ampliamente compartida: las únicas defensas reales son arquitectónicas:
  • Ejecutar agentes con los mismos permisos o permisos más estrictos que los del usuario que los invoca; nunca con acceso “root”/org-wide.
  • Delimitar agentes a un único repo o a flujos de trabajo estrechamente definidos; segmentar flujos con distintos tokens.
  • Restringir las escrituras de agentes que manejan entrada pública, incluso si pueden leer datos privados.
  • Aislar agentes y darles sus propias credenciales; tratarlos como usuarios no confiables.
• Algunos sugieren mejores UIs para permisos por prompt/por flujo de trabajo y tokens de GitHub más granulares.

Confianza en GitHub, la nube y las integraciones de IA

• Escepticismo hacia GitHub/Microsoft:
  • Percepción de “IA en todas partes” impulsada por presión de inversores, lo que lleva a funciones apresuradas e inseguras.
  • Preocupaciones de que los datos de repos privados alimenten el entrenamiento de Copilot salvo exclusión explícita.
• Un subgrupo visible aboga por migrar a forges autoalojados (Forgejo, Codeberg, bare git) para evitar la integración de IA y recuperar el control.

Reflexiones más amplias

• Varios comentaristas ven esto como otro ejemplo de una débil cultura de seguridad (“negligencia criminal”, envío “YOLO”).
• Temas de consenso:
  • Los LLM deben tratarse como otra capa de interfaz, no como un backend privilegiado.
  • No se puede confiar en guardrails a nivel de modelo; solo las barreras de seguridad duras y un diseño de mínimo privilegio reducen el riesgo de forma significativa.