Cuando una persona cambia de función dentro de la misma empresa, lo habitual es que salga de ahí con dos paquetes de acceso sumados, no con uno cambiado por otro: el anterior sigue vigente y el nuevo se suma encima. El cambio de puesto tiene proceso, aprobación y fecha. La pérdida del acceso anterior, en la mayoría de las empresas, no tiene ninguna de las tres cosas.
El informe de Panorama de Seguridad de Identidad 2025, de CyberArk, con la participación de 2.600 responsables de seguridad en organizaciones medianas y grandes, midió ese desequilibrio en otra escala: las identidades de máquina ya superan a las humanas por más de 80 a 1 dentro de las organizaciones, y se espera que la inteligencia artificial sea, en 2025, la mayor fuente de nuevas identidades con acceso privilegiado. Aun así, el 68% de los participantes admitió que su organización no cuenta con controles de identidad adecuados para estas tecnologías.
La relación entre ambos datos es directa: un agente de IA nace heredando buena parte del acceso de quien lo configuró. Si esa persona ya carga el exceso habitual de quien cambió de área varias veces, el agente hereda el mismo exceso, pero opera con él todo el tiempo, sin que nadie lo revise después. Para quien decide sobre seguridad y adopción de IA, ese es el detalle que suele pasar desapercibido: el acceso acumulado no es un problema nuevo, pero la IA lo reproduce a mayor escala.
El acceso que crece como una bola de nieve
La práctica tiene nombre en el mercado de identidad: acumulación de privilegio. Ocurre porque conceder acceso resuelve un problema con fecha y responsable — alguien necesita entrar a un sistema hoy —, mientras que retirarlo no resuelve ningún problema en el momento; solo reduce un riesgo que tal vez nunca se convierta en incidente. El resultado, en cualquier empresa que crece, es la misma asimetría: se vuelve buena para conceder y mala para revocar.
Una encuesta de Beyond Identity con 1.121 personas en Estados Unidos, Reino Unido e Irlanda, publicada en 2022, encontró que el 83% de los ex empleados seguía pudiendo entrar a cuentas de su empleador anterior después de irse — no porque alguien hubiera decidido mantener el acceso, sino porque nadie tuvo la tarea explícita de cerrarlo. Si esto ocurre cuando la persona se va definitivamente, es razonable esperar que ocurra con más frecuencia todavía cuando solo cambia de equipo, una situación en la que, a ojos de quien administra el acceso, nada parece haber cambiado.
El informe de Seguridad de Datos 2025, de Varonis, midió el mismo residuo desde otro ángulo: el 88% de las organizaciones tiene cuentas activas pero detenidas — perfiles que conservan el acceso habilitado mucho después de dejar de usarse en el día a día. Cada una de esas cuentas corresponde a un permiso que alguien concedió por un motivo específico, en un momento específico, y que sigue vigente incluso después de que ese motivo desapareciera.
Con los agentes de IA, el mismo patrón se repite a mayor velocidad. Un agente creado para apoyar al área financiera, por ejemplo, suele heredar el perfil de quien lo configuró — incluido lo que esa persona acumuló de funciones anteriores. Cuando otras personas del equipo empiezan a usar ese mismo agente, o cuando quien lo creó cambia de función, casi nadie vuelve a revisar qué puede ver y hacer ese agente.
El resultado es un exceso de privilegio que nadie concedió a propósito: simplemente nunca se retiró. Y cuanto más tiempo permanece activo un permiso innecesario, mayor es la ventana para que alguien lo use de un modo indebido — una credencial filtrada, un agente mal configurado o una persona malintencionada aprovechan exactamente el acceso que ya estaba ahí, acumulado, esperando.
Las identidades de máquina ya superan a las identidades humanas por más de 80 a 1 dentro de las organizaciones.
Revisiones que terminan en sello automático
La respuesta más común es la revisión periódica de acceso: una vez al año, el equipo de seguridad envía una planilla para que los gerentes confirmen si cada persona todavía necesita lo que tiene. En la práctica, la mayoría confirma todo sin revisar línea por línea — la lista es larga, el plazo es corto, y nadie quiere ser el gerente que trabó por error el trabajo de un colega.
Otra salida habitual es el acceso por grupo: en vez de configurar el permiso persona por persona, se crea un grupo — "finanzas", "ventas" — y todos los de esa área heredan el mismo paquete. Eso resuelve la velocidad de incorporación de gente nueva, pero convierte al grupo en un archivo de todo lo que alguna vez se le otorgó a alguien de ahí, por algún motivo. Salir del área rara vez saca a la persona del grupo.
El tercer intento es registrar todo y revisar después: monitorear cada acción, guardar todo registro, confiar en que una auditoría futura detecte lo que se pasó de la raya. Eso sirve para reconstruir un incidente después de que ya ocurrió — no para impedir que ocurra. Un registro detallado de lo que hizo un agente de IA con un acceso que no debía tener es, en el mejor de los casos, una explicación tardía.
Ninguna de las tres soluciones ataca la causa: tratan el síntoma — demasiado acceso circulando — sin tocar el motivo, que es la ausencia de un disparador para retirarlo. Mientras la única acción con plazo y responsable siga siendo conceder, la acumulación seguirá siendo el camino de menor resistencia.
Lo que tiene que existir en la práctica
Un entorno que resuelve la acumulación de privilegio — para personas y para los agentes de IA que ellas crean — depende de mecanismos verificables, no de buena voluntad.
Acceso definido por el rol actual, no por la suma del historial. El perfil de permiso proviene del puesto que la persona ocupa hoy y se recalcula con cada cambio: quien cambia de función gana el paquete nuevo y pierde el anterior en el mismo movimiento, en lugar de simplemente acumular ambos.
Alcance en capas para cada agente de IA. Un agente no hereda automáticamente todo lo que puede acceder quien lo creó. Recibe un perfil propio, definido por la tarea que ejecuta — empresa, agente, personal y sesión funcionan como capas separadas, y lo que vale en una no pasa a la otra sin una decisión explícita.
Aprobación humana antes de conceder cualquier acceso más sensible. Pedir un acceso nuevo — para una persona o para un agente — pasa por alguien que evalúa si eso tiene sentido para la función ejercida, con la decisión registrada, y no por un formulario que cualquier gerente aprueba sin examinar.
Revisión disparada por evento, no por calendario. Un cambio de área, la salida de la empresa o el cambio de responsabilidad de un agente disparan la revisión de acceso al instante, en lugar de esperar la próxima ronda anual, cuando el exceso ya lleva meses acumulado.
Trazabilidad de quién concedió qué y cuándo. Cada concesión, cada revocación y cada aprobación quedan registradas de un modo consultable — para una persona o para un agente, es posible responder en minutos de dónde vino determinado acceso.
Así fue diseñada Skyller: acceso conforme al rol de cada persona, alcance en capas para los agentes que crea el equipo, y aprobación con trazabilidad como estándar, no como configuración aparte.
Menos acceso ocioso, más confianza
Un entorno donde el acceso refleja el rol actual, y no la suma de todo lo que alguien tuvo alguna vez, reduce lo que el área de seguridad llama superficie de exposición: si una credencial se filtra o un agente queda mal configurado, el daño posible tiene el tamaño de la función ejercida, no el tamaño de todo lo acumulado a lo largo del tiempo.
El equipo de TI también gana una respuesta rápida a la pregunta que hace cualquier auditoría: quién puede acceder a qué, hoy. Sin un mecanismo así, esa respuesta exige un proyecto — levantar planillas, cruzar sistemas, entrevistar a gerentes de cada área. Con una trazabilidad disparada por evento, se convierte en una consulta de minutos.
Para quien cambia de puesto, la ganancia es velocidad sin el efecto colateral: el acceso nuevo llega tan rápido como llegaría de todos modos, sin necesidad de conservar el anterior "por las dudas" mientras el proceso formal avanza. Y, para los agentes de IA que crea el equipo, el razonamiento se repite: un agente con un alcance bien definido puede ser reutilizado por otras personas con más seguridad, porque lo que puede hacer es visible y limitado — no una suma de permisos de los que ya nadie sabe el origen.
Preguntas para la próxima revisión de acceso
- ¿Cuántas personas tienen hoy acceso de un puesto que ya dejaron atrás? Si responder eso exige levantar información manualmente, el problema no es de disciplina — es de proceso: falta un disparador que vincule automáticamente el cambio de función con el cambio de acceso.
- Cuando se crea un agente de IA, ¿recibe un perfil propio o hereda el de quien lo configuró? Si la respuesta es "hereda", todo el exceso que esa persona ya carga pasa directo al agente — y a quien lo reutilice después.
- ¿La revisión de acceso ocurre cuando algo cambia, o solo una vez al año? Un calendario fijo garantiza que el acceso equivocado permanezca activo, en promedio, la mitad del intervalo entre una revisión y otra.
- ¿La trazabilidad muestra quién concedió cada permiso y cuándo, o solo que existe? Una trazabilidad que no responde "quién autorizó esto" en pocos minutos no cumple la función de una trazabilidad.
