Los agentes de IA filtran credenciales al doble de velocidad: lo que el último informe de GitGuardian cambia sobre secrets en desarrollo

El informe 2026 State of Secrets Sprawl de GitGuardian aporta una cifra difícil de ignorar: los commits identificados como asistidos por IA filtran secretos aproximadamente al doble de ritmo que los escritos a mano. La mayoría de las categorías de credenciales expuestas que más rápido crecen ya están conectadas a servicios de IA. Es decir, las herramientas que prometen acelerar el desarrollo están acelerando, en paralelo, la exposición de las claves sobre las que ese mismo desarrollo se sostiene.

No estamos ante una vulnerabilidad nueva. Lo nuevo es la escala y la cadencia. Un agente de código puede leer un proyecto entero, modificar archivos, generar configuraciones e interactuar con servicios externos en el tiempo que un humano tarda en revisar un único pull request. El problema no es que el modelo «vea» un secreto de vez en cuando; es que la mayoría de esos secretos nunca fueron pensados para un entorno donde el software actúa de forma autónoma.

Secrets sprawl ya no es un problema de comportamiento, es de identidad

El sprawl de credenciales lleva años describiéndose con la misma imagen: claves API, tokens y cuentas de servicio diseminadas entre sistemas que ninguna organización llega a inventariar. El equipo de seguridad ha respondido con un arsenal ya clásico: escáneros sobre los repositorios, hooks de pre-commit, rotación reactiva cuando se descubre una exposición. Todo eso sigue siendo útil, pero los agentes de IA exponen los límites de depender solo de detección.

Un agente puede leer ficheros locales, ejecutar comandos, llamar a APIs, conectarse a servidores MCP y modificar configuración. Cada capacidad adicional es un sitio más donde puede requerirse una credencial y un camino más por el que esa credencial puede propagarse. La conclusión de GitGuardian es directa: conviene tratar el sprawl de secretos en la era de los agentes como un problema de identidades no humanas (NHI), no como un problema del modelo.

Cada acción útil que un agente realiza sobre otro sistema tiene una identidad detrás. Cuando consulta una base de datos, llama a una API o despliega en staging, alguna credencial autoriza esa acción. No podemos predecir de forma fiable cada movimiento de un sistema autónomo, pero sí podemos controlar a qué puede acceder la identidad bajo la que se mueve.

Cómo filtran credenciales los agentes de código en la práctica

Lo que hace útiles a los agentes de codificación es exactamente lo que crea nuevos riesgos de credenciales: necesitan contexto. Un agente que no puede leer un proyecto entero aporta poco, sobre todo si hay que reautorizarlo para cada operación. Hay cuatro patrones que se repiten en producción.

1. Los agentes leen ficheros sensibles del proyecto

Es habitual que los desarrolladores dejen credenciales en archivos .env y configuraciones locales tras una sesión de depuración, sin intención de llevarlas al control de versiones. Un agente de código con acceso amplio al proyecto puede leer esos archivos junto con el código que se le ha pedido revisar. Para el agente, un .env con una clave de producción sigue siendo parte del entorno de trabajo; si nada limita explícitamente su acceso, la credencial queda disponible aunque sea irrelevante para la tarea. Esto rompe una asunción clásica: las credenciales locales en texto plano ya no son accesibles solo para el desarrollador y las aplicaciones que las referencian, sino también para cualquier agente que opere sobre el mismo entorno.

2. Configuraciones del agente y de servidores MCP con credenciales hardcodeadas

Las instrucciones de instalación de agentes y servidores MCP suelen simplificar al máximo cómo conectarlos con bases de datos, APIs y otros servicios externos. Como muchas integraciones requieren autenticación, esa simplificación se traduce con frecuencia en pegar la credencial directamente en un fichero de configuración. Ese archivo nunca llega al repositorio, lo que invita a asumir que la clave está a salvo. Pero sigue existiendo en texto plano en el equipo del desarrollador, en una ruta que el propio agente tiene permisos para leer.

3. Secretos duplicados en superficies que los equipos no escanean

Un secreto rara vez vive en un único lugar. La misma clave termina en un .env, en una variable de CI/CD e incluso en un ticket de Jira mientras se depura un despliegue roto. Un agente conectado a esos sistemas introduce una vulnerabilidad añadida: como cada copia autentica, rotar la que está en el repositorio deja a las demás funcionando. Por eso escanear solo el repositorio no resuelve el sprawl. Una proporción creciente de incidentes con secretos se origina fuera del código, en herramientas de colaboración y ticketing. Rotar la copia hallada en el repo tiene un beneficio mínimo si la misma credencial sigue válida en otro sitio.

4. Credenciales de agente con permisos excesivos

