La apuesta de Okta por la identidad de IA depende de la economía de MCP

Okta ha llegado a un momento de Google News con un impulso concreto en identidad para IA, pese a la incertidumbre sobre si las empresas pagarán por otra capa de control. La empresa está posicionando la infraestructura de identidad en torno a los agentes de IA, las conexiones de Model Context Protocol y el acceso delegado entre aplicaciones empresariales.

La estrategia lleva a Okta más allá de proteger a los empleados al iniciar sesión. Pide a las empresas registrar agentes, limitar sus permisos, gobernar las conexiones posteriores y preservar la identidad de la persona detrás de cada acción delegada.

Esto sitúa a Okta en una competencia más amplia por controlar la actividad de IA empresarial. Microsoft, las plataformas cloud, los proveedores de seguridad y los proveedores de aplicaciones cuentan con posiciones creíbles. La ventaja de Okta es la neutralidad, pero su reto es demostrar que un plano de identidad independiente reduce el riesgo y los costes operativos.

La afirmación principal merece un tratamiento cuidadoso. MCP puede estandarizar cómo los agentes acceden a herramientas, pero el protocolo no reduce automáticamente el uso de modelos ni el gasto en infraestructura. El control de costes depende del descubrimiento de herramientas, el filtrado de respuestas, el alcance de los permisos, la observabilidad y la arquitectura que rodea a cada servidor.

Por tanto, Okta tiene dos oportunidades conectadas. Puede proteger el acceso de los agentes y ayudar a las empresas a evitar que herramientas, datos y credenciales innecesarios entren en cada flujo de trabajo. La primera oportunidad es visible en sus productos. La segunda sigue siendo un resultado empresarial que los clientes deben validar.

Okta está convirtiendo los agentes de IA en identidades gobernadas

El movimiento central de Okta consiste en tratar a cada agente empresarial como una identidad con sus propios permisos, conexiones y ciclo de vida.

Okta for AI Agents proporciona un plano de control para descubrir y registrar agentes. También conecta esos agentes con aplicaciones aprobadas, API, credenciales y servidores MCP. Un servidor MCP es un servicio que expone herramientas o datos a una aplicación de IA a través de una interfaz estándar.

Esta arquitectura aborda un problema creado por el software autónomo. Un empleado humano suele entrar en una aplicación mediante un proveedor de identidad reconocido. En cambio, un agente puede moverse entre API, cuentas de servicio, secretos almacenados y tokens delegados por usuarios.

Estas rutas suelen generar registros fragmentados. Un sistema ve al usuario humano, otro ve una credencial de aplicación y un tercero registra únicamente la cuenta de servicio. Los equipos de seguridad pueden tener dificultades para reconstruir quién inició una acción y por qué fue permitida.

Okta quiere que el agente se convierta en una identidad de primera clase. Los administradores pueden entonces asociarlo a un propietario, definir los recursos que puede utilizar y suspender su acceso cuando cambien las condiciones.

Los controles de agentes de IA de la empresa describen integraciones con entornos como Salesforce, AWS, Microsoft y ServiceNow. Okta afirma que los agentes pueden importarse a Universal Directory, proporcionando a los administradores un inventario centralizado.

Ese inventario importa porque las empresas rara vez despliegan agentes mediante un único programa coordinado. Los desarrolladores crean asistentes internos, los equipos de negocio adoptan agentes de proveedores y las aplicaciones SaaS añaden funciones autónomas. La colección resultante puede incluir tanto agentes aprobados como agentes en la sombra que los equipos de seguridad nunca revisaron.

El registro por sí solo no resuelve el problema. Un inventario adquiere valor cuando impulsa políticas, revisiones de acceso, supervisión y revocación. De lo contrario, se convierte en otra lista de activos que queda desactualizada.

El modelo de conexión de recursos de Okta proporciona esa vía de aplicación. Los administradores pueden definir a qué recursos posteriores puede acceder un agente. También pueden elegir entre tokens delegados, acceso de terceros intermediado y credenciales estáticas gestionadas.

La empresa admite servidores MCP como un tipo de recurso. La documentación de Okta indica que su plataforma gestiona el registro de servidores, la configuración, las comprobaciones del ciclo de vida y las relaciones de intercambio de tokens. Su arquitectura de servidores MCP también distingue entre la autorización controlada por Okta y los servidores de autorización externos.

