GitLost: Hicimos que el agente de IA de GitHub filtrara repos privados
Los investigadores demostraron que un “agentic workflow” de GitHub impulsado por un LLM podía ser inducido, mediante comentarios públicos en issues, a filtrar código de repositorios privados, a pesar de los guardrails destinados a impedirlo. Los comentaristas debaten si esto es principalmente una mala configuración del autor del flujo de trabajo o un fallo arquitectónico más profundo en la forma en que GitHub concede a los agentes acceso amplio entre repos, pero en general coinciden en que nunca se debe confiar a los LLM permisos más allá de los del usuario solicitante. El incidente alimenta un escepticismo más amplio sobre las integraciones de IA apresuradas, la viabilidad de defenderse del prompt injection y si el código sensible debería alojarse en plataformas que acoplan estrechamente agentes de IA con el acceso a repositorios.
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.