La herramienta de codificación Grok Build de SpaceXAI ha sido objeto de escrutinio después de que investigadores de seguridad descubrieran q...
La herramienta de codificación Grok Build de SpaceXAI ha sido objeto de escrutinio recientemente, después de que un investigador de seguridad descubriera que su herramienta de línea de comandos (CLI) subía repositorios enteros de Git al almacenamiento en la nube, en lugar de enviar únicamente los archivos necesarios para la tarea de codificación.
Según los informes, los datos subidos incluían archivos rastreados, el historial completo de Git, archivos que el agente tenía instrucciones de no leer, e información confidencial que había sido eliminada del árbol de trabajo actual pero que aún permanecía en confirmaciones anteriores. Los datos se enviaban a un depósito de Google Cloud Storage controlado por xAI.
Tras la publicación de los resultados de la investigación, las subidas se han detenido. Los investigadores observaron que los servidores de SpaceXAI comenzaron a devolver lo siguiente:
disable_codebase_upload: true
Elon Musk también declaró que los datos de los usuarios subidos anteriormente se eliminarían por completo. Sin embargo, en el momento de la noticia, no era posible confirmar de forma independiente si todas las copias históricas habían sido eliminadas.
El incidente comenzó con un análisis de red controlado de la CLI de Grok Build.
El investigador, conocido con el seudónimo Cereblab, realizó ingeniería inversa del binario oficial y monitoreó su tráfico de red. En una prueba diseñada para revelar el flujo de datos real de la herramienta, Grok Build empaquetó el repositorio en un paquete Git y lo subió a un depósito de Google Cloud Storage asociado con xAI.
Esto no se limitó a los pocos archivos necesarios para responder a la solicitud.
Según los informes, el paquete capturado contenía:
El informe original de AIbase describe que su alcance de retención era mucho mayor que el de herramientas similares de codificación con IA, como Claude Code.
En una prueba reportada por Axios, Grok Build subió aproximadamente 5.1 GB de datos, mientras que la tarea de codificación en sí misma solo requería unos 192 KB. Este ejemplo ilustra la diferencia entre enviar el contexto relevante para la tarea y transferir el archivo completo del repositorio.
Subir el árbol de código fuente actual ya es un incidente de seguridad grave. Subir el historial completo de Git puede causar aún más daño.
Los desarrolladores suelen eliminar información confidencial de la última versión de un repositorio, pensando que ha desaparecido. En realidad, ese valor podría permanecer en confirmaciones antiguas, a menos que se haya reescrito el historial.
El historial de Git puede contener:
Por lo tanto, el repositorio puede parecer limpio en el directorio de trabajo actual, pero el material sensible aún reside dentro del directorio .git.
Es por esto que instrucciones como "no abras este archivo" no son suficientes para proporcionar una protección adecuada cuando la herramienta empaqueta el repositorio de forma independiente a nivel de Git. Las directivas de permisos a nivel de archivo pueden controlar lo que el agente lee durante el diálogo del modelo, pero no impiden automáticamente que un proceso de subida independiente empaquete el historial del repositorio.
El análisis de Cereblab determinó que el destino era un depósito de Google Cloud Storage controlado por xAI.
El uso de Google Cloud no significa que Google decida de forma independiente la recopilación de los repositorios. El proveedor de almacenamiento en la nube aloja la infraestructura para los clientes y, según los informes, el controlador de datos o el operador del servicio en este caso es xAI o SpaceXAI.
El problema clave es que los datos del repositorio salieron de la máquina del usuario y entraron en una infraestructura en la nube de un tercero.
Para los equipos empresariales, esto puede plantear problemas relacionados con:
Incluso si el proveedor de la nube cuenta con fuertes controles de seguridad, las transferencias no divulgadas o inesperadas pueden violar las propias políticas de gobernanza de la empresa.
Después de que la investigación se hiciera pública, Cereblab probó la CLI nuevamente.
El servidor devolvió:
disable_codebase_upload: true
La subida del repositorio completo ya no se activaba.
Esto parecía ser un cambio en el lado del servidor, ya que los usuarios no necesitaron instalar una nueva versión para que el comportamiento cesara. Una bandera de configuración remota desactivó el proceso de empaquetado del repositorio.
Esta distinción es importante.
Un interruptor en el lado del servidor puede detener rápidamente el comportamiento, pero también indica que el comportamiento de tratamiento de datos del cliente puede depender de una configuración remota. Por lo tanto, las organizaciones que evalúen agentes de codificación deberían verificar el tráfico de red real, y no solo el número de versión local o las pantallas de configuración estática.
Elon Musk respondió públicamente afirmando que todos los datos de usuario subidos antes del cambio serían eliminados "completa y totalmente", sin dejar rastro.
SpaceXAI también declaró que respetará las preferencias de privacidad y que los clientes sujetos a acuerdos de retención cero de datos no conservarán datos de seguimiento ni de código.
Estas son promesas importantes, pero en el momento de la noticia seguían sin respuesta varias preguntas:
La eliminación puede mitigar los riesgos futuros, pero no resuelve automáticamente todos los problemas de seguridad. Si el repositorio contenía credenciales activas, los usuarios deben asumir que esos valores podrían haber salido del entorno local y rotarlos de inmediato.
/privacy no es una solución realSpaceXAI inicialmente guió a los usuarios a usar el comando de la CLI de Grok Build:
/privacy
La documentación oficial de Grok Build describe /privacy como un comando para mostrar o cambiar el estado de privacidad y retención de datos.
El investigador de seguridad descubrió que esta configuración controlaba el comportamiento de retención, no el mecanismo de transferencia del paquete completo del repositorio. En otras palabras, el comando solo podía afectar las operaciones de retención de SpaceXAI después de recibir los datos, pero no era un mecanismo del lado del servidor que impidiera que el repositorio saliera de la máquina local.
La conclusión de Cereblab fue clara:
/privacy es un control de retención a nivel de sesión.disable_codebase_upload.Esta es una de las lecciones más importantes de este incidente.
| Problema de control | Implicación |
|---|---|
| ¿Los datos salen del dispositivo? | Control de transmisión o subida |
| ¿Se almacenan los datos recibidos? | Control de retención |
| ¿Durante cuánto tiempo se almacenan? | Política de período de retención |
| ¿Se utilizan para el entrenamiento del modelo? | Política de uso para entrenamiento |
| ¿Puede el usuario eliminar los datos? | Control de eliminación |
| ¿Puede el usuario verificar la eliminación? | Control de auditoría y garantía |
Un servicio puede prometer no retener datos, pero aun así transmitirlos para su procesamiento en tiempo real. Esto puede ser aceptable bajo acuerdos empresariales documentados por escrito, pero no es lo mismo que mantener los datos localizados.
Los usuarios no deben equiparar "retención cero de datos" con "cero transmisión de datos", a menos que el producto lo garantice explícitamente.
El documento de seguridad de la API de xAI describe la Retención Cero de Datos (ZDR) como una función de nivel empresarial.
Cuando el equipo de la API activa ZDR, xAI indica que las indicaciones, las completaciones y los metadatos asociados se procesan en tiempo real, pero no se almacenan de forma persistente en sus servidores. El documento también explica que las respuestas de la API incluirán el encabezado x-zero-data-retention para que las aplicaciones puedan verificar si ZDR está activo.
Para los casos de uso estándar de la API sin ZDR habilitado, xAI señala que las solicitudes y respuestas pueden almacenarse temporalmente hasta 30 días para fines de auditoría de abuso y mal uso.
Estas políticas de la API son útiles como referencia, pero las organizaciones no deben asumir automáticamente que todos los productos Grok, seguimientos de CLI, canales de transferencia de archivos o cuentas de consumo siguen el mismo ciclo de vida de datos.
Antes de usar Grok Build con repositorios privados, verifique:
El investigador de seguridad independiente, Dr. Łukasz Olejnik, describe la magnitud de los datos: el tiempo de retención es demasiado largo.
La información que podría filtrarse incluye:
El riesgo no se limita al uso malintencionado.
Los grandes archivos de código también pueden filtrarse a través de:
El principio de minimización de datos busca reducir la superficie de ataque. Cuando solo se necesitan unos pocos archivos, cargar todo el repositorio por defecto difícilmente se alinea con este principio.
Los equipos que hayan usado Grok Build antes de que se deshabilitara la función de carga deben actuar como si estuvieran ante una posible filtración de código fuente.
Revise dónde se ejecutó Grok Build.
Registre:
No limite la revisión solo a los archivos que el agente parecía haber abierto.
Utilice herramientas de escaneo de claves aprobadas por la organización para revisar el historial completo, no solo el contenido de la rama actual.
Busque:
Incluso si un secreto se eliminó de la última confirmación, es posible que aún deba rotarse.
Si durante el período afectado existieron credenciales en cualquier parte del historial del repositorio rastreado, revóquelas o rótelas.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
No espere a tener evidencia de que alguien accedió a la copia cargada. La rotación de credenciales suele ser menos costosa que investigar una intrusión posteriormente.
Priorice las credenciales que otorgan:
Después de que el repositorio se haya utilizado con Grok Build, revise los registros de la nube, la gestión de código fuente, CI/CD, bases de datos y servicios internos en busca de actividad anómala.
Busque:
La ausencia de actividad sospechosa no prueba que los datos nunca se hayan filtrado, pero ayuda a evaluar el riesgo inmediato.
Utilice la versión actual de Grok Build y verifique la configuración activa.
La documentación oficial proporciona:
grok inspect
Este comando ayuda a confirmar qué fuentes de configuración se están cargando.
La CLI también ofrece:
/privacy
Úselo para verificar el estado de retención, pero tenga en cuenta que este comando no debe considerarse como evidencia.
Ningún dato sale del dispositivo.
Los usuarios empresariales deben solicitar una respuesta por escrito que cubra:
Las promesas públicas de eliminación son útiles, pero las organizaciones reguladas pueden necesitar evidencia específica de la cuenta.
Si el repositorio contiene código de clientes, datos personales, información regulada o contenido cubierto por acuerdos de confidencialidad, involucre a los equipos internos correspondientes.
Dependiendo del caso, los equipos relevantes pueden incluir:
No tome decisiones de notificación de infracciones basándose únicamente en noticias. Debe basarse en los hechos de exposición de la propia organización y en las leyes aplicables.
Este incidente resalta un problema más amplio en el ámbito de las herramientas de desarrollo con IA.
Los agentes de codificación a menudo requieren permisos amplios porque necesitan buscar en grandes repositorios, ejecutar comandos, leer documentos y modificar archivos. Esta capacidad crea una enorme frontera de privacidad.
Antes de aprobar el uso de un asistente de codificación, los equipos deben evaluar cinco aspectos.
Registre cada tipo de dato que la herramienta podría recopilar:
Pruebe qué contenido sale realmente de la máquina.
La documentación del proveedor es necesaria, pero el comportamiento de red es la evidencia más sólida de la transmisión real.
Utilice un repositorio de prueba aislado que contenga valores canarios inofensivos, luego verifique:
No ejecute la herramienta desde directorios de proyectos no relacionados.
Opte por:
Para implementaciones empresariales, confirme lo siguiente:
El comportamiento de la herramienta puede cambiar debido a actualizaciones automáticas o modificaciones remotas de la configuración.
Vuelva a probar después de:
Cuando los productos cambian rápidamente, la aprobación de seguridad no debería ser permanente.
Las instrucciones del agente se ejecutan a nivel del modelo o del uso de la herramienta. Los componentes separados de telemetría o sincronización podrían no respetar estas instrucciones.
Los controles de privacidad deben existir en la propia tubería de datos.
Los proveedores pueden afirmar que solo envían el contexto necesario, pero los usuarios empresariales necesitan evidencia.
Las garantías útiles incluyen:
La configuración remota puede detener rápidamente las cargas, pero también significa que los usuarios podrían no saber cuándo cambia un comportamiento importante.
Una respuesta madura debería incluir:
Incluso si SpaceXAI elimina todas las copias almacenadas, cualquier credencial contenida en los repositorios cargados debe tratarse según su riesgo de exposición.
La eliminación protege el acceso futuro a la copia del proveedor, pero no cambia las credenciales en sí mismas.
El análisis a nivel de protocolo realizado por Cereblab descubrió que la CLI sube todo el repositorio de Git rastreado como un paquete, incluyendo el historial de confirmaciones y archivos no relacionados con la tarea de codificación actual. Dicho historial puede contener claves que ya se han eliminado del directorio de trabajo actual.
El tráfico capturado muestra que se subió a un depósito de Google Cloud Storage controlado por xAI. Google Cloud es el proveedor de infraestructura; las decisiones sobre productos y procesamiento de datos corresponden a SpaceXAI.
Posteriormente, los investigadores observaron que el servidor devolvió disable_codebase_upload: true, y desde entonces ya no se activa la subida completa del repositorio. El cambio parece haberse realizado del lado del servidor.
/privacy puede evitar la subida del repositorio?Este comando controla la configuración de privacidad y retención, pero Cereblab informa que no es el mecanismo para detener la subida completa del repositorio. Los usuarios deben distinguir entre evitar la transmisión y limitar la retención posterior a esta.
Sí. Musk declaró públicamente que todos los datos de usuario subidos anteriormente se eliminarán por completo. Hasta el momento del informe, no se ha publicado una verificación independiente de dicha eliminación total.
Si al usar Grok Build existían claves en el repositorio rastreado o en su historial de Git, la rotación es una medida prudente. Eliminar la copia almacenada por el proveedor no garantiza que las credenciales no hayan sido expuestas o accedidas.
xAI describe ZDR como una función de API empresarial que procesa entradas y salidas sin persistirlas. Esto no implica necesariamente que los datos nunca abandonen el dispositivo local; las organizaciones deben verificar qué canales de datos de Grok Build están cubiertos.
La función de subida completa del repositorio, que ya fue reportada, se ha desactivado. Sin embargo, cada organización debe evaluar la versión actual, la configuración, los términos de la cuenta, el comportamiento de red y la sensibilidad del repositorio. Una corrección del lado del servidor no sustituye una revisión interna de seguridad.
/privacy.Se descubrió que Grok Build subía todo el repositorio de Git rastreado, incluyendo su historial completo, a un depósito de Google Cloud Storage controlado por xAI, incluso cuando la tarea solo requería una pequeña cantidad de código.
SpaceXAI desactivó la función de subida de repositorios mediante la marca disable_codebase_upload del lado del servidor, y Elon Musk prometió que los datos subidos anteriormente serían eliminados. El comando /privacy, aunque relacionado con la configuración de retención, no es el control para impedir la transmisión del repositorio.
Los desarrolladores que usaron la CLI afectada deben identificar los repositorios relevantes, escanear el historial completo de Git, rotar las credenciales que puedan haber quedado expuestas, revisar los registros y, si es necesario, solicitar información de eliminación específica para su cuenta.
La lección fundamental es simple: la privacidad de las herramientas de codificación con IA debe verificarse a nivel de transmisión de datos, y no puede deducirse únicamente a partir de indicaciones, etiquetas de retención o interfaces de configuración.
Empieza con una sola frase y obtén un sitio completo en minutos.