Un agente necesita acceso suficiente para completar su trabajo, lo que crea presión para concederle permisos amplios y garantizar que su tarea sea útil. Los permisos que se otorgan durante la fase de prototipado, para evitar errores, pueden acabar integrados en producción; las intenciones temporales se quedan en piedra. El riesgo se multiplica en sistemas multi-agente. Una capa de orquestación que custodia claves de varios agentes puede provocar un efecto dominó: cualquier atacante que la comprometa hereda el acceso a todo lo que el orquestador podía alcanzar.

La brecha de gobernanza ya es medible

La encuesta de Keeper Security en RSAC 2026 lo deja en cifras: el 46 % de los encuestados dice que herramientas con IA ya tienen acceso a sistemas críticos y datos sensibles, pero el 76 % reconoce que esas identidades no se gobiernan de forma consistente bajo políticas de acceso privilegiado. Incluso cuando se concede el acceso, los controles que normalmente acompañan a ese nivel de privilegio muchas veces no existen.

Este es el verdadero punto de inflexión. No hablamos de un fallo teórico del modelo, sino de un problema de identidad y gobierno que el modelo pone en primer plano.

Cómo asegurar los secretos en desarrollo asistido por IA

Prohibir las herramientas de codificación con IA no es realista para la mayoría de organizaciones y, sinceramente, tampoco es necesario. El enfoque correcto pasa por tratar a los agentes como una identidad más dentro del entorno de desarrollo y concederles acceso en consecuencia. Las palancas concretas que propone el informe son siete.

Eliminar credenciales estáticas del entorno del desarrollador. En lugar de guardar secretos en archivos .env, configuraciones MCP o ajustes del IDE, hay que recuperarlos desde una plataforma centralizada de gestión de secretos cuando se necesiten. Si la credencial en texto plano no está en la máquina, un agente no puede leerla accidentalmente.

Sustituir claves de larga duración por credenciales de vida corta y rotación automática. Una clave estática que se filtra sigue siendo una amenaza mientras siga siendo válida, lo que puede equivaler a meses o años. Una credencial de vida corta que caduca en minutos y rota con una cadencia definida reduce esa ventana y elimina la urgencia de encontrar cada copia antes que un atacante.

Asignar a cada agente una identidad con alcance propio. Las cuentas de servicio compartidas hacen casi imposible identificar qué agente hizo qué y garantizan que cada agente hereda el permiso más amplio que cualquiera de ellos necesite. Lo correcto es dar a cada agente únicamente los permisos necesarios para su tarea y hacerlos temporales siempre que sea posible. Tratar al agente como un contratista: maneja recursos concretos y ejecuta acciones concretas dentro de un plazo definido.

Extender la gestión de secretos más allá del código. La infraestructura de CI/CD, las máquinas de los desarrolladores, las configuraciones MCP, los sistemas de tickets y las herramientas de colaboración contienen credenciales que el escaneo del repositorio nunca ve. Buena parte de los incidentes con secretos nacen en esas superficies. El equipo de seguridad necesita visibilidad fuera del control de código fuente.

Exigir humanos en el bucle para operaciones sensibles. El acceso a credenciales, los despliegues a producción y los cambios de privilegios no deben volverse autónomos; tienen que pasar por aprobación explícita. Los modos de auto-aprobación deben ser una decisión de política intencionada con un alcance definido, no un valor por defecto que un desarrollador activa una vez y nunca revisa.

Inventariar agentes y servidores MCP ya en ejecución. La mayoría de organizaciones tienen más agentes funcionando de los que creen, instalados por desarrolladores individuales sin revisión. Hay que saber qué agentes y servidores MCP están operativos, quién es su dueño, qué identidades usan y a qué pueden acceder.

Registrar y auditar toda la actividad del agente. Las identidades no humanas necesitan el mismo rastro de acceso que las humanas. Sin un registro de qué credencial usó un agente y a qué llegó, la respuesta a incidentes no puede reconstruir una brecha ni aportar pruebas en auditorías de cumplimiento.

Sprawl de secretos es un problema de identidad, no de IA

El desarrollo de software es uno de los principales casos de uso empresariales de la IA, y ningún equipo de seguridad va a cambiarlo solo con políticas. Los agentes de IA no han creado el sprawl de secretos: han dejado al descubierto lo mal que muchas organizaciones gestionan las credenciales de las máquinas. El objetivo realista es conseguir que los secretos que un agente pueda encontrar no merezcan la pena robar. Eso pasa por eliminar credenciales estáticas innecesarias, retirar privilegios permanentes, acortar la vida útil de las claves, separar identidades y mantener visibilidad sobre cómo se usan las identidades de máquina.

Más escaneo no resuelve el problema, porque sigue encontrando credenciales después de que se hayan propagado. Lo que ayuda es el control centralizado, con arquitectura zero-knowledge, sobre cómo se almacenan, acotan y caducan los secretos. Los agentes de IA van a seguir trabajando más rápido y con más eficiencia; las credenciales, simplemente, tendrán que dejar de ser el eslabón más débil.