El servidor MCP de código abierto de Okta adopta un enfoque relacionado para la automatización administrativa. Traduce solicitudes en lenguaje natural en operaciones estructuradas de la API de Okta, al tiempo que utiliza ámbitos de OAuth para restringir las herramientas disponibles.

El servidor filtra las herramientas según los ámbitos concedidos. También vuelve a comprobar los ámbitos antes de realizar una llamada a la API. Esa segunda comprobación importa cuando las credenciales cambian durante una sesión o un token renovado incluye menos permisos.

Un ejemplo práctico muestra la diferencia. Un asistente de TI podría necesitar enumerar cuentas bloqueadas, pero no debería desactivar usuarios. La carga de herramientas basada en ámbitos puede ocultar la operación de desactivación en lugar de pedirle al modelo que recuerde esa política.

Este modelo reduce el número de opciones peligrosas presentadas al agente. También desplaza la autorización fuera del razonamiento del modelo, donde una inyección de prompts o un plan equivocado no puede simplemente anularla.

El cambio inmediato no es que Okta haya inventado la autenticación de agentes. OAuth, las identidades de servicio y los controles de acceso privilegiado ya existen. Okta está empaquetando esos elementos en torno al agente como objeto gobernado, en vez de tratar cada conexión como una integración aislada.

Ese empaquetado da a Okta una narrativa de producto oportuna. Aún no establece cuánto adoptarán los clientes, consolidarán o ampliarán su gasto en torno a ella.

Por qué la historia de Google News trata realmente del control empresarial

El ángulo más profundo de Google News no es otro lanzamiento de funciones de IA, sino una competencia por determinar dónde residirá la política de agentes empresariales.

Los agentes de IA aumentan el número de acciones iniciadas por máquinas dentro de las aplicaciones. Pueden recuperar registros, preparar documentos, cambiar configuraciones, crear cuentas o activar flujos de trabajo. Cada acción crea una cuestión de autorización antes de crear una cuestión de inteligencia.

Importa quién solicitó la acción. También importa la identidad propia del agente. Importa la aplicación de destino. También importan la operación solicitada y los permisos existentes del usuario humano.

El inicio de sesión único tradicional a menudo responde solo a la primera pregunta: quién inició sesión. Un flujo de trabajo autónomo necesita autorización continua después del inicio de sesión, especialmente cuando el agente cruza los límites entre aplicaciones.

Cross App Access de Okta, o XAA, está diseñado para esa situación. Permite que un agente lleve contexto de identidad y autorización a una aplicación posterior mediante un intercambio de tokens controlado.

En lugar de entregar al agente un secreto reutilizable, el proveedor de identidad evalúa la solicitud. Después puede emitir un token para un recurso concreto y un ámbito aprobado.

Okta presentó inicialmente XAA como un protocolo abierto para conexiones de agente a aplicación. Su plan original de Cross App Access identificaba una debilidad conocida: los usuarios a menudo se autentican y otorgan consentimiento por separado para cada integración.

Ese enfoque se vuelve más difícil de gobernar a medida que los agentes se conectan a más servicios. Las pantallas de consentimiento distribuyen las decisiones entre empleados, mientras que las credenciales estáticas pueden sobrevivir a las personas o proyectos que las crearon.

XAA traslada más autoridad hacia el proveedor de identidad y el administrador empresarial. Las políticas pueden configurarse antes de que un agente solicite acceso, y la aplicación posterior puede validar la declaración de identidad resultante.

El modelo ha obtenido apoyo práctico a través del trabajo de Enterprise-Managed Authorization de Anthropic. Una guía beta de Okta de junio de 2026 describe a Claude como la aplicación solicitante, a Okta como el proveedor de identidad y a los servicios MCP participantes como aplicaciones de recursos.

El flujo documentado por Okta utiliza una concesión de autorización Identity Assertion JWT, abreviada como ID-JAG. Claude envía el token de Okta del usuario autenticado y recibe una declaración independiente para la conexión solicitada.

Ese mecanismo conserva más contexto que una credencial de servicio genérica. El recurso puede saber qué empresa, agente y usuario participaron en la solicitud.

Desde entonces, una versión estable de Enterprise-Managed Authorization ha entrado en el ecosistema MCP. La extensión de autorización permite a las organizaciones aprovisionar conexiones de servidor compatibles mediante un proveedor de identidad, en lugar de hacer que los usuarios completen flujos OAuth por separado.

