Entre 2024 y 2025, los commits generados con ayuda de IA se dispararon en las principales plataformas de desarrollo. Los equipos de marketing empezaron a montar automatizaciones que conectaban sus CRM con herramientas de comunicación.
Los departamentos de atención al cliente desplegaron chatbots con acceso a sus bases de datos de soporte y los equipos de operaciones comenzaron a crear scripts para coordinar infraestructuras en la nube.
Todo esto ocurrió tan rápido que los equipos de seguridad apenas pudieron anticipar sus consecuencias. Cada flujo automatizado, cada integración y cada agente necesita credenciales para autenticarse. Un asistente de IA que responde a clientes requiere acceso al CRM, a la plataforma de soporte, al sistema de facturación y a la base de conocimiento. Un asistente de programación necesita entrar en repositorios, usar claves de API, acceder a la nube y tener permisos de despliegue.
Muchos equipos de seguridad no saben cuántas existen y mucho menos pueden gestionarlas adecuadamente
Las cifras son difíciles de ignorar. Si durante la era cloud una organización podía manejar unas diez identidades no humanas por empleado, ahora, a medida que proliferan los agentes de IA, esa cifra puede acercarse a cien. Muchos equipos de seguridad ni siquiera saben cuántas existen y mucho menos pueden gestionarlas adecuadamente.
Lo más preocupante es que todo esto sucede sin que apenas se note: se crean instancias en la nube con permisos demasiado amplios; las cuentas de servicio van acumulando accesos porque nadie las revisa; o las claves de API generadas para pruebas se quedan activas para siempre… Cada credencial olvidada es una posible puerta de entrada que los equipos de seguridad ni siquiera saben que está ahí.
Dónde se esconden las credenciales
Los controles de seguridad tradicionales parten de la premisa de que las credenciales residen en ubicaciones conocidas: repositorios de código fuente, bases de datos de configuración o bóvedas de secretos (secret vaults).
El desarrollo impulsado por IA ha desmoronado estos supuestos: los asistentes de IA generan credenciales en los registros de conversación (logs); las plataformas no-code las almacenan en extensiones de navegador; la sincronización de los espacios de trabajo crea copias en diversas ubicaciones de almacenamiento; la documentación las captura y las transcripciones de sesión las registran en las respuestas de las API.
De hecho, cuando un desarrollador consulta a un asistente de código sobre conexiones a bases de datos, la respuesta puede incluir credenciales. Esa conversación se registra, es indexada por el buscador empresarial y queda accesible para los sistemas de recuperación de información. Meses después, alguien que realiza una pregunta no relacionada recibe una respuesta generada por IA que, inadvertidamente, saca a la luz dichas credenciales.
El reto de la proliferación de credenciales, que ya era difícil en la era cloud, se
ha vuelto inmanejable en la era de la IA
El incidente de Openclaw (Moltbot) en enero de 2026 ilustró esto a gran escala. A los pocos días de que el asistente de IA ganara adopción masiva, varios investigadores documentaron 181 credenciales únicas expuestas en repositorios públicos donde los usuarios habían respaldado sus configuraciones, incluyendo certificados de producción de Kubernetes y claves administrativas de la nube. Además, realizar una copia de seguridad del espacio de trabajo de un agente de IA implica, intrínsecamente, respaldar las credenciales que habilitan su funcionalidad.
Los riesgos en la cadena de suministro multiplican este impacto. Una vulnerabilidad en una plataforma popular de alojamiento de IA podría haber expuesto credenciales de acceso a miles de instancias alojadas, cada una de las cuales contenía, a su vez, credenciales de clientes para docenas de servicios.
Esto empeorará antes de mejorar
Los agentes de IA funcionan con razonamiento probabilístico, lo que introduce retos de seguridad que los controles de acceso tradicionales no están preparados para gestionar. Los sistemas clásicos toman decisiones binarias: permiso concedido o denegado. Los agentes de IA, en cambio, interpretan la intención y actúan según niveles de confianza.
Un agente que tiene un 95% de certeza de que una solicitud de acceso a datos es legítima puede actuar pese a ese 5% de incertidumbre. Desde el punto de vista de la seguridad, ese margen abre brechas que pueden explotarse mediante la manipulación de instrucciones o prompts.
Cuando los agentes encadenan acciones de forma autónoma, los riesgos se multiplican. Un agente puede recuperar documentación, incorporarla a sus respuestas y ejecutar acciones: cada paso por separado parece razonable, pero en conjunto puede provocar exposiciones de credenciales que ningún control aislado detectaría.
Las organizaciones que despliegan agentes autónomos se enfrentan además a otro problema: estos sistemas van acumulando permisos con el tiempo. Un chatbot de atención al cliente puede acabar accediendo al CRM, a sistemas de facturación, a los tickets de soporte, a wikis internas y a directorios de empleados, muy por encima de su propósito inicial. Nadie documenta esos permisos ni revisa si siguen siendo adecuados.
La naturaleza efímera de la infraestructura en la nube complica aún más el control. Las credenciales se crean y se eliminan dinámicamente a medida que se lanzan contenedores o el autoescalado ajusta la capacidad. Las auditorías periódicas tradicionales no pueden seguir el ritmo de una infraestructura que se recrea continuamente.
Solucionarlo a gran escala
Incluso cuando las organizaciones detectan credenciales expuestas, solucionarlo resulta mucho más complejo que corregir vulnerabilidades en el código.
Descubrir un fallo de seguridad en el código implica arreglar la función, probarla y desplegar la actualización. Descubrir una credencial de producción expuesta, en cambio, desencadena una respuesta mucho más complicada. Los equipos de seguridad tienen que identificar en qué sistemas distribuidos se está usando esa credencial, evaluar qué servicios podrían fallar al rotarla, actualizar todas las referencias de forma sincronizada y vigilar que no queden servicios funcionando con la credencial antigua.
Esta complejidad operativa explica por qué muchas organizaciones fracasan al intentar remediar este tipo de incidentes. Y los atacantes conocen bien esta realidad, por lo que suelen centrarse en empresas donde la proliferación de credenciales ya se ha vuelto inmanejable.
Los equipos de desarrollo se convierten en objetivos especialmente valiosos, ya que los entornos locales acumulan credenciales de múltiples sistemas durante meses o incluso años. Un solo portátil comprometido puede dar acceso a decenas de credenciales críticas.
Qué deben hacer las organizaciones
Abordar la seguridad de las credenciales en la era de la IA implica actuar tanto sobre las herramientas como sobre la gobernanza, y exige cambios operativos de fondo.
Las organizaciones necesitan visibilidad completa sobre todos los entornos donde existan credenciales, no solo sobre los sistemas oficialmente controlados. Además, ese inventario debe actualizarse de forma continua, ya que las nuevas arquitecturas crean y eliminan credenciales de manera dinámica.
La evaluación del riesgo debe tener en cuenta el nivel de privilegios, el posible impacto de un compromiso y la criticidad operativa. Un token de un entorno de pruebas y una credencial de base de datos en producción representan amenazas muy distintas y requieren respuestas diferentes.
Para poder solucionarlo, hacen falta capacidades de orquestación que permitan rotar credenciales en sistemas distribuidos sin interrumpir el servicio. Los procesos manuales no pueden escalar cuando se crean, modifican y eliminan cientos de miles de identidades técnicas cada día.
Las organizaciones deben extender la gestión del ciclo de vida de identidades a las entidades no humanas con el mismo rigor que aplican a las cuentas de personas: control del aprovisionamiento, revisiones periódicas de acceso, reducción de privilegios y retirada sistemática cuando dejan de ser necesarias.
Por último, los equipos de seguridad deben asumir que los agentes de IA son distintos de las cuentas de servicio tradicionales. Su razonamiento probabilístico, su capacidad para encadenar acciones de forma autónoma y su tendencia a acumular permisos exigen nuevos marcos de gobernanza que aún no forman parte de los programas de seguridad empresariales estándar.
La aceleración continúa
La adopción de la IA no muestra señales de desaceleración. Las organizaciones afrontan una fuerte presión competitiva para desplegar agentes en atención al cliente, automatización y generación de código. Esta aceleración es inevitable y, en muchos casos, positiva: los agentes de IA aportan un valor real cuando se implantan con criterio.
Pero el sector de la seguridad debe ser honesto respecto a la brecha entre la velocidad de despliegue y la capacidad de gobernanza. Las organizaciones están creando identidades técnicas mucho más rápido de lo que están desarrollando sistemas para gestionarlas. El problema de proliferación de credenciales, que ya era difícil en la era cloud, se ha vuelto inmanejable en la era de la IA.
La elección no está entre adoptar IA o mantener la seguridad. La verdadera decisión es si construir ahora una infraestructura sólida de gobernanza de identidades o enfrentarse más adelante a las consecuencias de brechas masivas basadas en credenciales.
Los atacantes cuentan con que las organizaciones opten por el optimismo en lugar de la preparación, confiando en que la proliferación de credenciales superará la capacidad de control. Y, si se observan las tendencias actuales, parece que su apuesta no va desencaminada.
