¿Los agentes de código con IA filtran más secretos? Las cifras de GitGuardian 2026 y una lista de 10 minutos

Según el State of Secrets Sprawl 2026 de GitGuardian, los commits asistidos por Claude Code filtraron un secreto el 3,2 % de las veces, frente a una base del 1,5 % en el conjunto de commits públicos de GitHub. El mismo texto cuenta 24.008 secretos únicos en archivos de configuración relacionados con MCP en GitHub público, 2.117 de ellos válidos. Son mediciones reales y tienen límites: describen repositorios públicos, comparan con todos los commits y la propia GitGuardian advierte de que la diferencia no debe leerse como un fallo de la herramienta. Esta guía recoge las cifras tal como las da la fuente, explica por qué los agentes y sus archivos de configuración cambian dónde acaban los secretos y ofrece una lista de comprobación de unos 10 minutos.

¿Qué informó GitGuardian sobre secretos y agentes de código con IA?

GitGuardian vende detección de secretos, así que tiene datos y también interés en el tema. Conviene tener presentes las dos cosas. Citamos sus propias publicaciones y no añadimos nada: la página del informe State of Secrets Sprawl 2026 y el texto de GitGuardian con los resultados. Las cifras de abajo salen de esas dos páginas, tal como las leímos el 18 de octubre de 2026.

Algunas notas para leer la tabla.

El 3,2 % es una tasa por commit. El texto lo llama «secret-leak rate» y no define el término. La lectura natural es la proporción de commits que contienen un secreto escrito en el código, pero la fuente no lo dice expresamente.

La base es cualquier commit público. No es una base de commits humanos cuidadosos ni de commits de personas que usan otras herramientas de IA. Una diferencia entre el 3,2 % y el 1,5 % puede venir de la herramienta, del tipo de proyecto en el que se usa, de cuánto código se revisa o de las tres cosas. El informe no las separa.

GitGuardian no lo presenta como un fallo de la herramienta. El texto dice que la diferencia no debe leerse como un simple fallo de la herramienta: las personas siguen decidiendo qué aceptar, editar, ignorar o subir, y un usuario puede saltarse una advertencia o empujar al modelo hacia código inseguro.

Las cifras de MCP hablan de repositorios públicos. Las 24.008 son secretos únicos encontrados en archivos de configuración relacionados con MCP subidos a GitHub público. El texto añade que las guías de instalación de MCP más populares suelen indicar que se pongan las claves de API directamente en los archivos de configuración, en argumentos de línea de comandos o en cadenas de conexión. No encontramos en ninguna de las dos páginas un tamaño de muestra, un método de recogida ni un periodo para esta cifra. Tómala como un recuento de GitGuardian, no como una tasa.

Algunos datos aparecen en una sola página. La página del informe no mostraba el 3,2 % ni el 1,5 % cuando la leímos, solo el resumen «aproximadamente el doble». El texto tiene ambos y también las 2.117. Cuando una cifra aparece en una sola página, la tabla indica cuál.

Otra cifra de la misma fuente cambia lo que haces después de una fuga. GitGuardian volvió a probar credenciales válidas en 2022 y vio que más del 64 % seguían funcionando en enero de 2026. Una clave filtrada no caduca porque nadie se haya dado cuenta.

¿Por qué los agentes de código cambian dónde acaban los secretos?

Un agente es un programa que lee archivos, ejecuta comandos y envía parte de lo que ve a un proveedor de modelos. Ese es su trabajo. Para los secretos, de ahí se derivan tres cosas.

Los agentes leen los archivos donde la gente guarda secretos. Un archivo .env es el sitio habitual de las claves locales, y un agente que explora un proyecto para entenderlo abrirá ese archivo con frecuencia. Los valores viajan entonces con el resto del contexto hasta el proveedor. Una regla como .gitignore deja un archivo fuera de un commit, pero no promete nada sobre lo que un agente puede leer, y cada agente lo trata de forma distinta.

Los agentes escriben configuración. Cuando un agente añade un servidor MCP, prepara una prueba o conecta una base de datos, el cambio más rápido que funciona suele ser un valor literal en un archivo. El siguiente commit lo incluye. Una persona quizá se habría detenido ahí. Un agente al que se pide que la prueba pase puede no hacerlo, y quien revisa un diff largo puede no ver una línea más.

La configuración de MCP pone credenciales en un tipo nuevo de archivo. Un servidor MCP tiene que autenticarse en algún sitio, y su archivo de configuración es donde viven los ajustes. Las guías que muestran una clave dentro del archivo hacen de eso el camino fácil. Además, estos archivos se suben con facilidad: están en la carpeta del proyecto, a menudo como .mcp.json, junto al código.

Nada de esto significa que las herramientas sean descuidadas. Un actor nuevo toca ahora los archivos donde viven los secretos, a gran velocidad, y las defensas anteriores se pensaron para una persona que escribe un commit. Las defensas que siguen funcionando son las que no dependen de que alguien se acuerde.

¿Qué puedes hacer en 10 minutos?

Cada paso lleva su tiempo. Si haces solo los dos primeros, ya has tratado la exposición que es real.

1. Averigua a qué puede llegar un agente (2 minutos)

Desde la carpeta en la que trabajas, ejecuta:

npx -y zn-gate reach

Muestra los nombres, nunca los valores, de los secretos de tus archivos .env, los archivos de credenciales de tu carpeta personal, las variables de entorno con nombre de secreto y los hallazgos en servidores MCP y en los ajustes de los agentes. Es de solo lectura y no envía nada. Si prefieres no usar una herramienta para esto, busca en tu proyecto .env, .mcp.json, .cursor/, .codex/ y .claude/ y abre cada uno.

