Una investigación independiente de CEREBLAB documentó que Grok Build CLI podía empaquetar un repositorio completo, incluido su historial Git, y enviarlo a almacenamiento remoto incluso cuando la instrucción no requería abrir archivos. El investigador reprodujo el comportamiento, recuperó el proyecto desde el tráfico capturado y confirmó que el 13 de julio una bandera del servidor desactivó la carga. xAI no publicó en la fuente revisada una admisión equivalente.
✦ La evidencia se basó en tráfico capturado y reconstrucción
Cómo se reprodujo la transferencia
El investigador instaló un proxy local con un certificado de confianza para observar las solicitudes salientes del cliente. Luego ejecutó Grok Build CLI dentro de un repositorio de prueba y entregó una instrucción mínima: responder sin abrir archivos. A pesar de esa condición, registró una solicitud hacia un endpoint de almacenamiento cuyo cuerpo comenzaba con la firma de un bundle Git. Esa señal permitió tratar el contenido como un paquete reconstruible, no como telemetría abstracta.
Al clonar los bytes capturados, CEREBLAB recuperó archivos que el agente no había necesitado leer y varios commits del historial. La distinción es crítica. Un repositorio Git puede conservar secretos eliminados del estado actual, configuraciones antiguas, nombres internos y ramas que el usuario cree fuera del contexto activo. Por eso excluir un archivo desde una instrucción o ignorarlo durante la conversación no protege necesariamente la información contenida en el historial empaquetado.
La prueba se repitió en una segunda base de código y fue acompañada por hashes, capturas y pasos de reproducción. La investigación también comparó el comportamiento con otros agentes de programación. Esas comparaciones deben leerse como resultados del entorno probado, no como garantías permanentes sobre todos los productos. El hallazgo principal se sostiene por la observación directa del tráfico y la reconstrucción del bundle enviado.
El cambio del servidor y sus límites
El 13 de julio, el mismo cliente recibió desde el servidor las opciones trace upload enabled en falso y disable codebase upload en verdadero. La carga dejó de dispararse durante la nueva prueba. CEREBLAB señaló correctamente un límite causal: la cronología permite verificar que el comportamiento cambió, pero no demuestra que la publicación haya provocado la corrección. Tampoco sustituye una explicación oficial sobre qué versiones, usuarios o períodos estuvieron afectados.
El investigador distinguió además entre transmisión y retención. Un comando de privacidad podía modificar cómo se conservaban determinados datos, pero no era necesariamente el control que impedía que abandonaran el equipo. Para un desarrollador, esa diferencia es esencial. Una política de no utilizar datos para entrenamiento, una promesa de borrado y un bloqueo técnico de la transferencia son controles distintos y deben probarse por separado.
La fuente revisada presenta el problema como corregido para el comportamiento de carga completa observado. Aun así, un gate de seguridad responsable evita afirmar que ninguna información sale del cliente: los agentes necesitan comunicarse con servicios remotos para procesar instrucciones y pueden enviar prompts, archivos abiertos o trazas según su diseño. La conclusión comprobada es más estrecha: la transferencia automática del bundle completo dejó de ejecutarse en la repetición documentada.
Un gate mínimo antes de usar agentes con código privado
La seguridad de un agente no puede evaluarse únicamente por su interfaz. Debe observarse qué información abandona el equipo, bajo qué configuración y con qué capacidad de reconstrucción.
- Ejecutar pilotos en repositorios señuelo y observar tráfico antes de autorizar proyectos sensibles.
- Escanear todo el historial Git, rotar secretos expuestos y usar credenciales temporales con privilegios mínimos.
- Separar contractualmente transmisión, retención, entrenamiento y borrado, con evidencia para cada control.
✦ Una opción no sustituye los otros controles
Qué deben revisar los equipos de desarrollo
La primera medida es tratar cualquier agente remoto como un componente con acceso potencial a datos sensibles. Antes de ejecutarlo, conviene limpiar secretos del historial, usar credenciales de corta duración y trabajar en una copia con alcance mínimo. Un archivo punto env ignorado por Git no resuelve secretos incluidos en commits anteriores. Herramientas de detección de secretos y rotación de llaves deben acompañar la adopción, especialmente en repositorios con años de actividad.
La segunda medida es observar el comportamiento real. Las políticas del proveedor son necesarias, pero no reemplazan controles de red, inventarios de destinos y pruebas con repositorios señuelo. Las organizaciones pueden ejecutar un piloto en un entorno aislado, capturar solicitudes y definir qué tipos de datos tienen autorización para salir. Si el producto cambia mediante banderas del servidor, esas pruebas deben repetirse después de actualizaciones importantes.
Finalmente, los contratos y procedimientos internos deben diferenciar acceso, transferencia, retención y uso para entrenamiento. Cada concepto necesita una respuesta verificable. El caso también muestra por qué las configuraciones seguras deben venir activadas por defecto. Pedir a cada desarrollador que descubra un comando de exclusión después de iniciar una sesión traslada un riesgo sistémico a decisiones individuales difíciles de auditar.
✦ Confiar después de observar, no antes
Preguntas Frecuentes
✦ ¿xAI confirmó oficialmente la investigación?
La fuente primaria revisada corresponde a CEREBLAB, un investigador independiente. El cambio del servidor fue observado y reproducido, pero no debe presentarse como una admisión oficial de xAI sin un comunicado adicional.
✦ ¿El problema seguía activo el 13 de julio?
Durante la repetición documentada ese día, el servidor entregó una bandera que desactivó la carga completa y el comportamiento dejó de ejecutarse. Eso no equivale a una auditoría de todas las transferencias posibles del cliente.
✦ ¿Un archivo ignorado por Git queda protegido?
No necesariamente. Si el secreto existió en un commit anterior, puede permanecer dentro del historial. Además, una herramienta puede leer archivos locales por mecanismos distintos al bundle. Hay que limpiar historial, limitar permisos y observar tráfico.
La confianza en un agente de programación debe construirse con controles observables. Una opción de privacidad, una política de retención y un bloqueo de red no significan lo mismo. El aprendizaje práctico es revisar el sistema como revisaríamos cualquier integración con acceso al código: alcance mínimo, secretos rotables, telemetría visible y una salida segura cuando la evidencia no coincide con la promesa.
Fuente original: CEREBLAB