Este desarrollo da más peso a la estrategia de Okta. Una función propietaria puede tener dificultades para atraer un ecosistema. Un protocolo compatible con clientes de agentes y proveedores de recursos tiene más posibilidades de convertirse en infraestructura.

Okta anunció un grupo ampliado de socios de XAA en junio de 2026. La lista incluía empresas que trabajan en plataformas de agentes, aplicaciones empresariales e infraestructura MCP. Esas relaciones solo importan cuando generan conexiones de producción, pero demuestran que Okta no está construyendo el mecanismo de forma aislada.

La presión recae sobre varios grupos. Los proveedores de aplicaciones deben decidir si aceptan declaraciones de identidad gestionadas por la empresa. Las plataformas de IA deben preservar la identidad delegada entre llamadas a herramientas. Los equipos de seguridad deben decidir si su proveedor de identidad existente debe gobernar a los agentes.

Microsoft presenta el desafío estructural más claro. Controla una importante plataforma de identidad empresarial, aplicaciones de productividad, servicios cloud y un entorno de agentes en expansión. Esa integración puede convertir a Microsoft Entra en la opción predeterminada para los clientes que ya están concentrados en su ecosistema.

Las plataformas cloud también gestionan identidades de cargas de trabajo y permisos de servicio. Los proveedores SaaS pueden aplicar autorización dentro de sus propias aplicaciones. Las puertas de enlace de API y los productos de seguridad de IA especializados pueden inspeccionar el tráfico de agentes más cerca de la ejecución.

El contraargumento de Okta es la independencia. Un plano de identidad neutral puede gobernar agentes creados en una nube mientras acceden a aplicaciones propiedad de varios otros proveedores. Eso resulta útil cuando ninguna plataforma única controla el flujo de trabajo completo.

La neutralidad pierde valor si las integraciones siguen siendo superficiales. Las empresas no adoptarán un plano de control simplemente porque se sitúe por encima de productos competidores. Necesitan una aplicación de políticas coherente, registros de auditoría utilizables y compatibilidad con las aplicaciones que sus agentes realmente llaman.

Los controles de costes de MCP comienzan con menos herramientas y respuestas más pequeñas

La política de identidad puede influir en los costes de MCP, pero la autorización por sí sola no hace que un agente sea económico.

MCP crea una forma común para que los modelos descubran herramientas y las invoquen. Esa coherencia reduce el trabajo de integración personalizada. También puede introducir nuevos costes de tokens, latencia y observabilidad cuando los despliegues exponen demasiadas herramientas o devuelven datos excesivos.

Un modelo puede recibir nombres de herramientas, descripciones, parámetros y esquemas de respuesta como contexto. Los catálogos de herramientas más grandes consumen más tokens de entrada y dificultan la selección de herramientas. Los resultados extensos pueden consumir aún más contexto después de una llamada.

Aquí es donde la seguridad MCP de Okta y el control de costes pueden converger. Un agente con permisos limitados debería ver solo las herramientas necesarias para su función. Eliminar herramientas no autorizadas reduce tanto la superficie de ataque como la sobrecarga de contexto.

El servidor de código abierto de Okta registra dinámicamente herramientas en función de los ámbitos de OAuth concedidos a la aplicación administrativa. Si la credencial no puede gestionar usuarios, las herramientas correspondientes no necesitan aparecer en el conjunto disponible para el modelo.

Esa es una propiedad arquitectónica útil. Hace que el entorno de trabajo del modelo refleje la política externa. No depende de un prompt de sistema que diga: «No uses herramientas peligrosas».

Pensemos en un agente de soporte que investiga fallos de inicio de sesión. Puede necesitar recuperar usuarios, inspeccionar registros del sistema y revisar factores de autenticación. No necesita acceso a la configuración de marca, la eliminación de grupos ni la eliminación de aplicaciones.

Un servidor con un alcance limitado puede retener esas funciones no relacionadas. El modelo procesa un catálogo más reducido y los administradores obtienen un límite más claro en torno a su propósito.

El diseño de las respuestas es igual de importante. Una solicitud para enumerar todos los usuarios podría devolver miles de registros. Enviar todo el resultado a través de un modelo genera costes de tokens, latencia y una exposición innecesaria de datos.

