Grok CLI subió todo el directorio de inicio a GCS
Se descubrió que una herramienta de programación para el modelo Grok de xAI subía automáticamente todo el directorio de trabajo —en un caso reportado, la carpeta de inicio de un usuario, incluidas las claves SSH— a un bucket de Google Cloud Storage sin un aviso explícito ni una advertencia clara. Los comentaristas debaten cuánto de la culpa recae en el usuario por ejecutar estas herramientas fuera de sandboxes frente al proveedor por diseñar un flujo predeterminado que exfiltra en silencio datos sensibles. El incidente se cita como evidencia de que los agentes de IA remotos y los harnesses propietarios deben tratarse como software no confiable, y ejecutarse solo con un aislamiento estricto a nivel del sistema operativo (contenedores, VMs, usuarios separados) y con acceso mínimo a secretos reales o archivos personales.
Resumen del incidente
- El usuario ejecutó la CLI oficial de Grok Build en
$HOME; el análisis de red sugiere que creó untary subió todo el directorio de trabajo actual (en este caso, el directorio de inicio) a Google Cloud Storage. - Esto parece ocurrir automáticamente al iniciar la sesión, no como una “decisión” del LLM, y no se limita a los archivos solicitados explícitamente en un chat.
- Algunos comentaristas señalan que
repo_pathestaba configurado como el directorio de inicio, pero otros sostienen que eso aun así no justifica una exfiltración total.
Cómo se comporta la CLI (según la discusión)
- Un gist compartido afirma que el harness empaqueta de forma determinista la carpeta desde la que se ejecuta y la sube, probablemente para indexación semántica/embeddings de la base de código.
- Eso incluiría claves
.ssh, archivos.envy otros secretos si viven dentro del directorio elegido. - Un comentarista informa no haber visto este comportamiento en sus propios registros; no está claro si depende de la configuración, de la versión o de si es un error.
Preocupaciones de seguridad y privacidad
- Muchos consideran que esto es peor que
rm -rf /: en lugar de pérdida de datos, se trata de una filtración sin cifrar a un tercero. - Críticas contundentes a que la CLI:
- Lo haga en silencio, sin un opt-in explícito.
- Trate “confía en este directorio” como “sube todo este directorio a nosotros”.
- Hay amplio acuerdo en que las barreras en Markdown (por ejemplo, “no leas X”) no son límites de seguridad; solo importan los controles a nivel del sistema operativo.
Responsabilidad vs. error del usuario
- Un bando: los usuarios deben asumir que cualquier agente en la nube puede leer/subir todo lo que puede ver; ejecutar estas herramientas en
$HOMEsin aislamiento es un error del usuario. - Otro bando: culpar a los usuarios es culpar a la víctima; no se puede esperar que usuarios normales anticipen una exfiltración de todo el directorio desde una CLI al primer uso. La seguridad por defecto es responsabilidad del proveedor.
Mitigaciones y patrones propuestos
- Ejecutar agentes en:
- Usuarios del sistema operativo separados con permisos limitados.
- Contenedores (Docker/Podman/devcontainers), microVMs (smolvm, Kata, etc.) o VMs completas.
- Herramientas que usen bubblewrap, Landlock o sandboxes similares.
- Copiar o montar solo el repositorio del proyecto en el sandbox (a menudo un clon desechable), no todo el directorio de inicio.
- Evitar poner secretos en repositorios o archivos planos; usar keychains cifrados y rotar las claves si se sospecha exposición.
Reflexiones más amplias sobre IA e industria
- Muchos lo comparan con spyware: los harnesses de agentes de código cerrado se consideran inherentemente no confiables.
- El escepticismo es especialmente fuerte hacia proveedores percibidos como negligentes con la seguridad y los datos; algunos dicen que evitarán Grok por completo.
- Tema recurrente: las CLI de agentes son, en la práctica, endpoints de ejecución remota de código; hasta que el aislamiento robusto se vuelva estándar (y más fácil para no expertos), se espera que incidentes como este se repitan.