El 24 de agosto de 2026, Okta lanzó Agent SSO disponible para todos, otorgando a los agentes de IA identidades de primera clase en Universal Directory y reemplazando las claves API estáticas por tokens de corta duración gobernados por políticas. Es la infraestructura de seguridad para agentes más útil lanzada este año, está incluida en los planes básicos de Okta SSO sin coste adicional y los equipos de seguridad deberían activarla. También tiene un requisito previo que la mayoría de las empresas no pueden cumplir actualmente: un agente debe estar registrado antes de que la identidad pueda gobernarlo.
Ese requisito previo es donde las noticias de esta semana chocan con los datos de este mes. El Informe de Riesgos de Uso Empresarial de IA 2026 de Akamai encontró que el 47,11% de las conversaciones empresariales de IA se realizan a través de identidades personales en lugar de cuentas corporativas. Esas conversaciones ni siquiera llegan a un proveedor de identidad. No son agentes esperando recibir tokens, son empleados con pestañas del navegador. Hay dos planos de control diferentes involucrados y esta semana solo uno avanzó.
La identidad de agente finalmente tiene un estándar que vale la pena adoptar
La esencia del lanzamiento de Okta es el estándar subyacente. Agent SSO se basa en Cross App Access, un protocolo neutral que extiende OAuth y ha sido incorporado como la extensión oficial de Autorización Gestionada Empresarial para el Model Context Protocol. Un agente se registra en Universal Directory, los administradores aplican las políticas de acceso que ya usan para empleados y el agente recibe tokens de corta duración cuando necesita actuar en nombre de un usuario. Ric Smith, presidente de Productos y Tecnología de Okta, definió el problema con precisión: otorgar acceso a agentes a sistemas empresariales "no debería requerir sacrificar seguridad o visibilidad."
El patrón de credenciales que esto reemplaza merece las críticas que recibe. Las claves API estáticas son de larga duración, con permisos excesivos, copiadas en archivos de configuración y variables CI, compartidas entre servicios y prácticamente invisibles para los flujos de revocación. Reemplazarlas por tokens de corta duración vinculados a una identidad nombrada reduce genuinamente el radio de impacto. La propia investigación de Okta encontró que solo el 34% de las organizaciones aplican los mismos controles de seguridad a los agentes de IA que a los trabajadores humanos, por lo que la base que se mejora es baja. Que el protocolo sea abierto importa más que el producto: significa que el control sobrevive a un cambio de proveedor de identidad.
¿Qué gobierna realmente Okta Agent SSO?
Agent SSO gobierna las conexiones agente-aplicación compatibles para agentes que implementan Cross App Access. Registra esos agentes en Universal Directory de Okta, aplica las mismas políticas de acceso que los administradores usan para empleados y emite tokens de corta duración con permisos para actuar en nombre de un usuario específico. Reemplazar las claves API estáticas es lo más valioso que hace. Lo que no hace es igualmente importante. Agent SSO no es un mecanismo de descubrimiento: un agente se vuelve visible después de ser registrado o conectado, por lo que no es un inventario de todos los procesos autónomos que se ejecutan en tu entorno. No cubre agentes que no soportan Cross App Access, conexiones agente-agente ni la aplicación en tiempo real de lo que un agente hace una vez autorizado. El descubrimiento, revisiones de certificación, flujos de aprobación y desactivación están en la suscripción separada Okta for AI Agents. Okta es explícito sobre esta división y los compradores deben leerla cuidadosamente.
¿Es Cross App Access lo mismo que MCP?
No, pero ahora están formalmente conectados. El Model Context Protocol es el estándar abierto para cómo una aplicación de IA se conecta a herramientas y fuentes de datos. Define la infraestructura, no el modelo de permisos, por eso las primeras implementaciones de MCP usaban claves API estáticas y tokens personales de larga duración. Cross App Access extiende OAuth para responder a la pregunta de autorización: qué agente, actuando por qué usuario, puede acceder a qué recurso y por cuánto tiempo. Ha sido incorporado como la extensión oficial de Autorización Gestionada Empresarial para MCP, lo que significa que están diseñados para usarse juntos y no como competidores. Para los equipos de seguridad, la lectura práctica es sencilla: si tu organización despliega servidores MCP, Cross App Access es el mecanismo que te permite dejar de entregar credenciales estáticas. Es neutral respecto al proveedor, por lo que adoptarlo no te ata a un único proveedor de identidad.
La gobernanza de identidad comienza en el registro. El descubrimiento la completa.
Todo control basado en identidad hereda la integridad del inventario subyacente. No puedes emitir un token de corta duración a un agente que nunca has visto, aplicar políticas a una conexión que nunca lo solicita ni revocar un acceso que nunca fue concedido a través de ti. Esto no es un fallo de Agent SSO. Es una propiedad estructural que el inicio de sesión único siempre ha tenido.
El precedente es el SaaS en la sombra. Las empresas adoptaron SSO ampliamente en la última década y aún así terminaron con cientos de aplicaciones no federadas, porque SSO gobierna las apps que federas, no las que un equipo contrata con una tarjeta corporativa. La IA en la sombra es el mismo modo de fallo pero mucho más rápido, con una barrera de entrada más baja y sin ningún paso de adquisición. Google Cloud hizo un punto relacionado el mismo día, describiendo a los agentes como "los insiders definitivos" y reportando que el 79% de los líderes tecnológicos nombran la seguridad, gobernanza u operaciones como su mayor barrera para escalar la IA.
¿Por qué la identidad de agente no resuelve la IA en la sombra?
Porque la mayoría de la IA en la sombra no es un agente. Es una persona. Cuando un empleado abre una cuenta personal de ChatGPT en una pestaña del navegador y pega una lista de clientes, no hay agente que registrar, ni token que emitir ni solicitud de conexión que evaluar para un proveedor de identidad. La telemetría de Akamai sitúa el 47,11% de las conversaciones de IA empresarial en exactamente esa categoría. Los controles de identidad actúan en el momento en que algo solicita acceso a un sistema que posees. La IA en la sombra suele hacer lo contrario: extrae datos de un sistema en el que el empleado ya ha iniciado sesión legítimamente y los envía a un lugar que no posees. La decisión de autorización ya ha tenido éxito. La identidad de agente cierra una brecha real y seria para actores máquina, pero opera un nivel por encima del lugar donde ocurre la mayoría de las pérdidas de datos de IA empresarial.
Casi la mitad del uso empresarial de IA nunca llega al plano de identidad
El informe de Akamai se basa en la telemetría de uso real en lugar de respuestas a encuestas, lo que hace que sus cifras valgan más que las estadísticas habituales de adopción. Junto con la cifra del 47,11 %, encontró que más del 14 % de las conversaciones empresariales de IA involucraban suscripciones personales "freemium" de IA vinculadas a direcciones de correo electrónico corporativas. Esa combinación es lo peor de ambos mundos: lleva el dominio de la organización, por lo que parece gobernada en una hoja de cálculo, mientras que la cuenta, sus términos de retención de datos y sus controles de acceso están totalmente fuera del control de la organización.
La exposición también está concentrada. Akamai encontró que el 5% superior de usuarios genera al menos 144 conversaciones cada uno, a menudo superando 18 prompts por conversación, mientras que la mitad de la plantilla apenas participa. O como describió Eshed, vicepresidente de Seguridad Empresarial de Akamai, el cambio claramente:
La IA ya no es solo un impulsor de productividad; es un colega colaborativo con acceso directo a las joyas de la corona corporativas.
La concentración es una buena noticia operativa. Significa que la intervención de mayor valor es un programa dirigido a unos pocos cientos de personas, no una campaña a nivel organizacional que dura un año y molesta a todos.
La capa de extensiones del navegador es el software menos gobernado que instalas
Akamai encontró que casi el 75 % de las extensiones de navegador de IA solicitan permisos altos o críticos, y que el 16,3 % contienen CVE conocidos. Las extensiones se ejecutan dentro de la sesión autenticada. Pueden leer el contenido renderizado de tu CRM, tu cliente de correo y tu sistema de tickets después de que el inicio de sesión único ya haya tenido éxito, que es precisamente el punto en el que una decisión de identidad ha terminado y ha dejado de proteger algo.
Las tres técnicas de ataque nativas de IA que Akamai nombra para 2026 operan en esa capa. El hacking de vibración manipula archivos de instrucciones locales para que un asistente de codificación produzca resultados inseguros o tome acciones no autorizadas. CursorJacking roba claves API mediante una extensión maliciosa. CometJacking usa inyección indirecta de Prompts para extraer datos a través de un navegador de IA. Ninguno se derrota con un token mejor, porque en todos los casos la autorización fue legítima y el abuso ocurrió después.
Gobierna dos planos, no uno
El modelo práctico son dos planos con controles diferentes. El primero es el plano de identidad de máquina: agentes que se conectan a sistemas, gobernados por registro, tokens de corta duración y privilegios mínimos. El SSO para agentes es ahora una buena solución aquí y debería adoptarse. El segundo es la capa de interacción: lo que las personas y agentes realmente envían, prompts, texto pegado, archivos subidos, tráfico de extensiones, independientemente de la identidad, si la hay, que se adjunte. Nada en el plano de identidad inspecciona contenido, y es en el contenido donde ocurre la pérdida de datos.
- Construye un inventario observado del uso de IA, no uno basado en encuestas. El descubrimiento debe ejecutarse en el navegador y en el endpoint, porque las sesiones con identidad personal nunca pasan por tu proveedor de identidad.
- Habilita Agent SSO para cada agente que soporte Cross App Access. Está incluido en los planes básicos de Okta SSO, por lo que el único coste real es el tiempo de configuración.
- Empieza con el 5 % superior de usuarios. La concentración significa que un programa dirigido captura la mayor parte de la exposición con una fracción del esfuerzo.
- Trata las extensiones de navegador de IA como software privilegiado: inventaría, revisa los permisos que solicitan y permite en lista blanca en lugar de bloquear.
- Inspecciona la capa de interacción con DLP contextual que lea el contenido de prompts y cargas, no solo endpoints, correo electrónico y compartición de archivos.
- Cierra la vía de correo electrónico corporativo en suscripciones personales. Parece gobernada y no lo está.
¿Cómo descubres el uso de IA que no tiene identidad corporativa?
Lo observas donde sucede, que es en el navegador y el endpoint. Las sesiones autenticadas con credenciales personales nunca aparecen en los registros del proveedor de identidad, por lo que un inventario basado en IdP es estructuralmente ciego a ellas. Tres señales funcionan realmente: telemetría del navegador que ve qué aplicaciones de IA abre un empleado y qué envía; inspección en el endpoint del tráfico hacia proveedores de IA, incluidas aplicaciones nativas de escritorio que evitan el navegador por completo; y análisis de salida comparado con un catálogo mantenido de dominios de servicios de IA. El catálogo es la parte que los equipos subestiman. Akamai describe una larga cola de aplicaciones no gestionadas que funcionan bajo las pocas plataformas que los equipos de seguridad realmente vigilan, por lo que un control que reconoce solo a los veinte principales proveedores y nada más simplemente recrea la brecha de visibilidad a menor escala. El descubrimiento también debe ser continuo, porque el mercado de herramientas de IA cambia lo suficientemente rápido como para que una auditoría puntual quede obsoleta en un trimestre.
¿Qué debe hacer un CISO en los primeros 30 días?
Empieza con la medición, no con la política. La mayoría de las políticas de uso aceptable de IA fallan porque se escriben contra un patrón de uso imaginado en lugar del real. Dedica las primeras dos semanas a establecer un inventario observado: qué aplicaciones de IA se usan, por quién, con identidades corporativas o personales, y qué categorías de datos se envían. Luego actúa sobre la concentración, porque Akamai encontró que el 5 % superior de usuarios genera al menos 144 conversaciones cada uno. En paralelo, dos cambios cuestan casi nada: habilitar Agent SSO para cada agente que soporte Cross App Access, ya que está incluido en los planes básicos de Okta SSO, y auditar las extensiones de navegador de IA como software privilegiado, dado que casi el 75 % solicita permisos altos o críticos. Solo entonces deberías redactar o revisar la política, porque para ese momento estarás gobernando lo que la gente realmente hace.
Agent SSO es un avance real y el estándar abierto que lo sustenta es la apuesta correcta a largo plazo. Pero gobierna los agentes que has registrado, y los datos de esta semana dicen que casi la mitad del uso empresarial de IA nunca se registra en ningún lado. El plano de identidad avanzó. La capa de interacción no.
Cómo Aona cierra la brecha de la capa de interacción
Aona es una plataforma de Seguridad de IA para la plantilla construida para el plano al que la identidad no puede llegar. Descubre el uso de IA en más de 10.000 herramientas desde el navegador y el endpoint, incluyendo sesiones con cuentas personales que nunca pasan por tu proveedor de identidad, te muestra quiénes son los usuarios de alto volumen y aplica protección de datos en tiempo real sobre lo que realmente se envía, con redacción de archivos para cargas DOCX, Excel y PDF. Descubre cómo Aona detecta y gobierna la IA en la sombra.
