Resumen ejecutivo
Gestionar internamente la identidad de los agentes de IA Enterprise se convierte rápidamente en una carga continua de gobernanza y cumplimiento normativo. Requiere centralizar la autenticación, la autorización, la gestión del ciclo de vida de los tokens y el registro de auditoría en todos los agentes internos, de terceros y en la sombra. La creación de una capa de acceso personalizada genera puntos ciegos de seguridad, errores de cumplimiento durante las auditorías y una carga de trabajo de ingeniería continua a medida que evolucionan las especificaciones de MCP y OAuth.
Invertir en una capa centralizada de identidad de agentes permite a las empresas desacoplar el acceso a las herramientas de la gestión de credenciales, al tiempo que facilita la auditoría continua y la seguridad Zero Trust, y mantiene a sus ingenieros centrados en el desarrollo de los agentes que le ayudan a ejecutar tareas críticas para el negocio.
¿Qué es una capa de identidad de agente de IA y cómo se construye?
Cuando los agentes de IA comenzaron a tomar medidas en lugar de simplemente responder preguntas, los equipos de la plataforma tuvieron que conectarlos rápidamente con herramientas y datos reales. Muchos equipos terminaron construyendo ellos mismos una capa de acceso, que generalmente tiene tres componentes principales:
- Una puerta de enlace del protocolo de contexto del modelo (MCP) que enruta el tráfico del agente a los servidores MCP
- Un intermediario de tokens que almacena y actualiza las credenciales de cada usuario para las aplicaciones SaaS que llaman los agentes.
- Filtrado de ámbito basado en roles que limita las herramientas que un agente puede usar en función del rol del usuario.
Esas compilaciones requirieron meses de trabajo de ingeniería, pusieron agentes en producción y mantuvieron las credenciales fuera de las indicaciones. Para la mayoría de los equipos, construir era la única opción en aquel momento.
Descargue nuestro documento técnico Identidad de agentes de IA: desarrollar frente a comprar para descubrir por qué adquirir una capa de identidad diseñada específicamente para este fin es la forma más eficaz de gestionar los agentes de IA a lo largo de todo su ciclo de vida, sin sobrecargar a su equipo de ingeniería con un mantenimiento de identidades interminable.
Las seis preguntas clave sobre la identidad de los agentes de IA Enterprise
A medida que aumenta la adopción de agentes y estos asumen tareas más críticas para el negocio, los equipos se dan cuenta de que necesitan responder a más preguntas:
- Identidad del agente: ¿Quién es cada agente?
- Propiedad: ¿Quién es el propietario del agente?
- Delegación: ¿En nombre de quién actúa el agente?
- Alcance: ¿Qué herramientas y recursos puede abarcar?
- Registro de auditoría: ¿Qué acciones específicas ha realizado?
- Interruptor de seguridad: ¿Cómo pueden los equipos revocar acceso o desactivarlo rápidamente?
Cómo crece el alcance
La primera versión para construir una capa de acceso de agentes es manejable. Un equipo crea un pequeño grupo de agentes, asigna a cada uno una identidad de servicio, almacena los tokens SaaS de los usuarios en un intermediario y mantiene una lista de qué agentes existen y quién los creó. Para un único equipo cuyos agentes permanecen dentro de su propia plataforma, ese diseño funciona bien.
Luego, el número de agentes y las necesidades del negocio siguen creciendo. Cada nueva aplicación SaaS a la que acceden sus agentes ejecuta su propio servidor de autorización con su propio modelo de consentimiento, duración de los tokens y comportamiento de revocación, por lo que el intermediario necesita una integración adicional. Otros equipos inician el envío de agentes según sus propios cronogramas, y algunos nunca pasan por la capa que construyó su equipo de plataforma.
Los desarrolladores ejecutan agentes de codificación como Claude Code, Codex y Cursor en sus portátiles, y estos agentes se conectan directamente a los servidores MCP y a los repositorios de código pegando tokens en un archivo de configuración local, ya que nunca pasan por el proceso de compilación central. Los agentes en las plataformas de los proveedores acceden a sus datos a través de los conectores propios del proveedor. Los agentes insertados, los enjambres de agentes y los modelos locales exponen nuevas deficiencias, y cada nueva integración añade carga a una pila de identidad de la que ahora dependen Workflows más críticos.
Para entonces, el equipo que creó una capa de acceso para sus propios agentes ya está gestionando un producto de identidad para el resto de la empresa.
Gestionar su propia Identity Governance significa que la temporada de auditoría nunca termina.
Muchas Organizations comienzan con un registro de agentes sencillo: una lista de cada agente, quién es su propietario y las herramientas y aplicaciones a las que puede acceder. Deja de funcionar cuando otros equipos envían agentes, los propietarios cambian de funciones o abandonan la empresa, y los auditores solicitan pruebas de que alguien revisó el acceso de cada agente este trimestre.
Esa evidencia rara vez reside en un solo lugar. La puerta de enlace registra una cosa, el intermediario registra otra y las aplicaciones SaaS a las que accedió el agente registran una tercera, por lo que demostrar lo sucedido implica extraer los registros de cada sistema y correlacionarlos manualmente.
Para escalar realmente la cantidad de agentes, la mayoría de los equipos descubren que el registro también tiene que hacer más: reasignar o retirar agentes cuyos propietarios ya no están, ejecutar certificaciones de acceso según un cronograma y mostrar quién autorizó una acción, para quién y bajo qué política, meses después de que haya ocurrido. Ese trabajo se repite en cada ciclo de auditoría y aumenta con cada agente que su organización incorpora.
OWASP sitúa el abuso de identidad y privilegios de agente en el tercer puesto entre los principales riesgos para las aplicaciones basadas en agentes, citando la propiedad poco clara, las credenciales heredadas y los tokens almacenados en caché. Estas son precisamente las lagunas que surgen a medida que se expande un registro propio.
Los estándares de seguridad MCP y OAuth siguen evolucionando.
Los estándares para la autorización de agentes aún se están elaborando. En los últimos 12 meses, hemos observado cambios importantes en las directrices:
| Fecha | Actualización de especificaciones/normativa |
|---|---|
| Junio de 2025 | La especificación de autorización del Protocolo de Contexto de Modelo adoptó OAuth 2.1 y prohibió el paso del token de un cliente a las API de etapa final. |
| Septiembre de 2025 | El Grupo de Trabajo OAuth de la IETF adoptó la concesión de autorización de afirmación de identidad, que sirve de base para delegar el acceso de un proveedor de identidades Enterprise a aplicaciones de terceros. |
| Julio de 2026 | La especificación MCP comenzó a exigir la validación del emisor del servidor de autorización y trasladó el registro de clientes a los documentos de metadatos de ID de cliente. |
Además, las directrices de la NSA sobre la seguridad de MCP señalan que el protocolo no especifica la actualización ni la revocación de tokens, por lo que cada equipo que desarrolle su propia capa tendrá que realizar el diseño y proteger esos comportamientos por sí mismo.
Cada cambio en las especificaciones implica que alguien lea las nuevas especificaciones, actualice el código y vuelva a realizar las pruebas.
Por qué los intermediarios de token propios fracasan en la autorización de Enterprise SaaS
Un intermediario local puede almacenar y actualizar tokens que las aplicaciones SaaS ya hayan emitido, pero no puede otorgar acceso por su propia cuenta. Cada aplicación SaaS decide en qué proveedores de identidad confía para avalar a sus usuarios, y los proveedores de aplicaciones generan esa confianza con una lista reducida de proveedores de identidad establecidos. Si un corredor que una empresa gestiona internamente no está en esa lista, cada nueva aplicación implica otra ronda de pantallas de consentimiento por usuario o permisos de administrador manuales.
El acceso entre aplicaciones funciona de manera diferente. Su proveedor de identidad otorga directamente al agente acceso con ámbito definido, por lo que el departamento de TI establece la política una sola vez, los usuarios omiten la pantalla de consentimiento y el control de acceso está centralizado. Un número creciente de aplicaciones SaaS le dan soporte, y Model Context Protocol adoptó el mismo patrón que la autorización gestionada por Enterprise.
Construir o comprar: reorientar la velocidad de la ingeniería hacia las necesidades empresariales clave
El valor de un agente reside en lo que aporta a la empresa: el flujo de trabajo que automatiza, los datos que recopila y las decisiones que agiliza. Cada hora que sus ingenieros dedican a mantener la lógica de actualización de tokens, reconstruir los flujos de consentimiento para la próxima aplicación SaaS o generar informes de revisión de acceso para los auditores es una hora que no dedican a los propios agentes.
La mayoría de los ingenieros de plataformas prefieren desarrollar funcionalidades para agentes en lugar de gestionar un servicio de identidad.
Conserve lo que construyó, compre lo que hay debajo
Las capas de acceso que los equipos crearon para sus primeros agentes resolvieron un problema urgente. La capa de identidad subyacente representa un compromiso diferente. Debe abarcar a todos los agentes de la Enterprise, incluidos aquellos que su equipo nunca haya creado, alcanzar aplicaciones que su organización no controla, mantenerse al día con estándares que aún están en constante cambio y generar evidencia de auditoría en cada ciclo mientras los agentes estén en funcionamiento.
Invertir en una capa de seguridad permite que los ingenieros se centren en los agentes que impulsan el negocio, proporciona a los equipos de seguridad y TI un único lugar para ver y controlar los agentes, y traslada el trabajo continuo de gestionar estándares, integraciones y gobernanza a un equipo cuya única función es la identidad.
Okta® para agentes de IA es una capa de identidad de agente que funciona junto con el proveedor de identidades y las puertas de enlace que ya utiliza. Responde a cuatro preguntas vitales sobre toda su flota de agentes:
- ¿Dónde están mis agentes? Detección y registro
- ¿Qué pueden hacer? Gestión del alcance y Entitlement Management
- ¿Qué están haciendo? Registro de auditoría unificado
- ¿Cómo respondo? Revocación automatizada y aislamiento de amenazas
Guía para el comprador: desglose técnico y marco de revisión de seguridad
Para un análisis completo, incluidas las preguntas que debe formular a cualquier proveedor de identidad en su revisión de seguridad, lea el documento técnico “Identidad de agentes de IA: desarrollar vs. comprar”.
Estos materiales tienen fines informativos generales y no constituyen asesoramiento legal, de privacidad, seguridad, cumplimiento o empresarial.
El contenido puede no reflejar los desarrollos más recientes en seguridad, legal y/o privacidad. Usted es el único responsable de obtener asesoramiento de su propio asesor legal y/o profesional y no debe basarse en estos materiales para decisiones de cumplimiento, implementación o compra.
Okta no ofrece garantías ni declaraciones con respecto a este contenido y no se hace responsable de ninguna pérdida o daño que resulte de la implementación de estas recomendaciones. Puede encontrar información sobre las garantías contractuales que Okta ofrece a sus clientes en okta.com/agreements.
