Su asistente de programación con IA acaba de leer su cartera
Las herramientas de programación con IA leen los archivos .env antes de que usted escriba nada. Sus claves de API —cada una de ellas una tarjeta de crédito sin límite de gasto— están en la ventana de contexto de alguien más antes de que escriba su primer prompt. El problema no es la IA. El problema es que los secretos son archivos.
Abra su asistente de programación con IA. Antes de que usted escriba un solo carácter, ya ha leído su directorio de proyecto. Su archivo .env. Sus claves de API. La contraseña de su base de datos. Su clave secreta de Stripe.
Usted no se lo pidió. Usted no lo aprobó. Es una función, no un error: la herramienta necesita el contexto del proyecto para ser útil. Así que lee todo lo que un desarrollador puede leer.
Y un desarrollador puede leerlo todo.
La versión greentext
Un post ha circulado esta semana, escrito como un monólogo interno de un desarrollador:
> Abre Claude Code. Tu .env se lee antes de que escribas nada. Tus claves de API están ahora en el chat. Añades "no leer .env" a CLAUDE.md. No funciona.
380.000 personas vieron ese post. 2.700 lo guardaron en marcadores. No porque fuera una novedad, sino porque era un espejo.
Todo desarrollador que lo leyó pensó lo mismo: esa es mi configuración.
Las instrucciones no funcionan
Lo primero que la gente intentó fue escribir reglas. «No leer archivos .env». En CLAUDE.md, en AGENTS.md, en los system prompts. Prohibiciones directas y explícitas.
La herramienta leyó los archivos de todos modos.
Esto tiene sentido si se lo piensa. El archivo se lee como parte de la construcción del contexto del proyecto, antes incluso de que se procesen las instrucciones. Decirle al modelo que no lea un archivo que ya ha leído es como decirle a alguien que olvide lo que acaba de ver. La información está en la ventana de contexto. Ya se ha transmitido. La instrucción llega después del daño.
Un investigador descubrió que incluso las reglas de denegación a nivel de archivo podían eludirse mediante scripts personalizados o cadenas de tuberías. Otro detectó facturas elevadas de su proxy porque sus credenciales HTTP_PROXY se estaban cargando y utilizando automáticamente.
El dinero en su .env
La gente plantea esto como un problema de privacidad. Es un problema económico.
Abra un archivo .env típico en un proyecto de producción:
OPENAI_API_KEY=sk-... STRIPE_SECRET_KEY=sk_live_... AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgresql://user:pass@...
Esa clave de OpenAI es una tarjeta de crédito sin límite de gasto y sin PIN. Quien tenga esa cadena puede ejecutar 40.000 $ en llamadas a la API de la noche a la mañana. La clave de Stripe puede emitir reembolsos, crear cargos y acceder a los datos de pago de los clientes. Las credenciales de AWS —dependiendo de la política de IAM, que casi con seguridad es demasiado amplia— pueden levantar instancias GPU, acceder a buckets de S3 o eliminar infraestructura.
Esto no es una lista de contraseñas. Es una lista de carteras, cada una con un saldo distinto y sin candado.
29 millones de carteras en la acera
El último informe de GitGuardian contabilizó 28,6 millones de secretos expuestos en commits públicos de GitHub en 2025. Un aumento del 34 % respecto al año anterior, y el mayor incremento anual que han medido jamás.
Las cifras específicas de IA son peores. 1,2 millones de secretos de servicios de IA expuestos: un aumento interanual del 81 %. Los commits coautorados por herramientas de programación con IA filtraron secretos a una tasa aproximadamente el doble de la línea base. Y se encontraron 24.000 secretos únicos en archivos de configuración de MCP: la tubería que conecta a los agentes de IA con servicios externos.
Doce de los quince tipos de secretos filtrados de más rápido crecimiento eran servicios de IA. No bases de datos. No proveedores de nube. Servicios de IA.
Las herramientas que estamos usando para escribir código más rápido están filtrando las claves de los sistemas a los que ese código se conecta.
El problema real
El desarrollador que publicó ese hilo greentext terminó con una solución práctica: una configuración en settings.json que bloquea las lecturas de archivos. Funciona. Por ahora, para esa herramienta.
Pero el problema real no es Claude Code ni Cursor ni Copilot. El problema real es que los secretos son archivos.
Un archivo .env es un documento en texto plano que reside en disco, legible por cualquier proceso que se ejecute como su usuario. Antes de las herramientas de programación con IA, los procesos que leían su proyecto eran git, npm, node, su editor. Usted confiaba en ellos implícitamente. No pensaba en el hecho de que sus secretos estaban a un comando cat de quedar expuestos.
Las herramientas de programación con IA simplemente han hecho explícito lo implícito. Leen su proyecto igual que cualquier otra herramienta; simplemente ocurre que envían el contexto a algún sitio que usted puede ver.
Su pipeline de CI también lee archivos .env. Su ejecutor de pruebas también. Su linter también. Su compilación de Docker también. Ninguno de ellos pidió permiso tampoco. Simplemente usted no se dio cuenta porque no le mostraron una transcripción de chat con lo que encontraron.
El patrón subyacente
El 70 % de los secretos filtrados en 2022 siguen activos hoy. No rotados. No revocados. Seguían funcionando, seguían concediendo acceso, tres años después.
Esta es la cifra real. No 29 millones de filtraciones: un 70 % que nunca se corrigió. Porque rotar una clave implica encontrar todos los sistemas que la utilizan, actualizar cada despliegue, probar cada integración. La clave se creó una vez, se pegó en un archivo .env y nunca más se pensó en ella. El coste de filtrarla es instantáneo. El coste de corregir la filtración es ilimitado.
Así que la mayoría de las organizaciones no lo corrigen. No pueden. No saben qué claves están dónde, cuáles siguen activas, cuáles se han copiado en otros archivos .env de otras máquinas por otros desarrolladores que necesitaban sacar adelante una funcionalidad un viernes por la tarde.
Lo que esto significa realmente
Cada archivo .env es una apuesta. Una apuesta a que ningún proceso lo leerá sin estar autorizado a hacerlo. Una apuesta a que ninguna herramienta lo enviará a un sitio inesperado. Una apuesta a que ningún desarrollador lo commiteará por accidente.
29 millones de veces el año pasado, alguien perdió esa apuesta. Solo en GitHub público. Los repositorios privados —donde GitGuardian encontró secretos en el 35 % de los repositorios— ni siquiera están contados.
La solución no es una regla en settings.json. La solución no es una entrada en .gitignore. La solución no consiste en escribir «DO NOT READ .ENV» en mayúsculas en su archivo de instrucciones.
La solución es que el secreto no debería estar ahí desde el principio. No en un archivo. No en una variable de entorno cargada desde un archivo. No en ninguna forma que un proceso con sus permisos pueda leer haciendo lo que hacen los procesos: leer archivos en su directorio de proyecto.
Si el secreto está en disco, se leerá. La única cuestión es cuándo y por qué.
---
Fuentes
- GitGuardian — State of Secrets Sprawl 2025 — 28,6 M de secretos filtrados, tendencias de credenciales de servicios de IA, estadísticas de remediación
- GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — Cobertura de Help Net Security con desglose específico de IA
- Claude Code Can Consume, Transmit, and Compromise Your .env Files — Análisis de Martin Paul Eve sobre el fracaso de las prohibiciones en CLAUDE.md
- Claude Code Automatically Loads .env Secrets, Without Telling You — Análisis técnico de Knostic sobre la carga automática de secretos
- From .env to Leakage: Mishandling of Secrets by Coding Agents — Análisis más amplio de Knostic sobre Claude y Cursor
- @zodchiii on X — El post viral que motivó este artículo (380.000 visualizaciones, 2.700 marcadores)