9 de septiembre de 2026
Conceder acceso a un agente de IA a través de la cuenta de un empleado podría parecer la opción más pragmática. La cuenta ya está autenticada, cuenta con los permisos adecuados y el proyecto puede avanzar sin necesidad de otra larga revisión de seguridad. El problema surge en el momento en que el agente empieza a actuar. A partir de ese momento, la línea divisoria entre la persona y el software desaparece. El registro de auditoría indica que un empleado abrió un archivo, modificó un registro o aprobó una transacción, cuando en realidad fue un agente quien realizó la tarea. La rendición de cuentas se convierte en una incógnita, y el agente dispone, de forma silenciosa, de un acceso mucho mayor del que requiere su tarea.
El «Hype Cycle™» de Gartner® de 2026 sobre identidad digital define esta categoría de la siguiente manera: «La identidad de los agentes de IA es la representación digital única de dichos agentes dentro de una organización». Establecer y gestionar la identidad de los agentes de IA, incluidos los asistentes y los chatbots, permite a los sistemas de gestión de identidades y accesos (IAM) asignar identificadores únicos, emitir credenciales específicas para el acceso a recursos (por ejemplo, API, datos y servicios) y establecer una responsabilidad humana clara y pistas de auditoría en todos los sistemas de la empresa».
Esa definición establece un listón claro, y la mayoría de las primeras implementaciones de IA se quedan muy por debajo de él. El riesgo radica precisamente en la diferencia entre tener un agente y que ese agente tenga una identidad.
Las credenciales prestadas y la seguridad de las cuentas de servicio crean un punto ciego
Los primeros proyectos de IA suelen funcionar con cualquier acceso que ya esté disponible. Un asistente interno hereda los permisos del empleado que lo utiliza. Un flujo de trabajo se canaliza a través de una cuenta de servicio compartida. Un desarrollador conecta un agente a una API con una clave de larga duración. Cada atajo funciona, y cada uno introduce las mismas debilidades. El agente suele recibir todos los permisos que tiene el empleado cuando necesita acceder a un único sistema. La actividad humana y la del agente se confunden. Es posible que los equipos de seguridad no dispongan de una forma fiable de saber cuándo se está ejecutando un agente o qué transacciones ha completado.
Por eso la seguridad de las cuentas de servicio se ha convertido en un problema urgente, más que en una simple cuestión administrativa. Una cuenta de servicio compartida nunca se diseñó para actuar como un agente autónomo que tomara sus propias decisiones a la velocidad de una máquina, y una clave de API estática no contiene ninguna información sobre quién autorizó el trabajo ni por qué.
Las credenciales prestadas también socavan el no repudio. Cuando una persona y un agente comparten una misma identidad, la organización no puede demostrar cuál de los dos realizó una acción concreta. Según el informe: «La práctica peligrosa de implementar agentes de IA como representantes que operan con credenciales de acceso humanas incumple los requisitos de auditoría, trazabilidad y no repudio, lo que eleva significativamente el riesgo de conceder permisos excesivos, así como el impacto de la filtración de credenciales y la apropiación de cuentas».
Qué cambia una identidad propia
Una identidad dedicada proporciona al agente su propio registro en el entorno de IAM, con un propietario identificado, un propósito definido y un conjunto de permisos deliberadamente limitado. Se puede desactivar sin afectar al empleado o al equipo que hay detrás. Esa separación hace posible un control real. La autenticación del agente de IA se convierte en un evento diferenciado que se puede ver y analizar, en lugar de algo oculto dentro de una sesión humana. Al agente se le pueden asignar credenciales de corta duración en lugar de una contraseña fija o una clave API. Su acceso puede limitarse a una aplicación, tarea o transacción específicas. Su actividad puede revisarse por sí misma, independientemente de la de cualquier persona. La titularidad puede reasignarse a medida que cambia su función, y los permisos pueden caducar en el momento en que finalice la tarea.
Esto se acerca mucho más al modo en que se supone que debe funcionar el modelo «Zero Trust», en el que el acceso se basa en el contexto y en la necesidad del momento, en lugar de en el hecho de que una identidad haya sido autenticada en algún momento anterior.
Los agentes de IA rara vez necesitan acceso permanente
El acceso de las personas suele estar vinculado a su puesto de trabajo. Una persona que trabaja en el departamento de finanzas necesita acceso permanente a una serie de sistemas financieros, ya que sus responsabilidades son continuas. En cambio, un agente rara vez lo necesita. Es posible que solo tenga que recuperar una única factura, cotejarla con una orden de compra y devolver el resultado. Otorgarle el conjunto completo de permisos de un empleado sería injustificable.
Este es el caso de las credenciales efímeras. Mientras que una cuenta de usuario puede conservar una contraseña durante meses, a un agente se le puede asignar una credencial que dura lo que tarda en completarse una tarea y caduca una vez finalizada. No queda ningún rastro que un atacante pueda encontrar.
La gestión del acceso a las cargas de trabajo aborda este problema sustituyendo las credenciales estáticas y los permisos permanentes por un acceso dinámico y sensible al contexto. El informe lo describe de la siguiente manera: «La gestión del acceso a las cargas de trabajo, que forma parte de un programa global de gestión de identidades y accesos (IAM) para máquinas, protege el universo en rápida expansión de las cargas de trabajo —que incluye agentes de IA, aplicaciones, contenedores y microservicios— al aplicar el principio del mínimo privilegio en tiempo de ejecución, sustituyendo las credenciales estáticas por controles dinámicos y sensibles al contexto. La gestión del acceso a las cargas de trabajo elimina los permisos permanentes, reduce las superficies de ataque entre máquinas y subsana el punto ciego crítico que socava la mayoría de las estrategias de «cero confianza»».
La identidad por sí sola no explica la intención
Una identidad independiente determina qué agente está actuando. No dice nada sobre lo que ese agente está tratando de conseguir. La distinción cobra importancia en cuanto un agente recibe una instrucción general como «organiza mi viaje de negocios» o «resuelve el problema con la cuenta de este cliente». El agente puede interpretar la solicitud de formas que el usuario nunca pretendió, y puede desviarse de su objetivo mediante la inserción de indicaciones o datos falsos.
Aquí es donde se diferencian la autenticación y la autorización. La autorización del agente de IA debe responder a una pregunta que el proceso de inicio de sesión no puede resolver: ¿se encuentra esta acción concreta dentro de los límites de lo que la persona solicitó realmente?
El informe describe otro perfil de innovación que aborda precisamente esto: «El control de acceso basado en la intención es un marco de autorización emergente que sustituye a los permisos generales y permanentes y que, aunque actualmente está orientado a la IA agentiva, ofrece una amplia aplicabilidad. El control de acceso basado en la intención concede acceso a los recursos de back-end en función de la intención captada o inferida de los usuarios que interactúan con un agente y evalúa las acciones previstas por el agente en relación con dicha intención».
Los agentes de atención al cliente suben el listón
Las organizaciones también deben prepararse para los agentes que no gestionan en absoluto. En poco tiempo, los clientes utilizarán sus propios agentes para realizar compras, actualizar cuentas, enviar formularios y ponerse en contacto con los equipos de atención al cliente. La empresa tendrá que determinar quién es el cliente, si el agente está realmente autorizado para actuar en su nombre y qué es exactamente lo que el cliente le ha permitido hacer. El informe señala «soluciones de gestión de identidades y acceso (IAM) para clientes, destinadas a gestionar las identidades de los agentes de IA en contextos de atención al cliente, en los que los clientes envían a sus agentes de IA a interactuar con las organizaciones».
Creemos que es aquí donde el reto se agudiza. Detectar si el tráfico procede de un bot no es suficiente. Las organizaciones necesitan una forma fiable de vincular tres elementos: una persona real, el agente que actúa en su nombre y el permiso específico que esa persona ha concedido. Esa vinculación solo es válida si primero se puede demostrar que hay una persona real y que es quien dice ser. Si se establece correctamente ese punto de referencia, la autoridad del agente se remonta a una persona verificada, en lugar de a un inicio de sesión prestado.
Hemos analizado cómo debería funcionar esa delegación en la práctica en un artículo aparte sobre la autorización humana verificada en la IA agentiva.
Empieza por distinguir entre personas y agentes
Los agentes no deben ser extensiones invisibles de la cuenta de un empleado. Hay que dotar a cada uno de ellos de su propia identidad, asignarles un responsable, mantener sus permisos bien controlados, realizar un seguimiento de sus acciones y retirarles el acceso una vez finalizado el trabajo . Si se gestiona adecuadamente, se trata de una gestión del ciclo de vida de los agentes de IA, más que de una configuración puntual: los agentes se crean, se revisan, se reasignan y se retiran, y la gobernanza de los agentes de IA es lo que garantiza la integridad de ese ciclo a medida que aumenta el número de agentes.
Estos pasos requieren un esfuerzo al inicio de un proyecto, pero evitan un problema mucho mayor más adelante: miles de agentes autónomos que operan con credenciales diseñadas exclusivamente para personas.
Gartner, «Hype Cycle for Digital Identity», 2026, Zachary Smith, Nayara Sangiorgio, 6 de julio de 2026.
«Gartner» y «Hype Cycle» son marcas registradas de Gartner, Inc. y/o sus filiales.
Gartner no respalda a ninguna empresa, proveedor, producto o servicio mencionado en sus publicaciones, ni aconseja a los usuarios de tecnología que elijan únicamente a aquellos proveedores con las calificaciones más altas u otras distinciones. Las publicaciones de Gartner recogen las opiniones de la organización de análisis empresarial y tecnológico de Gartner y no deben interpretarse como afirmaciones de hecho. Gartner renuncia a toda garantía, expresa o implícita, con respecto a esta publicación, incluidas las garantías de comerciabilidad o de idoneidad para un fin determinado.
Próximo capítulo de la serie: por qué la visibilidad de la identidad es tan importante cuando las personas, las máquinas y los agentes de IA interactúan en un mismo entorno.
Preguntas frecuentes
¿Deberían los agentes de IA tener su propio sistema de identidad y permisos?
Sí. Un agente que se ejecuta en una cuenta de usuario hereda todos los permisos de esa persona, y sus acciones se registran a nombre de esta. Contar con una identidad independiente te permite limitar los permisos a la tarea en cuestión, asignar un responsable y revisar la actividad del agente por separado.
¿Cuál es el riesgo de permitir que un agente de IA utilice las credenciales de los empleados?
Se acumulan tres riesgos. El agente casi siempre cuenta con privilegios excesivos, ya que recibe el conjunto completo de permisos del empleado para una tarea que solo requiere un sistema. El registro de auditoría deja de ser fiable, ya que las acciones de las personas y las del agente son indistinguibles. Y se rompe el principio de no repudio, ya que no se puede demostrar cuál de los dos realizó una acción concreta.
¿Qué es la identidad de un agente de IA?
Se trata de un registro independiente para un agente de IA en tu entorno de gestión de identidades y accesos, con su propio identificador, credenciales, titular y permisos, independiente de cualquier cuenta de usuario humano. Su finalidad es que la actividad del agente pueda autorizarse, registrarse y revocarse con independencia de las personas para las que trabaja el agente.
¿En qué se diferencia la gestión de identidades no humanas de la gestión tradicional de identidades y acceso (IAM)?
El modelo tradicional de IAM parte de la base de que una persona tiene un cargo, un responsable y unas responsabilidades fijas, por lo que el acceso se concede una sola vez y se revisa periódicamente. Las identidades no humanas no tienen un cargo específico, pueden superar en número a los empleados en muchas ocasiones y pueden necesitar acceso durante segundos en lugar de años. Esto lleva a que el modelo se oriente hacia credenciales de corta duración y autorizaciones en tiempo de ejecución, en lugar de permisos permanentes.
¿Cuánto tiempo debería durar el acceso de un agente de IA?
Por regla general, no debe durar más que la tarea en cuestión. Mientras que una cuenta de usuario humano conserva una credencial durante meses, a un agente se le puede asignar una que caduque al finalizar el trabajo, lo que elimina el permiso permanente que, de otro modo, heredaría un atacante.
