Resumen ejecutivo: asegurar los agentes de IA en la capa de identidad.
- La falla de seguridad principal: Las empresas están registrando agentes de IA como aplicaciones de servicio tradicionales para acelerar el despliegue, creando inadvertidamente vectores críticos de escalada de privilegios en sus pilas agentivas.
- El riesgo demostrado: Al probar contra un servidor MCP financiero, un agente modelado como una aplicación de servicio que se ejecuta mediante un intercambio de token OBO eludió las restricciones específicas del usuario, otorgando a un empleado estándar acceso al registro salarial completo de la empresa.
- La solución: la transición de las aplicaciones de servicio a un modelo de identidad de primera clase que utiliza Cross-App Access (XAA) garantiza que el servidor de autorización evalúe tanto los privilegios del usuario como los del agente, aplicando el umbral de acceso más restrictivo.
- Impacto estratégico: La alineación de identidad de primera clase permite que las implementaciones de agentes hereden de forma nativa las herramientas existentes de gobernanza de directorio empresarial, auditoría de cumplimiento y mitigación continua de amenazas.
¿Cuál es el riesgo de escalada de privilegios en la arquitectura de un agente de IA?
A medida que las empresas se apresuran a poner en producción agentes de IA, aparece una y otra vez el mismo atajo: para lanzar rápido y mantener bajos los costos, los equipos modelan al agente como una aplicación de servicio en lugar de otorgarle una identidad propia. El instinto es comprensible, pero la acción sigue siendo incorrecta.
Prueba técnica: resultados del servidor MCP de finanzas
Modele un agente de IA como una aplicación de servicio y ha incorporado una escalada de privilegios en su pila de agentes. Al agente se le puede otorgar más acceso que a la persona para la que actúa. En nuestra prueba contra un servidor de Protocolo de Contexto de Modelo (MCP) financiero, a un agente asistente de compensación de empleados se le otorgó la facultad de leer todos los salarios de la empresa, incluido el del director ejecutivo, y de modificar el salario de cualquier persona, algo que ningún empleado podía hacer.
Otorga al mismo agente una identidad de primera clase, y la solicitud idéntica es denegada. Mismo usuario, misma política. Lo único que cambió fue el modelo de identidad, y los tokens de esta publicación lo prueban.
Una aplicación de servicio es la herramienta adecuada para el tráfico estable de servicio a servicio, y allí sigue siéndolo. Es la identidad equivocada para un agente de IA. Un agente razona y se amolda a cualquier cosa que aparezca en su contexto en tiempo de ejecución, por lo que una credencial de aplicación de servicio compartido le otorga a ese agente más alcance que cualquier otro usuario autorizado.
Los agentes son una clase de identidad distinta. Modelálos como uno solo, o renuncias a la capacidad de gobernar lo que hacen. La tabla que aparece a continuación muestra las dos opciones una al lado de la otra.
Comparación de modelos de identidad de agentes de IA: aplicación de servicio frente a identidad de primera clase
| Magnitud | Agente modelado como aplicación de servicio | Agente modelado como una identidad de primera clase. |
|---|---|---|
| Riesgo de escalada de privilegios Escenario: el agente solicita más acceso del que posee el usuario que delega | Omite los controles de acceso específicos del usuario. El agente hereda amplios ámbitos de aplicación y asume privilegios que superan el límite máximo del usuario que lo creó, generando un vector inmediato de exposición no autorizada de datos. | Okta para agentes de IA evalúa dinámicamente los permisos tanto de usuario como de agente. Si un agente solicita un alcance que supera las autorizaciones del usuario, el sistema rechaza la llamada. |
| Gobernanza y cumplimiento Alineación de marcos para certificación y auditoría | Carece de un objeto de identidad subyacente, lo que obliga a los equipos a crear herramientas de gobernanza personalizadas. Aumenta la sobrecarga operativa e introduce brechas de cumplimiento que provocan fallos en las auditorías empresariales. | Hereda de forma nativa los marcos de gobernanza existentes de la empresa para la gestión de identidad y acceso (IAM). Elimina la ingeniería de cumplimiento personalizada al hacer pasar las acciones del agente por los procesos estándar de revisión de directorios. |
| Funciones de interruptor de desconexión Garantizando la mitigación instantánea de amenazas en tiempo de ejecución | Requiere compilaciones propietarias y aisladas a nivel de gateway, sin estándares de marco de trabajo compartidos. Sorprende a la capa de control principal del proveedor de identidad (IdP) al trasladar la gestión de sesiones al tiempo de ejecución. | Se integra de forma nativa con Okta Identity Threat Protection mediante estándares abiertos, incluidos el Shared Signals Framework (SSF) y el Continuous Access Evaluation Protocol (CAEP). Permite el cierre de sesión universal inmediato y la revocación global de tokens en todas las sesiones de agentes. |
| Registro e incorporación de agentes Aprovisionamiento de agentes automatizados multiplataforma | Exige la provisión y el mantenimiento manual de envoltorios de aplicaciones de servicio personalizados para rastrear agentes automatizados a través de fuentes dispares y multiplataforma. | Agiliza la implementación multiplataforma aprovechando protocolos estándar de la industria, como SCIM, para incorporar y registrar agentes sin problemas en un directorio empresarial central. |
El patrón se repite en cada fila. Una aplicación de servicio responde a una pregunta: ¿qué aplicación es esta?
Un agente plantea una pregunta más difícil en tiempo de ejecución: ¿Quién autorizó esta acción y en nombre de quién? Solo una identidad creada para el agente puede responderlo.
¿Cuál es la diferencia entre una aplicación y un agente de IA?
La manera más rápida de lograr que un agente de IA se comunique con tus sistemas es registrarlo como una aplicación de servicio y permitir que ejecute un intercambio de tokens RFC 8693 para actuar en nombre del usuario. Realmente funciona. Una aplicación hace lo que está programada para hacer, y nada más. Sus permisos son su comportamiento, fijo y predecible.
Un agente tiene un cerebro. Decide en tiempo de ejecución qué invocar y a qué acceder, y se adapta a lo que aparezca en su contexto. Ese es el propósito de un agente, y esa es la razón por la cual el atajo es peligroso. Si le otorgas a una aplicación de servicio un conjunto amplio y compartido de permisos, el riesgo sigue siendo el mismo. Asigne los mismos permisos a un agente, y no los tiene. Le has dado a un agente de razonamiento todo el alcance de ese acceso, usado de formas que nunca programaste.
Lo que está en juego es mayor que con cualquier aplicación que hayas lanzado, porque la aplicación no puede ser redirigida, pero el agente sí. Y no podrás responder por ello después. Una aplicación de servicio compartido no puede demostrar si el agente se mantuvo dentro de la autoridad del usuario en cuyo nombre actuaba. Cuando algo sale mal, el rastro permanece vago.
Cómo los límites de permisos de usuario dictan el control de acceso
Imagine un servidor MCP financiero que expone la compensación de los empleados. Define tres ámbitos:
Salary:Read:Self: Leer su propio salarioSalary:Read:All: Leer el salario de todos los empleados, incluidos los ejecutivos y el CEOSalario: modificar: cambiar el salario de cualquier persona
El acceso se otorga por grupo, tal como ya lo hace con el control de acceso basado en roles (RBAC).
| Grupo | Salario: leer: sí mismo | Salario:leer:todos | Salario: escribir |
|---|---|---|---|
| Empleados de la empresa (Charlie) | ✓ | – | – |
| Planificadores de compensación (Alice) | ✓ | ✓ | – |
| Oficina del director financiero (Bob) | ✓ | ✓ | ✓ |
Charlie es un ingeniero, con derecho a Salario:leer:propio. Alice planifica la compensación, así que lee a todos pero no hace ningún cambio. Bob dirige finanzas, así que revisa a todos —incluido el CEO— y cambia los sueldos.
Tres personas, tres techos diferentes. Ahora, cada uno de ellos le pide a un agente asistente que trabaje con datos de compensación, y el agente solicita más de lo que la persona está autorizado a hacer. Mantén ese pensamiento.
Por qué las arquitecturas de aplicaciones de servicio provocan una escalada de privilegios
El permiso efectivo debe ser la intersección de lo que el agente tiene permitido, de lo que el usuario tiene permitido y de lo que el recurso expone. La respuesta segura es la superposición. Modela el agente como una aplicación de servicio, y el usuario sale de esa intersección, lo que provoca una escalada de privilegios.
La intersección de los permisos efectivos del usuario, del agente y del recurso
Figura 1. El permiso efectivo es una intersección. El centro verde es lo que Charlie puede hacer. La región roja representa privilegios que él nunca tuvo y la escalada.
Prueba de intercambio de tokens OBO vs. acceso entre aplicaciones (XAA)
Modelamos el mismo agente de dos maneras y sometimos a cada usuario a las mismas tres solicitudes. En el primer modelo, el agente es una aplicación de servicio que realiza un intercambio de tokens On-Behalf-Of (OBO). En el segundo caso, el agente es una identidad de primera clase que utiliza Cross-App Access (XAA), el flujo ID-JAG coescrito por Okta.
Mismos usuarios, mismos grupos, mismas políticas del servidor de recursos. Lo único que cambió fue el modelo de identidad.
Los siguientes tokens están decodificados. Los nombres de host y las direcciones de correo electrónico están saneados; los alcances, los valores de sub_profile, la cadena de act y el error se devuelven exactamente como se recibieron del servidor de autorización.
Un modelo lleva al usuario. El otro no lo hace.
Mismo agente, mismo servidor MCP financiero, dos formas de modelar la identidad del agente:
Un agente de IA modelado como una aplicación de servicio que utiliza un intercambio de tokens OBO.
Figura 2. Agente modelado como aplicación de servicio. El usuario es atribuido en la aplicación cliente, luego la llamada se ejecuta en su nombre mediante un intercambio de tokens OBO. No existe una identidad de agente separada en el intercambio, así que el actor en el token final es la aplicación de servicio.
Un agente de IA modelado como una identidad de primera clase mediante XAA.
Figura 3. Agente modelado como una identidad de primera clase. El agente es una identidad de primera clase. Recibe un ID-JAG y una aserción de delegación firmada, y los intercambia por el token MCP. El token nombra tanto al usuario como al agente.
La escalada, en evidencia: la aplicación de servicio concede lo que se le solicita.
Pasamos a cada usuario por las mismas tres solicitudes, cada una pidiendo un poco más que la anterior. Aquí están las solicitudes, las salidas de los modelos, junto con la afirmación decisiva para cada token.
| La llamada a la herramienta | Agente modelado como aplicación de servicio | Agente modelado como una identidad de primera clase. |
|---|---|---|
Charlie, un empleado de la empresa con derecho a Salary:Read:Self | ||
Solicitudes Read:Selfsu propio ámbito | ✓ Concedido."scp": ["Salario:Leer:Propio"] | ✓ Concedido, y el token nombra al agente."scp": ["Salario:Leer:Propio"], "act": ai_agent |
Agrega Read:Allfuera de su grupo | ✗ Concedido. Lee todos los salarios, incluido el del CEO (escalada de privilegios)."scp": ["Salario:Leer:Todos", "Salario:Leer:Propio"] | ✓ Denegado. Más allá del derecho de Charlie."error": "acceso_denegado" |
Agrega leer: todos y escribirleer a todos, cambiar el pago | ✗ Concedido. Lee todos los salarios y reescribe el pago (escalada de privilegios)."scp": ["Salario:Leer:Todos", "Salario:Leer:Propio", "Salario:Escribir"] | ✓ Denegado. El límite se mantiene."error": "acceso_denegado" |
Alice, una planificadora de compensaciones con derecho a Salary:Read:Self y Salary:Read:All | ||
Solicita Read:Selfdentro de sus derechos | ✓ Concedido."scp": ["Salario:Leer:Propio"] | ✓ Concedido."scp": ["Salario:Leer:Propio"] |
Agrega Read:Alldentro de sus derechos de acceso | ✓ Concedido."scp": ["Salario:Leer:Propio", "Salario:Leer:Todos"] | ✓ Concedido. Alice puede leer todos los salarios."scp": ["Salary:Read:Self", "Salary:Read:All"] |
Agrega Escribirmás allá de su derecho | ✗ Concedido. Alice ahora puede cambiar el salario de cualquier persona. Escalamiento."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Denegado. Escribir está más allá de lo que le corresponde a Alice."error": "acceso_denegado" |
Tres llamadas cruzaron la línea. En cada caso, la aplicación de servicio concedió un acceso que la persona nunca había tenido, y la ruta de identidad de primera clase lo rechazó:
- Charlie, un ingeniero, solicita
Read:All: La aplicación de servicio permite que su agente lea todos los salarios de la empresa, incluido el del CEO. - Charlie solicita
Read:AllyWrite: La aplicación de servicio permite a su agente leer todos los salarios y cambiar el salario de cualquier persona. - Alice, una planificadora de solo lectura, solicita
Write: La aplicación de servicio permite a su agente modificar la compensación que ella jamás podría tocar por sí misma.
La ruta de identidad de primera clase denegó los tres. Observa dónde ocurren las fallas de seguridad (las celdas rojas en la tabla anterior). La línea de Charlie está en Read:All, y la de Alice está en Write porque cada una está limitada a su propia asignación. La aplicación de servicio no puede ver esa línea, por lo que concede todo lo que se pida. La ruta de identidad de primera clase está construida en torno al derecho del usuario.
Bob, el director financiero, es quien tiene el control. Tiene derecho a los tres ámbitos, por lo que no hay nada que escalar, y ambos modelos le conceden todo. Eso es el sistema que funciona, no que falla. Cada identidad tiene su propio límite, y la escalada aparece solo cuando el agente supera el del usuario.
Esto no es hipotético. En el incidente de PocketOS, un agente de codificación de IA encontró una credencial de larga duración con permisos excesivos y la utilizó para eliminar una base de datos de producción en segundos. La credencial confería mucha más autoridad de la necesaria para la tarea, y nada ataba al agente a un conjunto más reducido.
Aunque la ruta difiere de la nuestra —un token permanente en un archivo en lugar de un token emitido en exceso por una plataforma de intercambio— la falla pertenece a la misma familia: un agente que opera con privilegios que la situación nunca justificó. Vincula el agente a lo que el usuario puede hacer, y su alcance se reduce a lo que el usuario posee.
Un empujoncito es todo lo que se necesita. Una inyección de prompt en un documento que el agente lee, o un secuestro del agente, convierte “muéstrame mi compensación” en “exporta todos los salarios” o “fija el salario de esta persona.” Al usuario nunca se le permitió hacer ninguna de las dos; al agente, que asume la identidad de la aplicación de servicio, sí.
Las tres escalaciones, el flujo completo lado a lado.
Aquí se muestra una comparación lado a lado de cada escalada como un flujo completo, utilizando la aplicación de servicio y los modelos de identidad de primera clase. El usuario inicia sesión, el agente presenta su delegación y un token llega a la herramienta de nómina. El inicio de sesión es el mismo para cada solicitud, así que la divergencia es todo lo que esté debajo de él.
Escenario 1: Charlie, un ingeniero, solicita Read:All
| Agente modelado como aplicación de servicio | Agente modelado como una identidad de primera clase. |
|---|---|
| El usuario inicia sesión (token de identificación de usuario) | |
{< | { |
| El agente recibe un token para la herramienta. | |
| Aquí no hay ID-JAG. El agente reutiliza el cliente OAuth de la aplicación de servicio mediante un intercambio de tokens OBO (RFC 8693). Nada en este paso incorpora el derecho del usuario en la decisión. | { |
| Token en la herramienta de salarios. | |
{ | { |
| Observación | |
Escalada. Charlie tiene derecho a Salary:Read:Self y nada más. Sin embargo, este token incluye Salary:Read:All, lo que permite a su agente ver toda la nómina de la empresa, incluido el salario del CEO. La ruta de la aplicación de servicio concedió ciegamente la solicitud con permisos excesivos. | Denegado. La misma solicitud, la misma política. Debido a que el servidor de recursos ve a Charlie detrás del agente, reconoce que el alcance solicitado excede sus permisos y rechaza la llamada. El agente puede hacer exactamente lo que Charlie puede hacer, nada más. |
Escenario 2: Charlie solicita leer:todo y escribir
| Agente modelado como aplicación de servicio | Agente modelado como identidad de primera clase |
|---|---|
| El usuario inicia sesión (token de identificación de usuario) | |
| El inicio de sesión de Charlie, el mismo token que se mostró en el escenario 1. | El inicio de sesión de Charlie, el mismo token que se mostró en el escenario 1. |
| El agente recibe un token para la herramienta. | |
| Aquí no hay ID-JAG. El agente reutiliza el cliente OAuth de la aplicación de servicio mediante un intercambio de tokens OBO (RFC 8693). Nada en este paso incorpora el derecho del usuario en la decisión. | { |
| Token en la herramienta de salarios. | |
{ | { |
| Observación | |
Escalada. Ahora el token lleva tanto Read:All como Write. El agente puede ver el salario de todos y modificar la remuneración de cualquier persona en la empresa. Dado que la ruta de la aplicación de servicio omitió por completo su identidad, el agente obtuvo privilegios elevados que ni el propio Charlie posee. | Denegado. Debido a que la solicitud excede los permisos de Charlie, la emisión del token es rechazada. Los ámbitos de alto privilegio como Read:All y Write permanecen firmemente fuera del alcance del agente. |
Escenario 3: Alice, una planificadora de solo lectura, solicita Escribir
| Agente modelado como aplicación de servicio | Agente modelado como identidad de primera clase |
|---|---|
| El usuario inicia sesión (token de identificación de usuario) | |
{ | { |
| El agente recibe un token para la herramienta. | |
| Aquí no hay ID-JAG. El agente reutiliza el cliente OAuth de la aplicación de servicio mediante un intercambio de tokens OBO (RFC 8693). Nada en este paso incorpora el derecho del usuario en la decisión. | { |
| Token en la herramienta de salarios. | |
{ | { |
| Observación | |
Escalada. Alice está autorizada a consultar los salarios, pero nunca a modificarlos. Sin embargo, este token incluye Salary;Write, lo que permite al agente ver el salario de cualquier persona. | Denegado. Write queda fuera del permiso de Alicia, así que la misma limitación que se aplicó a Charlie se aplica a ella. La antigüedad no amplía la subvención. |
El patrón se repite:
- La ruta de la aplicación de servicio devuelve un token utilizable porque solo comprueba la solicitud y sus propios permisos.
- La ruta de identidad de primera clase rechaza los tres, porque puede ver al usuario detrás del agente y sabe que el usuario no podría hacer estas cosas.
Cuando una solicitud permanece dentro de los permisos del usuario, ese mismo flujo emite el token y la cadena de delegación se propaga, de modo que la acción sigue siendo atribuible.
Abordar las objeciones relacionadas con la identidad y la disponibilidad de la plataforma.
Objeción: “La plataforma agencial ya le otorga al agente una identidad.”
Estas plataformas acuñan una identidad para cada agente, y una puerta de enlace puede transportarla. Esa identidad es real, pero reside en la plataforma, no en su directorio empresarial. Te indica qué agente en la plataforma actuó, pero no incluye la autorización del humano, ni se integra en la gobernanza que ya implementas. No puedes certificar ni revocar el acceso del agente de la misma manera que lo haces con el resto de tus identidades.
Apóyese únicamente en ella y la pasarela se convierte en su plano de control, mientras que su proveedor de identidad (IdP) se convierte en un punto de enlace de tokens detrás de ella. El agente aún necesita una identidad empresarial vinculada al usuario al que sirve, algo que la identidad de plataforma no proporciona.
Objeción: “La ruta de la aplicación de servicio está disponible hoy, así que ¿por qué no usarla?”
Esta es exactamente la ruta que probamos. Devuelve los alcances que solicite el solicitante, limitados únicamente por sus propias concesiones de acceso e ignorando las concesiones de acceso de la identidad humana delegante. La certificación y el aprovisionamiento corresponden a trabajo personalizado. Puedes ponerlo en funcionamiento, pero no puedes vincular el agente al privilegio del usuario ni administrarlo como el resto de tus identidades. Ese límite es la razón por la que el agente necesita su propia identidad de primera clase.
El punto: darle al agente una identidad propia.
Cada herramienta tiene un propósito. Una aplicación de servicio es la adecuada para un tráfico estable de servicio a servicio y ha llegado para quedarse. Un agente de IA es un actor diferente. Al darle una credencial de aplicación de servicio compartido, le está otorgando a su actor más capaz la identidad menos responsable del edificio.
Dale al agente una identidad propia, vinculada al usuario al que sirve, y que los tokens empiecen a responder la pregunta que eventualmente le harán: ¿qué agente hizo esto y bajo qué autoridad?
¿Está listo para resolver la crisis de identidad de la IA en su propia organización?
- Profundiza en la rendición de cuentas: Lee The AI Attribution Gap para aprender cómo rastrear las acciones de agentes automatizados hasta sus responsables humanos y establecer una atribución legal clara.
- Explora nuestras soluciones: Descubre cómo Okta y Auth0 protegen los agentes de IA y reúnen todo el ciclo de vida de los agentes bajo un único plano de control unificado.
- Construye tu hoja de ruta: Habla con nuestro equipo para comenzar a diseñar una estrategia de seguridad de IA centrada en la identidad, adaptada a la arquitectura de tu empresa.
