📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
El clic rápido sale caro
Yo también soy de los que hacen clic sin leer cuando un agente de código pregunta “¿ejecuto este comando?”. Llevas tres horas depurando, el agente te propone la cuarta vez lo mismo, y la opción sí, y no preguntar de nuevo es demasiado cómoda. Un estudio de apiiro publicado esta semana demostró cuánto cuesta ese hábito: encontraron 2.539 secretos reales en 1.994 repositorios públicos de GitHub, guardados por el propio agente de código, con permiso del dueño del repo.
Cómo termina una contraseña en un archivo de settings
El mecanismo es casi banal. Le pides al agente revisar por qué falla el login en staging, y él arma el comando completo leyendo el valor de tu .env o de tu config: la contraseña va embebida en el string. Antes de ejecutarlo pregunta. Respondes “don’t ask again” y el agente guarda ese comando exacto, secret incluido, en .claude/settings.local.json dentro del proyecto. El archivo está pensado para quedarse en tu máquina, así que el agente lo agrega al git ignore global de tu usuario, no al .gitignore del repo. Si el proyecto se convierte en repo después, o un clon llega a otra máquina, esa protección no viaja con el código. Y peor: del 1.105 repos con secret real que rastrearon, en 539 el propio Claude hizo un commit que tocaba el archivo.
Los números: 104.185 copias públicas de ese archivo, de las cuales 1.122 (el 1,1%) contienen un secret real hoy mismo en la rama principal, con una mediana de 217 días expuestos desde el primer commit. En el lote hay desde un password de producción de Azure Postgres y tokens de Square, hasta 43 credenciales SSH a servidores públicos, incluyendo un par de root vía sshpass. 63 organizaciones afectadas, y una confirmó que su llave estaba activa. Contando historial de git, forks y transcripts de chat guardados en repos, la cifra sube a esos 2.539 secretos distintos. Borrar el archivo hoy no arregla nada: en el historial aparecen otros 734 que ya no existen en ninguna copia actual, y 211 forks siguen arrastrando los mismos.
Lo que el scanner no ve
Lo que más me gustó del análisis es el detalle del scanner. Pasaron gitleaks y TruffleHog por los 104.185 archivos: 215 secretos de los 1.122 escapan a los dos. La razón: ambos buscan patrones de llave, prefijos de proveedor y strings largos aleatorios. Un PGPASSWORD= en el medio de un comando o un sshpass -p es sólo una palabra más en una línea cualquiera. Yo administro varios servidores y tengo cron corriendo agentes con acceso a .env y archivos de credenciales, así que este caso me caló hondo: la allowlist de tu agente es, a todos los efectos, un log en texto plano de cada comando que le aprobaste. Nadie la trata como trata su .env, y debería ser el mismo nivel de cuidado.
Mi recomendación concreta, después de revisar mi propia configuración: rota primero, limpia después. Busca .claude/settings.local.json y .claude/settings.json en todos tus repos y en todo tu historial de git. Trata las carpetas de agentes (.claude/, .cursor/, .gemini/) como si guardaran secretos, en pre-commit y en CI, con un scanner que entienda passwords dentro de comandos, no sólo formatos de API key. Y en vez de aprobar comandos literales con la contraseña pegada, prefiero aprobar patrones tipo Bash(npm run:*) y pasar los valores por entorno, de manera que el agente ejecute el comando pero nunca tenga que escribir el secreto dentro de él.
La cómoda costumbre de aprobar todo para no volver a leer tiene un costo que hoy está medido al decimel: 2.539 razones para mirar tu allowlist ahora, no el lunes.
Fuente: Coding Agents Are Leaking Your Secrets to GitHub, informe de apiiro con datos del 1 al 3 de noviembre de 2026.
Fuente de inspiración: Coding Agents Are Leaking Your Secrets to GitHub – apiiro