El filtrado del lado del servidor puede devolver únicamente los usuarios bloqueados o un recuento agrupado por política. La ejecución de código cerca de los datos también puede calcular la respuesta antes de presentar un resultado compacto al modelo.

La investigación independiente refuerza la preocupación más amplia sobre los costes. Un estudio de 2026 sobre tareas de programación con agentes concluyó que los tokens de entrada impulsaban gran parte del gasto, mientras que las ejecuciones repetidas podían variar considerablemente en el uso total. Los autores también observaron que un mayor consumo de tokens no producía de forma fiable una mayor precisión.

Estos hallazgos no miden los productos de Okta. Muestran por qué los compradores deberían exigir evidencia a nivel de carga de trabajo en lugar de asumir que la conectividad estandarizada de herramientas reduce el gasto.

Por tanto, los controles de costes de MCP requieren varias capas:

• La política de identidad limita qué agente puede acceder a cada servidor.

• Los ámbitos de OAuth limitan qué operaciones expone el servidor.

• El descubrimiento de herramientas evita cargar cada esquema en cada solicitud.

• El filtrado del lado del servidor reduce el tamaño de los datos devueltos.

• La telemetría de uso atribuye el consumo del modelo y de las herramientas a un agente o equipo.

• Los presupuestos y límites de frecuencia detienen los bucles antes de que generen actividad descontrolada.

• La aprobación humana interrumpe operaciones destructivas o inusualmente costosas.

Okta aborda directamente las dos primeras capas y contribuye a la capa final de aprobación. Las notas de lanzamiento de MCP de 2026 describen compatibilidad con la API MCP Elicitation, que puede exigir supervisión humana antes de acciones destructivas.

La empresa no controla la economía completa. Los proveedores de modelos determinan el comportamiento de los tokens. Las plataformas de agentes deciden cómo entran las herramientas en el contexto. Los desarrolladores de servidores MCP determinan el tamaño de las respuestas. Los equipos empresariales configuran los ámbitos y las políticas de aprobación.

Eso convierte los «controles de costes de MCP» en un problema compartido de sistemas, no en una única función de Okta. Okta puede mejorar las condiciones de partida al garantizar que los agentes reciban solo acceso autorizado. No puede garantizar un razonamiento eficiente una vez concedido el acceso.

La seguridad y el coste también pueden divergir. Un agente con autorizaciones estrictas puede seguir llamando repetidamente a una herramienta aprobada porque su plan falla. Un flujo de trabajo barato puede seguir siendo inseguro si utiliza una credencial con privilegios excesivos.

Las empresas deberían medir ambas dimensiones. Las métricas de seguridad incluyen solicitudes denegadas, permisos sin usar, agentes obsoletos, antigüedad de las credenciales y acciones privilegiadas. Las métricas de coste incluyen tokens de entrada, tokens de salida, llamadas a herramientas, reintentos, tamaños de respuesta y latencia.

El resultado más creíble para un cliente conectaría ambas dimensiones. Por ejemplo, reducir el conjunto de herramientas autorizadas de un agente podría disminuir los tokens de esquema y, al mismo tiempo, reducir el número de rutas privilegiadas disponibles para un atacante.

Hasta que los clientes publiquen esa evidencia, el argumento de costes sigue siendo una consecuencia plausible del principio de mínimo privilegio. No debería presentarse como un ahorro verificado producido por Okta.

Los agentes de IA de Okta aún enfrentan una brecha de adopción y evidencia

Okta ha construido un modelo de control coherente, pero el caso comercial depende de la adopción en producción más allá de las demostraciones y los anuncios de socios.

La primera incertidumbre es la urgencia de los clientes. Las empresas claramente se preocupan por el acceso de los agentes, pero muchas implementaciones siguen siendo pilotos limitados. Una empresa con unos pocos asistentes internos puede gestionar los permisos mediante los roles existentes en la nube y la configuración de OAuth de las aplicaciones.

Okta se vuelve más valiosa cuando los agentes se multiplican entre departamentos y proveedores. En ese punto, los inventarios, credenciales y procesos de aprobación separados crean fricción operativa.

La empresa debe demostrar que los clientes están alcanzando ese umbral. Los agentes registrados, las conexiones de recursos activas, los servidores MCP gobernados y las evaluaciones de políticas recurrentes revelarían más que declaraciones generales de interés.

