GitGuardian: los commits con asistencia de IA filtran el doble de credenciales
El informe State of Secrets Sprawl 2026 apunta a los agentes de código como acelerador de las fugas de claves, y pide tratar el problema como una cuestión de identidad no humana.
Los commits que llevan asistencia de IA filtran credenciales a un ritmo que duplica al de los escritos por una persona. Lo recoge el informe State of Secrets Sprawl 2026 de GitGuardian, y el dato es tan incómodo como suena: las categorías de credenciales filtradas que más crecen son precisamente las ligadas a servicios de IA. La herramienta que acelera el desarrollo acelera también la exposición de las claves que ese mismo desarrollo necesita.
La vulnerabilidad no es nueva. Lo que cambia es la escala y el ritmo. Un agente de código puede leer un proyecto entero, tocar ficheros, generar configuraciones y hablar con servicios externos en el tiempo que a un desarrollador le lleva revisar un único pull request. El problema de fondo no es que el agente se cruce a veces con un secreto: es que buena parte de esos secretos no se diseñaron para un entorno donde el software actúa por su cuenta.
De la detección a la identidad
Hasta ahora el control de la dispersión de secretos se apoyaba en detectar después: escáneres sobre repositorios, hooks de pre-commit y rotación de credenciales una vez vista la fuga. Esos controles siguen haciendo falta, pero el informe señala su límite. Un agente lee ficheros locales, ejecuta comandos, llama a APIs, habla con servidores MCP y reescribe configuración. Cada capacidad añade un sitio donde hace falta una credencial y un camino más por el que esa credencial se propaga.
La propuesta es tratar el asunto como un problema de identidad no humana, no de comportamiento del modelo. Cada acción útil de un agente sobre otro sistema lleva una identidad detrás: cuando consulta una base de datos, cuando llama a una API, cuando despliega en staging, hay una credencial autorizando. No se puede predecir qué hará un sistema autónomo, pero sí se puede acotar a qué tiene acceso la identidad que lo representa.
En la práctica se ve en cuatro sitios. Los ficheros .env y las configuraciones locales que quedaron de una sesión de depuración y que el agente puede leer aunque no tengan nada que ver con la tarea encomendada. Las configuraciones de agentes y de servidores MCP, donde la vía rápida para conectar una aplicación con una base de datos es pegar la credencial en el fichero, y como ese fichero no entra en control de versiones se asume que está a salvo. Las copias duplicadas en variables de CI/CD o en tickets de Jira: cada copia autentica igual, así que rotar la del repositorio no sirve de nada si la otra sigue viva. Y los permisos excesivos que se conceden durante el prototipado y que nadie revisa cuando el flujo ya está en producción. En sistemas multiagente, un orquestador que guarda las claves de varios agentes amplía el efecto dominó: quien comprometa esa capa hereda todo lo que el orquestador podía alcanzar.
Keeper Security presentó en el RSAC 2026 una encuesta sobre los huecos en la protección de agentes de IA, máquinas e identidades no humanas, que apunta en la misma dirección.
Para quien administra sistemas, la consecuencia práctica es que escanear repositorios ya no basta. Los secretos viven en portátiles de desarrollo, en ficheros de configuración de agentes y en herramientas de colaboración que muchos equipos no auditan. Y la rotación, que era la red de seguridad, pierde eficacia cuando la misma credencial está replicada en sitios que nadie inventaría. Queda por ver si los proveedores de agentes asumen el reparto de permisos por defecto o si cada organización sigue improvisándolo.
