Si alguien de tu equipo empezó a usar un asistente de programación con IA este año, hay bastantes posibilidades de que un archivo de configuración haya acabado en un repositorio con una clave de verdad escrita dentro. No un texto de relleno, ni un ejemplo. Una credencial que funciona, de GitHub, Slack, Notion, tu base de datos o un proveedor de IA al que pagas.
No es una suposición. La empresa de seguridad Hush Security leyó unos 82.000 de esos archivos de configuración en repositorios públicos de GitHub y publicó lo que encontró en agosto de 2026. Me salto la jerga y te doy solo lo que importa a un negocio con un puñado de personas y sin equipo de seguridad.
Qué es en realidad este archivo de configuración
Cuando usas herramientas como Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Codex o JetBrains, estas se conectan a otros programas: tu calendario, tu gestor de proyectos, tu base de datos, una herramienta de diseño. El archivo que dice a cuáles conectarse y cómo iniciar sesión se llama archivo de configuración MCP.
Aquí está la parte que casi ningún dueño llega a oír. A diferencia de un archivo .env, que los desarrolladores aprenden a mantener fuera del control de versiones, estos archivos de configuración están pensados para subirse al repositorio. Así es como un equipo comparte el mismo conjunto de herramientas en el ordenador de cada uno. El diseño es cómodo. Y es también la razón de que los secretos acaben publicados.
Qué encontraron los investigadores
El equipo de Hush Security buscó en GitHub los nombres de archivo de configuración que usan los principales agentes de programación con IA, analizó los archivos y clasificó cada hueco destinado a contener una credencial. La versión corta del informe:
En palabras llanas: el 44% de los huecos de credencial usaba un patrón seguro, como una referencia a una variable de entorno o a un gestor de secretos. Otro 38% contenía marcadores de posición evidentes, del estilo your-api-key-here (aquí va tu clave), y nunca había tenido un secreto real. El 12% restante, más o menos uno de cada ocho, llevaba una credencial que funciona escrita directamente en un archivo pensado para compartirse.
Empeora al entrar en los detalles. De las credenciales encontradas, el 55% no tiene una forma que un escáner pueda reconocer. Herramientas como gitleaks, trufflehog o el propio escaneo de secretos de GitHub buscan patrones: un prefijo ghp_, una cadena de conexión, un formato de clave conocido. Más de la mitad de lo que hay en esos repositorios no coincide con ningún patrón, incluidos los tokens de acceso opacos a servidores internos que no describe la firma de ningún proveedor. Un escáner pasa de largo sin verlos.
Y la exposición no es de alcance reducido. Entre las credenciales filtradas cuyo tipo tiene un alcance definido, el 53% da acceso a toda la organización, la cuenta, el espacio de trabajo o la base de datos. Entre las que tienen una política de caducidad definida, el 80% no caduca nunca por su cuenta. Si sumas las dos cosas, el 24% de todos los secretos escritos a mano son a la vez de alcance amplio y permanentes.
La mezcla de proveedores es la lista que menos querrías ver en público: tokens de acceso personal de GitHub, claves de API de Anthropic y OpenAI, tokens de espacio de trabajo de Slack y Notion, cadenas de conexión de Postgres y Mongo con la contraseña dentro, y claves de nube.
Borrar la línea no deshace la fuga
Esta es la parte que pilla a la gente. Alguien se da cuenta del fallo, borra la línea, sube el cambio y da el asunto por resuelto. No está resuelto.
Hush rastreó el historial de 7.681 archivos de configuración que en algún momento habían llevado una credencial, releyendo cada uno a través de hasta siete revisiones. Encontró 1.394 archivos que aún llevan un secreto en la versión actual, y 243 en los que el secreto se había borrado del último archivo pero sigue siendo perfectamente legible en una versión anterior. El valor no está escondido. Hoy mismo puede leerlo cualquiera que sepa dónde mirar.
Por eso el arreglo no es una limpieza del archivo. Es una rotación: ve al proveedor que emitió la clave, revócala, emite una nueva y guarda la nueva en un sitio que no viva en el repositorio.
La comprobación que toca hacer esta semana
Nada de esto requiere un equipo de seguridad. Requiere una persona y unos veinte minutos. Hazlo en este orden.
- Haz la lista de tus archivos de configuración. Busca nombres como
mcp.json,.mcp.json,claude_desktop_config.json,opencode.json,settings.jsonyconfig.toml. Suelen estar en una carpeta oculta del directorio personal del usuario o dentro del propio proyecto. - Lee cada valor que esté junto a una palabra como KEY, TOKEN, SECRET o PASSWORD. Buscas una cadena larga y aleatoria. Si pone
${GITHUB_TOKEN}o te pide que la escribas al ejecutar, está bien y puedes parar ahí. - Decide dónde vive cada credencial real. Si está en un archivo que se sube a un repositorio, dala por publicada. Si ese repositorio es público, dala por publicada en internet.
- Rota, no borres. Por cada credencial que encuentres en esa situación, ve al proveedor, revoca la clave antigua y emite una nueva. Este es el paso que la gente se salta, y es el único que corta la hemorragia.
- Sustitúyela por una referencia. La nueva credencial va a una variable de entorno o a un gestor de contraseñas, y el archivo de configuración apunta a ella. La guía de Hush es tajante con el orden: nunca subas un secreto escrito dentro del archivo, después pasa a tokens de vida corta y, por último, dale a cada clave un responsable y una fecha de caducidad.
- Apunta lo que has encontrado. Una línea por credencial: qué era, dónde estaba y cuándo se rotó. La próxima vez que alguien pregunte tendrás la respuesta, no una suposición.
Si tu repositorio es público, también puedes comprobarlo tú antes que nadie. El escaneo de secretos de GitHub ya marca las claves que coinciden con un formato conocido, lo que cubre más o menos la mitad de lo que encontró el estudio. La otra mitad le resulta invisible, así que la lectura manual del paso dos no es opcional.
¿Y si nadie de tu equipo escribe código?
Entonces probablemente no tengas estos archivos y puedes cerrar la pestaña. Muchas pymes compraron el año pasado una web, una automatización o un chatbot a una agencia o a un autónomo, y ese trabajo bien puede estar en un repositorio que no has mirado nunca.
Tres preguntas que enviarles, por escrito:
- ¿Alguna de las herramientas de IA que nos montasteis usa un archivo de configuración con una credencial dentro? ¿Ese archivo está en un repositorio, y el repositorio es público?
- ¿Alguna credencial se ha subido alguna vez al repositorio y luego se ha borrado? Si es así, ¿cuáles, y se rotaron con el proveedor?
- ¿Quién es responsable de cada clave y cuándo caduca?
Un proveedor serio responde a las tres en un párrafo. Una respuesta evasiva es también una respuesta, y conviene saberlo antes de la próxima factura.
Qué cambiar de aquí en adelante
Las cifras del estudio describen costumbres, no mala suerte. Tres costumbres explican la mayor parte.
| Costumbre que dejar | Qué hacer en su lugar | A quién protege |
|---|---|---|
| Escribir una clave dentro de un archivo de configuración compartido | Referenciar una variable de entorno o un gestor de secretos | A cualquiera con acceso de lectura al repositorio, ahora y siempre |
| Claves de vida larga y sin caducidad | Tokens de vida corta generados al ejecutarse el agente | La ventana entre la fuga y su descubrimiento |
| Credenciales anónimas que no son de nadie | Un responsable designado y una caducidad por clave | La próxima persona que tenga que revocarla con prisa |
Si usas agentes de IA dentro de un sistema de gestión, la misma lógica aparece en otro sitio. Escribimos sobre qué pasa cuando los agentes de IA reciben acceso a APIs, y la respuesta vuelve siempre a lo mismo: una credencial debe ser estrecha y debe morir por su cuenta.
Nada de esto significa que las herramientas sean peligrosas. Significa que el ajuste por defecto es cómodo, y la comodidad tiene un coste que aparece seis meses después, en un repositorio al que nadie recuerda haber subido nada.
Preguntas frecuentes
¿Cómo sé si una clave mía ya está por ahí fuera?
No lo sabrías, al menos por casualidad. Nadie te avisa. La comprobación realista es la de arriba: abre los archivos de configuración que usan tus herramientas de IA, lee los huecos de credencial y compáralos con las claves que has emitido. Si la misma clave aparece en un repositorio, dalo por hecho: es pública, rótala.
Mi repositorio es privado. ¿Estoy a salvo?
Más a salvo, no a salvo. Un repositorio privado sigue teniendo dentro a cada colaborador, autónomo y exempleado al que invitaste alguna vez, además de las herramientas que lo lean. Los archivos del estudio eran públicos porque el buscador de código llegaba a ellos; los privados no se contaron, lo cual no significa que estuvieran limpios.
La clave se borró hace meses. ¿Aun así hay que rotarla?
Sí. Git conserva la versión antigua del archivo, y esa versión antigua sigue siendo legible para cualquiera con acceso al repositorio. Borrar la línea cambia el archivo actual y nada más. La rotación es el único paso que cierra de verdad la exposición.
¿Esto es solo un problema para empresas con desarrolladores?
No, es un problema de quien toque la herramienta. Los equipos de marketing ya montan sus propios scripts de automatización, y los dueños instalan asistentes de IA en su portátil. Estos archivos son fáciles de crear y fáciles de subir sin querer. Lo que no es fácil es darse cuenta después.
¿No sabes a qué llegan ya tus herramientas de IA?
En BigLobster revisamos cómo se conecta con todo lo demás el software que tu empresa ya paga, encontramos las credenciales que están donde no deberían y te decimos cuáles rotar primero. Sin jerga: la lista y ya.
Pide que revisemos tu configuración