9 de septiembre de 2026
Conceder a un agente de IA acceso sin restricciones a la cuenta de un empleado podría parecer la opción más pragmática. La cuenta ya está autenticada, ya cuenta con los permisos adecuados y el proyecto puede seguir adelante sin necesidad de otra larga revisión de seguridad. El problema surge en el momento en que el agente empieza a actuar, y 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ó el trabajo. La rendición de cuentas se convierte en una incógnita, y el agente dispone, sin que nadie se dé cuenta, de un acceso mucho mayor del que requiere su tarea.
Otorgar a cada agente su propia identidad es la corrección adecuada, y es la primera de las dos. Una identidad diferenciada establece qué agente actuó. No establece que un ser humano responsable haya aprobado lo que hizo el agente. Ese segundo problema persiste incluso con un programa de identidad bien gestionado, y es el que conlleva consecuencias legales y financieras.
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 registros de auditoría en todos los sistemas de la empresa».
Los identificadores únicos, las credenciales con ámbito de aplicación y un registro de auditoría que atribuye las acciones al agente correcto son, en su conjunto, propiedades de atribución. Estas propiedades determinan qué agente actuó y bajo la autoridad de quién, lo cual es una cuestión distinta de si una persona concreta aprobó la acción que llevó a cabo.
Las credenciales prestadas y la seguridad de las cuentas de servicio crean un punto ciego
Los primeros proyectos de IA suelen ejecutarse utilizando cualquier recurso al que se tenga acceso:
- Un asistente interno puede heredar permisos excesivos a menos que se restrinja explícitamente su acceso delegado.
- Un flujo de trabajo se ejecuta a través de una cuenta de servicio compartida.
- Un desarrollador conecta un agente a una API mediante una clave de larga duración.
Estas configuraciones generan diversos riesgos: acceso excesivo, atribución ambigua o credenciales persistentes. Es posible que el agente reciba más permisos de los que requiere su tarea. La actividad humana y la del agente pueden llegar a confundirse cuando se comparten credenciales. 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, una característica de seguridad que demuestra que una persona concreta envió un mensaje o realizó una transacción, y que no puede negarlo posteriormente. 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 determinada. Según el informe: «La práctica peligrosa de desplegar 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».
Se trata de fallos de atribución, y una identidad propia es la solución adecuada para ellos.
¿En qué consiste un cambio de identidad independiente?
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 deliberadamente limitado de permisos aprobados en su nombre por dicho propietario. Se puede desactivar sin que ello afecte al empleado o al equipo que hay detrás. La autenticación del agente de IA se convierte en un evento diferenciado que se puede observar 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 permanente o una clave de API. Su acceso puede limitarse a una aplicación, tarea o transacción específica. Su actividad puede revisarse en sus propios términos, independientemente de la de cualquier persona.
La reasignación merece una atención especial. Reasignar a un agente a otro titular o mandante supone un cambio de identidad, más que una simple actualización de un campo, por lo que debería requerir una nueva verificación de la persona que asume ahora la responsabilidad. Un registro de titularidad que pueda modificarse sin volver a determinar quién aceptó asumir el riesgo deja la relación expuesta a posibles disputas.
Esto se acerca más al modo en que se supone que debe funcionar el modelo «Zero Trust», en el que una autenticación previa no se considera una prueba definitiva de nada. El caso «agentic» lleva esa lógica un paso más allá. Una autenticación previa tampoco es prueba de que una persona haya dado su consentimiento a lo que ocurre a continuación.
¿Necesitan los agentes de IA acceso permanente?
A menudo, sí. El acceso de los usuarios suele estar vinculado a un puesto de trabajo, ya que las responsabilidades persisten. Algunos agentes funcionan de la misma manera. Un agente de conciliación que se ejecuta cada noche, o un agente de servicio que gestiona una cola continua, necesita una autorización permanente para poder ser útil. Otros necesitan mucho menos: recuperar una factura, cotejarla con una orden de compra y devolver el resultado. Otorgar a cualquiera de estos dos tipos el conjunto completo de permisos de un empleado sería indefendible. Las credenciales de corta duración ayudan en ambos casos, aunque reducen el margen para el uso indebido en lugar de eliminarlo por completo, y la caducidad no anula por sí misma el permiso subyacente.
El informe describe un perfil de innovación relacionado 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 que tienen en cuenta el contexto. La gestión del acceso a las cargas de trabajo elimina los permisos permanentes, reduce las superficies de ataque de máquina a máquina y elimina el punto ciego crítico que socava la mayoría de las estrategias de «cero confianza»».
Mantenemos los permisos persistentes y planteamos una pregunta diferente al respecto. No se trata de cuánto tiempo conserva un agente su autoridad, sino de quién se la concedió. Cada conjunto de permisos debe ser aprobado por una persona concreta, utilizando pruebas que el agente no haya podido generar. Un agente que pueda generar, reproducir o cumplir con esas pruebas puede, en la práctica, aprobarse a sí mismo.
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».
La intención inferida es un dato útil para tomar una decisión de acceso. No es una aprobación. La intención extraída de una conversación sigue siendo una descripción elaborada dentro del propio contexto del agente, por lo que un agente desalineado o al que se le haya inyectado una indicación puede moldearla. La evaluación de la intención puede limitar lo que hace un agente dentro de la autoridad que alguien le ha concedido. Establecer que se ha concedido dicha autoridad es un paso aparte. En este punto, hay tres controles que están realizando una labor real, y cada uno tiene el mismo límite:
- La verificación de la identidad de una persona permite determinar quién es. No determina qué es lo que ha aceptado.
- La inferencia de la intención permite determinar cuál parecía ser la intención de la petición. No demuestra que la persona viera la acción que se produjo a raíz de ella.
- El alcance del acceso se limita estrictamente a lo que el agente puede alcanzar. No implica que se deseara esa acción concreta.
Lo que necesitan las acciones de mayor repercusión es un vínculo entre tres elementos: una persona verificada, el agente que actúa en su nombre y la acción o permiso específico que dicha persona ha aprobado. Por lo tanto, la acción debe retenerse antes de que surta efecto. La capa de control, y no el agente, debe presentar en qué consiste la acción y dentro de qué límites, y la decisión debe devolverse fuera de banda, directamente a esa capa de control, a través de un canal en el que no intervenga el agente proponente. Denominamos a la evidencia generada en contra de esa decisión «resistente al agente»: el agente no puede generarla, reproducirla ni obtenerla reclutando a un segundo agente en otro dispositivo. iProov Dynamic Liveness la proporciona, demostrando la presencia de un ser humano real en el momento de la aprobación y vinculada a la acción concreta. Hemos detallado cómo debería funcionar esa delegación en un artículo aparte sobre la autorización humana verificada en la IA agentiva.
Empieza por distinguir entre personas y agentes, y luego demuestra la aprobación
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 estrictos, 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.
A continuación, hay que decidir qué acciones no pueden llevarse a cabo únicamente con la autoridad delegada, ya que es aquí donde una prueba más sólida resulta rentable. Las organizaciones suelen limitar a los agentes a tareas de baja importancia, no porque el agente no pueda hacer más, sino porque no pueden demostrar la aprobación humana para nada de mayor calado. Una prueba de aprobación que ningún agente pueda cumplir elimina ese límite. La iniciación de pagos, los cambios de beneficiario, la elevación a roles privilegiados y los cambios en los propios permisos de un agente pueden automatizarse hasta el punto de aprobación y mantenerse allí, listos para una autenticación de nivel superior; a continuación, se autorizan mediante un recibo en el que se indican el nombre del aprobador, la acción, los parámetros que se le mostraron y un periodo de validez de un solo uso. La fricción se limita a unos pocos momentos decisivos, y el trabajo rutinario entre ellos se desarrolla sin interrupciones.
Las pruebas de autorización no pueden reconstruirse a posteriori, por lo que el vínculo entre una decisión humana y la acción que autoriza debe diseñarse antes de que se pongan en marcha los 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 mediante credenciales compartidas o gestionadas de forma inadecuada, tomando decisiones trascendentales de las que no se puede demostrar que las haya tomado ninguna persona identificable.
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.
