Un relevamiento de BlueFlag Security sobre permisos de desarrollo revela que casi ninguna organización revoca credenciales cuando termina el trabajo que las justificó.
BlueFlag Security publicó esta semana su informe «The State of Developer Risk 2026», un análisis sobre la gestión de accesos en entornos de desarrollo de software que documenta una brecha de seguridad estructural: el 99% de los tokens de acceso a repositorios de código nunca expira. Esto significa que desarrolladores, herramientas automatizadas y agentes de inteligencia artificial que alguna vez recibieron permisos para trabajar en el código de una empresa conservan esa capacidad de forma indefinida, incluso después de que el proyecto, el contrato o la necesidad operativa que justificó ese acceso ya no existe.
El hallazgo no se limita a credenciales olvidadas de empleados que cambiaron de rol. Según el informe, la persistencia de permisos afecta por igual a cuentas de servicio, bots de integración continua y agentes de IA que generan o revisan código de forma automatizada. Sin procesos de revisión de acceso, estas cuentas quedan con capacidad técnica para copiar, modificar o eliminar código corporativo mucho después de que dejaron de ser necesarias. BlueFlag identifica este patrón como un punto ciego de seguridad que atraviesa repositorios, sistemas de revisión de código, pipelines de compilación y aplicaciones conectadas al flujo de desarrollo.
Cómo la automatización amplificó un problema de gestión de identidad
El ciclo de desarrollo moderno involucra múltiples capas de acceso: repositorios Git, plataformas de CI/CD, registros de contenedores, sistemas de gestión de secretos, herramientas de análisis estático. Cada una de estas capas requiere credenciales — tokens de API, claves SSH, certificados de servicio — que se emiten con permisos específicos. El problema documentado por BlueFlag es que esos permisos rara vez se revocan de forma proactiva.
La incorporación de agentes de IA al flujo de desarrollo agrega una variable nueva: estos sistemas reciben acceso de escritura a repositorios para generar código, aplicar correcciones automáticas o refactorizar módulos completos. A diferencia de un desarrollador humano que eventualmente cambia de equipo o deja la empresa, un agente de IA puede quedar activo en segundo plano sin que nadie recuerde que tiene permisos vigentes. Si ese agente está conectado a un servicio externo o si su configuración queda expuesta, el token de acceso se convierte en un vector de ataque persistente.
El informe no especifica qué porcentaje de tokens corresponde a humanos, herramientas o IA, pero señala que las cuentas de desarrollo y herramientas crean puntos ciegos de seguridad en las organizaciones. Esto implica que el problema no es solo de volumen — es de visibilidad: muchas empresas no tienen un inventario actualizado de qué cuentas tienen acceso a qué repositorios, ni cuándo fue la última vez que ese acceso se utilizó.
El riesgo en América Latina: dependencia de plataformas globales sin auditoría local
Aunque el informe de BlueFlag no desglosa datos por región, el patrón de riesgo es especialmente relevante en América Latina por dos factores estructurales. Primero, la mayoría de las empresas de tecnología en la región — desde fintechs en Brasil y México hasta plataformas de e-commerce en Argentina y Colombia — dependen de servicios de repositorio en la nube (GitHub, GitLab, Bitbucket) sin equipos de seguridad dedicados a auditar permisos de forma continua. Segundo, el uso de contratistas externos y equipos distribuidos es proporcionalmente más alto que en mercados con mayor concentración de talento técnico local, lo que multiplica la cantidad de cuentas temporales que deberían revisarse y no se revisan.
Un caso hipotético pero plausible: una fintech mexicana contrata un equipo de desarrollo en Argentina para construir un módulo de pagos. El equipo recibe tokens de acceso al repositorio principal. Tres meses después, el proyecto termina, pero nadie revoca los tokens. Seis meses más tarde, uno de esos desarrolladores cambia de empleador — a una empresa que compite en el mismo sector. El token sigue activo. No hace falta un ataque sofisticado: basta con que alguien revise su historial de credenciales guardadas en su máquina local para tener acceso de lectura (y posiblemente escritura) al código de la fintech original.
Por qué las revisiones de acceso no se hacen aunque todos saben que deberían hacerse
La falta de revisiones de acceso no es un problema técnico — es un problema de proceso. Las herramientas para listar tokens activos, auditar permisos y revocar credenciales existen en todas las plataformas de repositorio principales. El obstáculo es operativo: nadie tiene asignada la responsabilidad de ejecutar esas revisiones de forma periódica, y cuando alguien lo intenta, descubre que no hay un registro claro de por qué se emitió cada token ni quién lo solicitó.
En organizaciones que crecieron rápido — un patrón común en startups de tecnología en LATAM durante los últimos cinco años — el problema se agrava porque los procesos de onboarding y offboarding de desarrolladores nunca se formalizaron. Un desarrollador que deja la empresa puede perder acceso a su cuenta de correo corporativo y a Slack, pero conservar tokens de API que emitió él mismo y que están guardados en variables de entorno de su máquina personal o en secretos de un pipeline de CI/CD que nadie más sabe que existe.
BlueFlag señala que sin revisiones de acceso, las organizaciones pueden dejar cuentas con capacidad de copiar o cambiar código de la empresa después de que el trabajo termina. Esto no es solo un riesgo de fuga de propiedad intelectual — es un riesgo de integridad del código: un token con permisos de escritura puede usarse para inyectar backdoors, modificar dependencias o alterar configuraciones de seguridad sin que quede registro de quién lo hizo, porque la cuenta que ejecuta el cambio es técnicamente legítima.
Nuestro análisis
El dato del 99% de tokens sin vencimiento no es una anomalía — es el estado por defecto de la industria. La mayoría de las plataformas de repositorio emiten tokens de acceso personal (PAT) y tokens de OAuth sin fecha de expiración configurada, porque eso simplifica la experiencia del desarrollador: no hay que renovar credenciales cada cierto tiempo. El problema es que esa conveniencia operativa se convirtió en una deuda de seguridad acumulada que nadie está pagando.
Lo que hace relevante este informe no es que revele un riesgo nuevo — el problema de credenciales persistentes se conoce desde hace años — sino que cuantifica su prevalencia de forma tan contundente que ya no puede tratarse como un caso marginal. Si el 99% de los tokens nunca expira, significa que prácticamente ninguna organización está gestionando el ciclo de vida de accesos de desarrollo como un proceso continuo. Y con la incorporación de agentes de IA que generan código de forma autónoma, el inventario de cuentas con permisos activos va a seguir creciendo más rápido de lo que cualquier equipo de seguridad puede auditar manualmente.
El informe no ofrece datos sobre cuántos de esos tokens están efectivamente en uso versus cuántos quedaron abandonados, ni cuántos corresponden a cuentas humanas versus automatizadas. Esa falta de granularidad es, en sí misma, parte del problema: si las organizaciones no tienen visibilidad sobre qué tokens existen, mucho menos van a tener visibilidad sobre cuáles representan un riesgo activo. ¿Cuántas brechas de los próximos doce meses van a rastrearse hasta un token de acceso que debió revocarse hace dos años y nadie recordaba que existía?