La segunda incertidumbre es la cobertura del ecosistema. XAA funciona mejor cuando las aplicaciones solicitantes, los proveedores de identidad y las aplicaciones de recursos implementan flujos compatibles. Un participante ausente puede obligar a que un flujo de trabajo vuelva a un secreto estático o a un proceso de consentimiento independiente.

La expansión de socios de Okta es alentadora, especialmente en torno a Claude y los proveedores de MCP participantes. Sin embargo, la documentación beta también revela limitaciones de implementación. Los administradores deben configurar correctamente las aplicaciones, credenciales, detalles del emisor, llamadores delegados y conexiones de recursos.

Esa configuración ofrece control porque es explícita. También genera trabajo administrativo. Los compradores compararán esa carga con configuraciones de gateway más sencillas o controles nativos ya incluidos en sus plataformas de nube y aplicaciones.

La tercera incertidumbre es la madurez del protocolo. MCP ha evolucionado rápidamente, y el soporte de autorización ha cambiado a su lado. Las empresas pueden encontrarse con servidores que utilizan supuestos de OAuth distintos, metadatos incompletos o comportamientos de registro incompatibles.

La documentación de ayuda actual de Okta indica que los clientes MCP deben estar preregistrados y utilizar un cliente confidencial de código de autorización. Dynamic Client Registration no es compatible con ese flujo de trabajo.

El preregistro puede reforzar la supervisión empresarial. También puede ralentizar las integraciones con herramientas diseñadas en torno a la incorporación automática de clientes. Okta debe equilibrar la gobernanza central con la experiencia de desarrollador que ayudó a MCP a expandirse.

La cuarta cuestión es la delegación humana. Un agente puede autenticarse correctamente y, aun así, actuar más allá de la intención del usuario. Un token válido demuestra que una solicitud cumplió un flujo de autorización. No demuestra que el modelo interpretara correctamente la instrucción.

La inyección de prompts crea una brecha relacionada. El contenido malicioso puede influir en un agente después de la autenticación. El principio de mínimo privilegio limita el daño posible, pero no elimina la vulnerabilidad a nivel de modelo.

La autorización continua puede ayudar. La capa de identidad puede evaluar el ámbito, el contexto y el riesgo antes de emitir un token. Las aplicaciones pueden exigir una verificación más sólida para acciones sensibles. La aprobación humana puede detener operaciones destructivas.

Estos controles reducen la exposición, en lugar de eliminarla. Okta debería evaluarse como una capa de un diseño más amplio de seguridad para agentes que incluya defensas del modelo, controles de datos, supervisión en tiempo de ejecución y autorización de aplicaciones.

La quinta incertidumbre se refiere a la respuesta competitiva. Microsoft puede conectar identidad, datos de productividad, Copilot, Azure y telemetría de seguridad. Google puede combinar Workspace, identidad en la nube y servicios de desarrollo de agentes. Cloudflare, las empresas de gestión de API y las startups de seguridad pueden gobernar el tráfico de MCP en el gateway.

La principal defensa de Okta es la consistencia multiplataforma. Las empresas con nubes mixtas y carteras de SaaS pueden preferir una capa de políticas independiente. Los clientes concentrados en una única plataforma pueden ver menos motivos para añadirla.

La posición financiera de Okta le da margen para perseguir la oportunidad, pero los inversores deberían separar el rendimiento actual del negocio de los futuros ingresos de IA. La empresa comunicó sus resultados fiscales de 2026 en marzo de 2026, pero su comunicado público no desglosó ingresos materiales procedentes de productos de agentes de IA.

Los resultados fiscales de 2026 describieron la misión más amplia de Okta como proteger identidades de IA, máquinas y personas. Ese lenguaje confirma una prioridad estratégica, no la adopción por clientes ni la contribución del producto.

Una tesis de inversión defendible exige más que un gran mercado potencial. Requiere evidencia de que Okta puede vincular la gobernanza de agentes de IA a las renovaciones, ampliar el valor de los contratos y defender su papel frente a los servicios de identidad integrados.

La atención de Google News puede amplificar la narrativa. No puede sustituir al uso divulgado, las referencias de clientes ni los resultados comerciales duraderos.

Qué vigilar tras el momento de Okta en Google News

Tres señales mostrarán si la estrategia de identidad para agentes de Okta se está convirtiendo en infraestructura o sigue siendo una narrativa de producto atractiva.

