Todo programa, toda integración y todo agente de IA que opera dentro de una empresa carga consigo al menos una credencial: una llave que abre la puerta de algún sistema. Según el informe State of Secrets Sprawl 2026, de la empresa de seguridad GitGuardian, publicado en marzo de 2026, se encontraron 28,65 millones de credenciales nuevas expuestas en código público a lo largo de 2025 — un alza del 34% respecto al año anterior y el mayor salto anual que la empresa ha registrado.
Una parte importante de ese crecimiento está ligada directamente a la IA: las credenciales asociadas a servicios de inteligencia artificial sumaron 1.275.105 en el mismo estudio, un aumento del 81% en un año. Cada agente nuevo puesto en funcionamiento es, en general, una credencial más circulando por la empresa — y pocas de ellas tienen dueño definido, fecha de vencimiento o un acceso limitado a la tarea que deberían cumplir.
La OWASP, fundación internacional de referencia en seguridad de software, formalizó este escenario en 2025 con una lista de los diez riesgos más comunes en identidades usadas por programas y agentes, no por personas. Entre ellos están el exceso de privilegio, la credencial sin fecha para expirar y la desactivación incompleta cuando termina un proyecto. Para quien decide poner agentes en producción, queda una pregunta simple y poco formulada: ¿qué abre exactamente la llave que carga este agente, y por cuánto tiempo?
Más llaves de las que cualquier equipo puede contar
Ninguna empresa decide, de una sola vez, tener miles de credenciales de sistemas circulando. Se acumulan poco a poco: una integración aquí, un agente allá, cada uno con acceso a un sistema para resolver una tarea puntual. El problema es que esa credencial rara vez se revisa después — simplemente sigue activa, mucho después de que la tarea original haya cambiado o terminado.
El mismo informe de GitGuardian midió ese hábito de forma directa: el 64% de las credenciales confirmadas como válidas en 2022 seguían activas y explotables en enero de 2026. Cuatro años después, la mayoría nunca había sido rotada ni revocada — solo quedó olvidada en algún lugar del sistema.
La lista de la OWASP nombra exactamente ese patrón. Uno de los diez riesgos, identidad no humana con exceso de privilegio, describe credenciales de programas y agentes con un acceso muy superior al que exige su función. Otro, credencial de larga duración, describe llaves y certificados sin fecha para expirar. Un tercero, desactivación incompleta, describe lo que ocurre cuando nadie revoca el acceso de un proyecto ya cerrado.
El Informe de Investigaciones de Brechas de Datos 2026, de Verizon, muestra por qué esto importa en la práctica. El abuso de credenciales cayó al 13% como puerta de entrada inicial en los ataques — era 22% el año anterior —, pero, al contarlo en cualquier etapa del ataque y no solo en el primer paso, sigue en la cima, presente en el 39% de las brechas analizadas. El propio informe cita la rotación inadecuada de credenciales y la ausencia de acceso mínimo en cuentas de sistemas y servicios entre las causas de fondo más comunes en brechas que involucraron a terceros.
En las empresas brasileñas y latinoamericanas que empiezan a poner agentes de IA a atender clientes, actualizar registros o consultar sistemas financieros, el patrón se repite: la integración nace rápido, alguien reutiliza una credencial ya existente o crea una con acceso amplio "para que no se trabe después", y nadie vuelve a estrechar ese acceso cuando la rutina se estabiliza.
Por qué la llave maestra parece el camino más rápido
Cuando un agente necesita conectarse a un sistema de pagos, a una hoja de cálculo o a un sistema de atención, el camino más rápido es entregarle una credencial de acceso amplio — la misma que usaría una persona para hacer cualquier cosa en ese sistema. Configurar un acceso restringido a solo dos o tres funciones, dentro de una herramienta que tiene decenas, parece demasiado trabajo para una automatización que "solo va a hacer una cosa".
El problema aparece cuando ese agente se equivoca, es manipulado o simplemente se usa más allá de lo previsto. Como heredó el mismo alcance de una credencial de uso general, la acción ejecutada carga con todo ese poder — aunque la tarea original exigiera mucho menos. Y en el registro del sistema, lo que queda grabado es el nombre genérico de la cuenta o del agente, no la persona o el proceso que debería responder por eso.
Esa es exactamente la combinación que la OWASP cataloga como uso indebido de identidad no humana: alguien reutiliza una credencial amplia porque configurar una estrecha parece burocracia, y el riesgo solo aparece meses después, en una investigación donde nadie puede decir con certeza quién autorizó qué.
Lo que tiene que existir en la práctica
Resolver esto no es cuestión de confiar más o menos en el agente. Es cuestión de arquitectura: cada credencial tiene que nacer estrecha, tener dueño y tener plazo.
Credencial personal por herramienta conectada. Cada integración usada por un agente o por una persona tiene su propia llave de acceso — nunca una credencial genérica que se comparte entre varias automatizaciones o personas distintas.
Acceso liberado función por función, incluso dentro de la misma herramienta. Si un sistema conectado tiene treinta funciones y el agente solo necesita dos para cumplir su tarea, son esas dos las que quedan liberadas — no la herramienta entera.
Plazo de revisión para cada credencial, sin excepción. Ninguna llave queda activa indefinidamente solo porque nadie recordó reevaluarla; la revisión periódica es parte del funcionamiento, no una tarea extra de alguien.
Aprobación humana antes de cualquier acción sensible. Antes de que el agente ejecute algo con impacto real — mover dinero, alterar un registro crítico, publicar un documento —, la acción se detiene y pide confirmación de una persona, dentro de la propia conversación.
Trazabilidad que conecta la acción con quien la originó. Cada uso de una credencial queda registrado de forma que apunta a la persona o al proceso responsable, no solo al nombre genérico del agente.
Así fue diseñada la plataforma Skyller: cada herramienta conectada recibe su propia credencial, el acceso se libera función por función, y las acciones sensibles pasan por confirmación humana antes de ocurrir.
Lo que cambia cuando cada llave tiene dueño
La primera ganancia aparece al investigar algo fuera de lo común. Con una credencial estrecha y personal por herramienta, saber qué pudo haber hecho un agente específico deja de ser una suposición y se convierte en una consulta directa — porque el alcance de esa llave ya estaba limitado desde el inicio.
La segunda ganancia aparece cuando un proyecto termina o se reemplaza una herramienta. Desactivar esa credencial específica no exige rastrear a quién más dependía de ella, porque nunca se compartió con nada más allá de la tarea para la que nació.
La tercera es la que más pesa a medida que la empresa crece: agregar el agente número cincuenta deja de ser más riesgoso que agregar el número cinco, porque cada uno carga solo el acceso que su propia función exige — no lo que sobró de una credencial prestada. En Skyller, revisar lo que autoriza una herramienta específica, y revocarlo sin afectar nada más, es una pantalla de configuración, no una investigación.
Una guía para revisar las llaves en uso
Antes de conectar el próximo agente a un sistema nuevo, vale la pena reunir al equipo de TI y responder estas preguntas sobre lo que ya está en funcionamiento:
- Lista las credenciales que ya usan los agentes de IA hoy. Incluyendo las creadas de forma informal, por alguien que resolvió una tarea puntual que sigue corriendo meses después.
- Para cada una, pregunta qué abre — no solo en qué sistema. Los sistemas suelen tener decenas de funciones; pocas credenciales realmente necesitan todas.
- Descubre hace cuánto tiempo no se rota cada credencial. Una llave sin fecha de revisión es, en la práctica, una llave sin dueño.
- Define quién aprueba qué antes de que el agente actúe. No toda acción exige confirmación manual, pero la que involucra dinero, datos críticos o comunicación externa, sí.
- Confirma que el registro apunte a una persona, y no solo al nombre del agente. Sin eso, la próxima investigación va a chocar con la misma respuesta vaga: "alguien del equipo, no sé quién".