2. Rota todo lo que haya estado expuesto (3 minutos)

Si una clave real estuvo alguna vez en un archivo con commit, en una rama subida, en un chat o en una configuración que compartiste, considérala expuesta. Crea una clave nueva en el proveedor, actualiza los sitios que la usan y revoca la anterior. Hazlo aunque el repositorio sea privado: GitGuardian informa de que los repositorios internos tienen aproximadamente seis veces más probabilidad que los públicos de contener secretos escritos en el código, y un repositorio privado puede hacerse público o copiarse.

Rota primero y ordena después. Borrar el archivo o reescribir el historial de git no sirve si alguien ya tiene una copia de la clave.

3. Saca los secretos de los archivos de configuración de MCP (2 minutos)

Sustituye cada valor literal de una configuración de MCP por una referencia a algo que esté fuera del archivo. Qué forma funciona depende de tu cliente, así que consulta su documentación. Muchos clientes permiten pasar una variable por nombre o expandir una variable de entorno en la entrada, y una bóveda o un gestor de secretos puede aportar el valor al arrancar. El objetivo es que el archivo de tu repositorio no contenga ningún valor que funcione por sí solo.

Esta es la forma del cambio, con un nombre de ejemplo y sin ningún valor real:

{
  "mcpServers": {
    "example-service": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": { "EXAMPLE_API_KEY": "<set in your environment, not here>" }
    }
  }
}

Si una clave ya estaba en el archivo y el archivo salió de tu máquina, vuelve al paso 2.

4. Añade un escáner de secretos antes del commit (2 minutos)

Un escáner que se ejecuta en cada commit atrapa el error que se escapa de todo lo demás. Dos opciones habituales son ggshield, de GitGuardian, y gitleaks, que es de código abierto. Ambos pueden ejecutarse como hook de pre-commit. Sus comandos de instalación cambian entre versiones, así que sigue las instrucciones actuales del README de cada proyecto. Elige uno, ejecútalo una vez sobre tu historial y actívalo para los commits nuevos.

Esto no sustituye a los demás pasos. Un escáner de commits ve lo que subes. No ve lo que un agente lee de tu disco y envía a un modelo.

5. Restringe lo que el agente puede leer (1 minuto, más las preguntas)

Usa primero los ajustes del propio agente: casi todos tienen reglas de permisos y archivos ignorados, y el comportamiento exacto varía. Después, si quieres una capa que funcione con varios agentes, zn-gate es una opción. Es de código abierto (MIT), se ejecuta en tu máquina y no necesita cuenta.

npx -y zn-gate init
npx -y zn-gate env shadow .env
npx -y zn-gate check

init encuentra Claude Code, Codex CLI, Cursor y OpenCode, muestra la configuración de cada uno y pregunta antes de cada cambio. env shadow .env mueve los valores reales a una bóveda cifrada local y deja en el archivo marcadores como __ZN_STRIPE_KEY__. La primera vez, ejecuta npx -y zn-gate unlock para crear la bóveda. check prueba la configuración con un secreto falso en una carpeta temporal y te dice si algún agente no está protegido. Ejecuta init en tu propio terminal: cuando lo lanza un agente o un script, solo imprime los pasos.

Después revisa en qué confían tus agentes según la configuración de este proyecto:

npx -y zn-gate audit
npx -y zn-gate scan .

npx -y zn-gate audit revisa .claude/, .mcp.json, .codex/, .cursor/, los hooks, AGENTS.md y CLAUDE.md, los plugins y las skills. Añade --include-home para revisar también los ajustes de tu carpeta personal. zn-gate scan busca secretos filtrados en los archivos de configuración y los informa con el siguiente paso. Las mismas comprobaciones pueden ejecutarse en CI como GitHub Action.

¿Qué no cubren estos pasos?

• Claves fuera de tu máquina. Una clave guardada en la consola de un tercero, en una variable de CI o en un chat queda fuera de lo que una herramienta local puede proteger. Limita esas claves con topes de gasto y vidas cortas.
• Secretos que tus herramientas no reconocen. Los escáneres buscan formatos y nombres conocidos. Un token propio sin forma reconocible puede pasar por cualquiera de ellos, zn-gate incluido. Dar nombres claros a las variables ayuda.
• Agentes y editores que zn-gate admite solo en parte. El soporte varía según el agente. La tabla de compatibilidad indica qué permite cada uno. En algunos editores zn-gate funciona solo como servidor MCP al que el agente decide llamar, lo cual no es protección automática.
• Lo que significan las cifras para ti. Las cifras de GitGuardian describen GitHub público. Tus repositorios privados pueden ser distintos, en un sentido o en el otro.

zn-gate es una de varias formas de hacer el paso 5, y es la que construimos nosotros. Los demás pasos no dependen de él. La rotación y el escaneo son lo que cierra la exposición que ya existe.

¿Dónde puedes leer más?

Las dos páginas de GitGuardian citadas arriba son las fuentes primarias. Para los detalles de zn-gate, consulta la documentación de reach y de la bóveda de secretos y el scrubber. Para lo básico sobre cómo mantener un .env fuera del alcance de un agente, lee cómo impedir con un solo comando que Claude Code, Codex CLI, Cursor y OpenCode lean tu .env. Para ver cómo se puede eludir un hook y cómo se corrigió, lee cómo un agente de código podía leer tu fichero .env de forma indirecta. zn-gate tiene licencia MIT, se ejecuta en local y no necesita cuenta: GitHub e Install.