La primera señal es la adopción en producción en torno a XAA y Enterprise-Managed Authorization. Los logotipos de socios son útiles durante el desarrollo de estándares, pero las integraciones en vivo determinan si los administradores pueden gobernar flujos de trabajo reales.

Observe si los principales proveedores de SaaS habilitan acceso MCP respaldado por XAA en productos de disponibilidad general. También observe si los clientes empresariales describen implementaciones que abarcan varios proveedores en lugar de una única demostración controlada.

Un amplio soporte en producción reforzaría el argumento de neutralidad de Okta. Un soporte limitado dejaría a los clientes gestionando excepciones, credenciales estáticas y flujos de consentimiento separados junto al nuevo sistema.

La segunda señal es el uso medible del producto. Con el tiempo, Okta debería proporcionar indicadores operativos como agentes registrados, conexiones activas, servidores MCP protegidos o clientes que utilizan la gobernanza de agentes de IA.

La divulgación de ingresos sería aún más informativa. Compradores e inversores necesitan saber si Okta for AI Agents impulsa nuevas compras, amplía implementaciones existentes o protege principalmente la plataforma central frente a la presión competitiva.

Los estudios de caso de clientes deberían incluir resultados de seguridad. Menos privilegios permanentes, desactivación más rápida de agentes, menos credenciales no gestionadas o mejor cobertura de auditoría demostrarían valor sin depender de una demanda generalizada de IA.

Los resultados de costes requieren su propia evidencia. Las mediciones útiles incluyen catálogos de herramientas más reducidos, menor consumo de tokens de entrada, menos llamadas repetidas y menor esfuerzo administrativo. Okta debería distinguir esos resultados medidos de los beneficios teóricos.

La tercera señal es cómo responden los competidores y los organismos de estándares. Microsoft, los proveedores de nube, las plataformas de agentes y los proveedores de gateways MCP pueden adoptar patrones similares de intercambio de identidad o promover alternativas.

Si convergen en una autorización empresarial interoperable, Okta podrá competir como una implementación neutral dentro de un mercado más amplio. Si cada plataforma construye un sistema de control cerrado, el alcance de clientes y la distribución pasarán a ser decisivos.

La convergencia de estándares no garantizaría el éxito comercial de Okta. Validaría la necesidad subyacente de una identidad de agente delegada. La fragmentación aumentaría los costes de integración y debilitaría la promesa de un plano de control unificado.

Los equipos de seguridad que evalúen la seguridad MCP de Okta deberían empezar con un flujo de trabajo limitado. Elijan un agente que acceda a una aplicación sensible en nombre de usuarios conocidos. Definan un conjunto limitado de herramientas, exijan ámbitos explícitos y midan cada solicitud.

Registren el consumo de tokens antes y después del filtrado de herramientas basado en ámbitos. Comparen los tamaños de respuesta cuando el servidor filtra los datos localmente. Prueben si el acceso desaparece cuando se suspende el usuario, el agente o la conexión.

Después, pongan a prueba el sistema. Introduzcan una solicitud fuera del rol del agente, revoquen un ámbito durante una sesión activa y exijan aprobación para una operación destructiva. El resultado revelará más que una demostración pulida.

Los trabajadores del conocimiento también tienen interés en el resultado. Los agentes se desplazan cada vez más entre documentos, calendarios, mensajes y sistemas internos de conocimiento. Una identidad delegada clara puede ayudar a los usuarios a entender qué asistente accedió a qué recurso y bajo la autoridad de quién.

Los lectores que siguen esta historia a través de Google News deberían distinguir entre tres afirmaciones. Okta ha lanzado una infraestructura de identidad relevante para agentes. La gobernanza de MCP puede reducir el acceso y el contexto innecesarios. Ninguno de estos hechos garantiza menores costos operativos ni nuevos ingresos significativos.

La oportunidad estratégica es real porque la conectividad de los agentes se está convirtiendo en un problema de autorización. Okta ahora debe demostrar que las empresas desean un plano de control independiente, que los proveedores respaldarán sus flujos y que un acceso disciplinado genera resultados medibles.

Esa prueba aparecerá en los despliegues, las métricas de uso y los resultados de los clientes, no en el próximo titular. La cuestión es si Okta puede convertir su visibilidad en Google News en la capa de identidad predeterminada para los agentes que operan en plataformas empresariales rivales.