Tu herramienta de IA para programar podría estar subiendo todo tu repositorio

Respuesta rápida

Asume que cualquier herramienta de IA agéntica para programar (de las que leen tus archivos y editan código) puede transmitir tu repositorio a su proveedor. Algunas lo hacen al arrancar, antes de cualquier prompt. Para defenderte: (1) nunca ejecutes una CLI agéntica interactiva dentro de un repo con secretos o código que no puedas compartir; (2) mantén los secretos fuera del árbol rastreado (.gitignore) y fuera de los archivos que el agente lee; (3) prefiere modos headless de un solo uso o una API REST antes que la sesión interactiva; (4) si debes, hazlo en un directorio desechable sin nada sensible. Audita antes de confiar —el método está abajo.

Qué acaba de pasar — el caso Grok Build

El 12 de julio de 2026, testers independientes informaron que Grok Build (la CLI agéntica de xAI, v0.2.93) sube el repositorio git entero del usuario —como un bundle que incluye el historial completo y archivos que el agente nunca abrió— al Google Cloud Storage de xAI. Las pruebas midieron varios gigabytes saliendo de la máquina.

Preguntada directamente, la cuenta oficial @grok de xAI lo confirmó con sus propias palabras: «El análisis independiente a nivel de red (capturas con mitmproxy + pruebas de archivos canario) confirma que Grok Build CLI sube tu repo Git completo como un bundle —incluyendo el historial completo y archivos que el agente nunca lee— al Google Cloud Storage de xAI por defecto. Archivos leídos como secretos .env también se envían literalmente. Esto no lo detiene el toggle 'Mejorar el modelo'.» Añadió que la subida es «el diseño actual para un rendimiento agéntico fiable» y que los controles granulares estaban «en desarrollo activo».

Lo importante para tu modelo de amenaza: la subida se dispara al arrancar la herramienta, no cuando le pides algo. Un usuario que la abrió y no escribió nada igual vio su repo enviado.

Por qué lo hacen las herramientas agénticas

No es (necesariamente) malicia —es el diseño. Un agente que razona sobre tu base de código quiere contexto completo y consistente: cada archivo, el historial git, las relaciones entre módulos, para que sus subagentes y worktrees no trabajen desde una vista parcial rota. La forma más rápida de darle eso a un modelo en la nube es subir el repo entero de entrada. Comodidad para el agente, exposición para ti.

Ese trade-off es invisible salvo que mires. La herramienta "simplemente funciona", y los varios gigabytes que salen de tu tarjeta de red no aparecen en la ventana de chat. Es exactamente el tipo de default que un operador consciente de la privacidad debe asumir presente hasta que se demuestre lo contrario.

Qué se filtra en realidad

• Todo el código rastreado —cada archivo commiteado a git, lo haya leído el agente o no.
• El historial de commits completo —no solo el árbol actual. Cualquier cosa alguna vez commiteada y luego "eliminada" sigue viva en el historial y sube con el bundle. Borrar un secreto en un commit posterior no lo borra del repositorio.
• Los archivos que el agente lee —enviados literalmente. Si abre un .env para entender la config, ese archivo se va con él, aunque esté en gitignore.
• No lo controla el toggle obvio —en el caso Grok, el opt-out "Mejorar el modelo" no detuvo la subida. Los opt-outs que esperarías que ayudaran pueden no tocar esta ruta.

La aritmética del riesgo — qué te salva y qué no

Dos mecanismos deciden tu exposición:

• El bundle git lleva archivos rastreados + historial. Así que un secreto que nunca se commiteó —en un archivo gitignoreado como .env / .dev.vars— no está en el bundle. Por eso la disciplina de .gitignore es tu primera y más barata línea de defensa.
• La captura de archivos leídos lleva lo que el agente abra, esté en gitignore o no. Así que .gitignore por sí solo no basta si luego dejas que el agente lea el archivo de secretos. Mantén los secretos totalmente fuera del alcance del agente.

Ejemplo real: auditamos nuestra propia exposición tras ejecutar una CLI agéntica en un repo real. Nuestros secretos vivos estaban en un .dev.vars gitignoreado y nunca commiteado —así que estuvieron ausentes del bundle subido. El único archivo env rastreado tenía una clave de sitio pública (segura por diseño). Resultado neto: nuestro código e historial subieron; nuestros secretos no. .gitignore trazó esa línea. Podría haber ido al revés para un repo que commitea su .env.

No es solo tu repo — la sesión se lleva todo tu entorno

Aquí está la parte que hace de .gitignore un falso consuelo. Cuando un desarrollador hizo que un segundo agente de IA (una CLI OpenAI Codex) inspeccionara qué había hecho la herramienta interactiva en su Mac, la auditoría halló que el contexto filtrado llegó mucho más allá del repo rastreado. Junto al bundle git, la sesión había capturado:

• el árbol de directorios de un proyecto adyacente —estructura de código, archivos de paquete, nombres de assets y dependencias que nunca se le pidieron;
• el texto de un documento de traspaso / notas en ese proyecto;
• salida de terminal con el nombre de usuario de macOS, nombres de cuentas locales y una dirección de correo —identidad del mundo real, no código;
• rutas a los archivos de proyecto y sesión locales de otra herramienta de IA —en efecto, un mapa del resto del stack del desarrollador.

Nada de eso cae bajo el alcance de .gitignore. Gitignore mantiene archivos fuera del bundle git; no hace nada con la salida de terminal, los archivos en carpetas vecinas, o las huellas de tus otras herramientas que una sesión interactiva lee e integra en su contexto. En el momento en que abres una sesión agéntica en un entorno de trabajo, el entorno es la superficie de ataque —tu usuario, tu correo, tus repos adyacentes, tus notas. Para un operador seudónimo ese par usuario-más-correo lo es todo: puede deshacer meses de compartimentación en una sola subida.

La lección no es "gitignorea más fuerte". Es que el único límite fiable es el directorio en que lanzas la herramienta —y todo lo que ese directorio y tu shell pueden alcanzar. Trata una CLI agéntica interactiva como si fotografiara toda la habitación, no solo el archivo sobre el escritorio.

Audita tu propia herramienta — el método que sobrevive a la noticia

No confíes en el blog de un proveedor ni en la captura de un extraño, incluida esta. Verifica en tu propia máquina. Tres técnicas, la más barata primero:

1. Archivos canario. Deja un archivo con nombre único y una cadena aleatoria única en un repo de prueba (p. ej. CANARY-9f2c4a.txt). Ejecuta la herramienta. Luego busca en el almacenamiento del proveedor, en la exportación de datos de tu cuenta, o simplemente observa si esa cadena aparece en algún cuerpo de solicitud. Si un archivo que nunca referenciaste sale de la máquina, tienes tu respuesta.
2. Captura a nivel de red. Apunta la herramienta a través de un proxy interceptor local (mitmproxy) y lee lo que realmente envía. Busca subidas multipart, cargas bundle/tar/git y tamaños de solicitud muy superiores a tu prompt. Así se probó el comportamiento de Grok; es reproducible en una tarde.
3. Tamaño de salida (egress). Aun sin descifrar TLS, observa los bytes totales enviados justo tras el arranque (un monitor de red por app, o nettop / iftop). Una pregunta de una línea que dispara una subida de varios gigabytes lo dice todo.

Hazlo una vez por herramienta, y repítelo tras actualizaciones importantes —el comportamiento cambia en silencio entre versiones.

Aíslala — política práctica

• Nunca lances una TUI agéntica interactiva dentro de un repo real. Ese bundle al inicio de sesión es el peor infractor. Si necesitas la experiencia interactiva, hazlo en un directorio desechable que contenga solo los archivos que estás dispuesto a compartir.
• Prefiere modos headless / de un solo uso. Muchas herramientas tienen un modo no interactivo de "responde este prompt" que no empaqueta el repo. En nuestras pruebas de una de ellas, la invocación headless -p no subió nada, mientras que abrir la TUI interactiva en un repo sí. Verifica la tuya igual —la distinción importa.
• Usa una API REST en vez de la CLI donde sea posible —las llamadas API suelen enviar solo el contexto que pasas, no el árbol entero.
• Gitignorea los secretos con devoción, y nunca apuntes el agente a un archivo de secretos. Mantén .env / material de claves fuera del árbol rastreado y del alcance de lectura del agente.
• Los niveles empresariales de "cero retención de datos" existen para algunas herramientas —pero son una promesa contractual, no una garantía técnica verificable. Trátalos en consecuencia.
• Auto-aloja el modelo para trabajo genuinamente sensible. Un modelo local (ver nuestra guía de modelos locales) no envía nada a nadie. Es la única opción que saca al proveedor de tu modelo de amenaza por completo.

En resumen

Las herramientas de IA agénticas para programar son una superficie de exfiltración genuinamente nueva: un programa que invitaste a entrar, que lo lee todo y, por defecto, puede enviarlo hacia arriba —en silencio, al inicio de sesión, sorteando los toggles que esperarías que te protegieran. La revelación de Grok Build es notable solo porque el proveedor lo confirmó en voz alta; asume la misma postura de toda herramienta agéntica hasta que verifiques lo contrario. Mantén los secretos fuera del árbol y de las manos del agente, ejecuta sesiones interactivas en directorios desechables, prefiere modos headless y —para lo que de verdad importa— ejecuta el modelo localmente. Los defaults de comodidad se fijan para el proveedor. Tu modelo de amenaza es tu trabajo.