La seguridad de los agentes de IA de Okta apunta a la confusión empresarial
Okta ha identificado un oponente inusual para su impulso en seguridad de agentes de IA: la confusión de los clientes, no otro proveedor de seguridad. El presidente y director de operaciones, Eric Kelleher, defendió esta idea en la Goldman Sachs Communacopia + Technology Conference el 9 de septiembre de 2026.
El argumento refleja un mercado en el que las empresas quieren software autónomo, pero tienen dificultades para definir qué debe protegerse. Un agente puede resumir correos electrónicos, actualizar un registro de ventas, aprobar un reembolso u operar todo un flujo de trabajo financiero. Cada función crea requisitos distintos de permisos, riesgos y rendición de cuentas.
Okta quiere que la identidad se convierta en la capa organizadora de ese desorden. Su marco plantea tres preguntas: ¿Dónde están los agentes?, ¿a qué pueden conectarse? y ¿qué pueden hacer? Microsoft persigue objetivos similares mediante Entra Agent ID y Agent 365, lo que hace que la distribución empresarial sea tan importante como el diseño de seguridad.
Esa competencia cambia el significado del mensaje de Okta. La confusión puede abrir un mercado para un proveedor independiente de identidad, pero también puede ralentizar las compras y favorecer las plataformas integradas. Okta debe convertir una narrativa de seguridad urgente en implementaciones repetibles, adopción medible y estándares que los clientes puedan utilizar entre distintos proveedores.
La seguridad de los agentes de IA de Okta comienza con tres preguntas
La medida inmediata de Okta es reducir un problema de seguridad extenso a la detección de agentes, el control de conexiones y la autorización.
Durante la conferencia de septiembre, Kelleher describió cómo los clientes piden ayuda a Okta después de encontrarse con informes alarmantes sobre agentes autónomos. Estos compradores entienden que los agentes introducen riesgos, pero con frecuencia carecen de un modelo compartido para evaluar ese riesgo.
La respuesta de Okta es su Blueprint for the Secure Agentic Enterprise. La empresa presentó el marco en marzo y puso Okta for AI Agents a disposición general el 30 de abril de 2026. El producto extiende controles de identidad conocidos al software autónomo y semiautónomo.
La primera pregunta, «¿Dónde están mis agentes?», se refiere al inventario y la propiedad. Los empleados pueden activar herramientas sin un proceso formal de implementación, mientras que los desarrolladores pueden crear agentes en numerosas plataformas en la nube. Los equipos de seguridad no pueden gobernar un agente que no pueden identificar.
La capacidad Agent Discovery de Okta está diseñada para revelar esas implementaciones ocultas. Según los detalles de detección de agentes de la empresa, detecta actividad de consentimiento OAuth e identifica conexiones relacionadas con plataformas de agentes no autorizadas.
El consentimiento OAuth concede a una aplicación permiso para acceder a otro servicio sin recibir la contraseña del usuario. Esa comodidad se vuelve arriesgada cuando un empleado autoriza a un agente desconocido a leer correo, archivos, calendarios o registros de clientes.
Okta afirma que las señales del navegador pueden revelar la aplicación cliente, el recurso conectado y los ámbitos de permisos solicitados. Los administradores pueden entonces registrar el agente, asignar un propietario humano y aplicar políticas básicas.
La segunda pregunta, «¿A qué pueden conectarse los agentes?», desplaza la atención del inventario a las rutas de acceso. Un agente puede interactuar con aplicaciones, API, bases de datos, herramientas o servidores Model Context Protocol. MCP es una interfaz estándar que permite a los sistemas de IA acceder a herramientas e información externas.
El plan de Okta incluye una puerta de enlace para mediar esas conexiones, una bóveda de credenciales y gestión de acceso a API. Estos controles pretenden sustituir credenciales amplias y persistentes por decisiones más acotadas basadas en identidad, contexto y riesgo.
La tercera pregunta, «¿Qué pueden hacer los agentes?», alcanza la capa más difícil. Saber que un agente puede entrar en un sistema no revela si puede leer, escribir, transferir, aprobar o eliminar información.
Okta propone registrar llamadas individuales a herramientas y decisiones de autorización. También promueve Universal Logout como un interruptor de desactivación que revoca los tokens de acceso de un agente en todos los sistemas conectados.
Este enfoque importa porque un agente no es simplemente otra cuenta de empleado. Puede ejecutar muchas acciones con rapidez, combinar información entre sistemas y cambiar su comportamiento cuando cambia el contexto circundante.
También difiere de una cuenta de servicio tradicional, que normalmente realiza una tarea automatizada predecible. Un agente de IA puede seleccionar herramientas, generar planes intermedios y actuar mediante permisos delegados por un usuario.
Por tanto, las tres preguntas de Okta crean una estructura útil para las compras. No demuestran que cada control subyacente funcione en todas las plataformas de agentes. Ofrecen a los líderes de seguridad un vocabulario común para decidir qué debe probarse.
Ese vocabulario es la base de la estrategia de la empresa. Okta quiere que las empresas consideren la seguridad de los agentes como una extensión de la gobernanza de identidad, no como una categoría aislada de supervisión de IA.
La confusión está creando demanda y retrasos a la vez
La misma incertidumbre que lleva a los clientes a Okta también puede prolongar las evaluaciones e impedir que la seguridad de los agentes se convierta en un negocio predecible.
Kelleher calificó la confusión como el mayor competidor actual de la empresa en identidad para agentes. Los compradores se enfrentan a afirmaciones contrapuestas de proveedores de seguridad, proveedores de nube, desarrolladores de IA y plataformas de gobernanza. Muchos productos emplean un lenguaje similar mientras protegen capas diferentes.
Un proveedor puede analizar prompts en busca de instrucciones maliciosas. Otro puede detectar identidades de máquina o credenciales expuestas. Un tercero puede controlar el tráfico de red, mientras que un proveedor de identidad determina qué agente puede acceder a una aplicación específica.
Estas funciones pueden complementarse, pero las empresas aún deben establecer responsables. El equipo de seguridad puede controlar las políticas de acceso, mientras que los desarrolladores son propietarios del agente y las unidades de negocio definen las acciones aceptables.
La adquisición se vuelve más difícil cuando una organización no puede responder preguntas básicas sobre su implementación. Una empresa puede saber que sus empleados usan asistentes de IA sin saber qué asistentes poseen permisos duraderos sobre aplicaciones.
Las definiciones de agente también siguen siendo inconsistentes. Algunos sistemas son interfaces de chat que recomiendan acciones. Otros ejecutan flujos de trabajo tras la aprobación humana, mientras que los agentes autónomos pueden actuar sin revisar cada paso.
Esa ambigüedad afecta a la concesión de licencias y a la medición del producto. Kelleher afirmó que Okta actualmente fija el precio de su oferta para agentes como un incremento sobre la tarifa por usuario. Reconoció que el modelo es imperfecto para la arquitectura de agentes, pero lo describió como fácil de adquirir para los clientes.
Según sus declaraciones en la conferencia, la mayoría de las primeras transacciones son acuerdos de un año. Okta espera que ambas partes obtengan mejor información sobre el uso de agentes y los costes operativos antes de las renovaciones.
Este enfoque reduce la fricción inmediata de compra. También revela lo incipiente que sigue siendo el mercado. Una categoría de seguridad madura suele tener unidades más claras, como usuarios, dispositivos, cargas de trabajo, transacciones o volumen de datos protegidos.
La actividad de los agentes puede atravesar todas esas unidades. Un empleado puede utilizar varios agentes, mientras que un agente puede generar trabajadores temporales o realizar miles de llamadas a herramientas. Un modelo por usuario puede desconectarse de la carga de trabajo que se está protegiendo.
La ventaja de Okta es su relación existente con los equipos de identidad empresarial. Kelleher afirmó que más de 20.000 empresas ya confían a Okta identidades humanas y no humanas. Esa base instalada ofrece una vía directa hacia las conversaciones sobre seguridad.
Sin embargo, la confianza no elimina el trabajo de implementación. Los clientes deben detectar agentes, clasificar sus propósitos, identificar propietarios, reducir permisos excesivos y conectar las aplicaciones pertinentes a los puntos de aplicación de políticas.
Los líderes de seguridad también deben decidir qué acciones requieren aprobación humana. Un agente de resumen y un agente de quote-to-cash no deberían recibir controles idénticos, aunque ambos utilicen la misma plataforma de identidad.
El segundo puede afectar a precios, contratos, sistemas de facturación y registros de ingresos. Un error podría convertirse en un incidente financiero o de cumplimiento normativo, en lugar de una respuesta inconveniente.
Esta distinción convierte la confusión en una oportunidad de producto solo cuando Okta puede guiar la implementación. Un plan ayuda a los clientes a formular mejores preguntas, pero las plantillas operativas y las integraciones deben aportar las respuestas.
Ese requisito ejerce presión sobre el modelo de ventas y servicios profesionales de Okta. Los compradores esperarán que la empresa traduzca un marco abstracto de identidad en controles para flujos de trabajo reales.
Los desarrolladores afrontan un reto relacionado. Necesitan patrones de acceso seguros que no requieran reconstruir cada agente para el sistema de identidad de cada cliente. Por eso la estrategia de estándares de Okta ocupa un lugar central en su argumento de producto.
Cross App Access es la apuesta de Okta por una capa de control abierta
Okta apuesta por que un estándar de autorización abierto puede hacer portátil el acceso de los agentes y, al mismo tiempo, preservar a los proveedores de identidad como ejecutores centrales de políticas.
Cross App Access, o XAA, es el método propuesto por Okta para conectar agentes a aplicaciones mediante autorización estandarizada. Amplía conceptos de OAuth y funciona junto con MCP, que proporciona una forma común para que los agentes descubran y llamen herramientas.
La distinción es importante. MCP puede describir una herramienta disponible y facilitar la interacción, pero las empresas aún deben decidir si un agente concreto puede utilizarla. XAA pretende llevar el contexto de identidad y autorización a esa conexión.
Kelleher afirmó que Okta propuso Cross App Access como un estándar abierto en lugar de un formato propietario de Okta. También dijo que había sido aceptado como una extensión de MCP y que estaba atrayendo un amplio interés del sector.
Okta puso Agent SSO a disposición general en agosto de 2026. Agent SSO permite a un administrador registrar un agente como un principal de carga de trabajo, es decir, una identidad no humana gestionada de forma independiente.
Cuando un agente compatible se conecta a una aplicación, Okta puede incorporarlo a Universal Directory junto a otras identidades gobernadas. Los administradores pueden entonces ver la propiedad, las conexiones y las políticas aplicables mediante los procesos de identidad existentes.
El enfoque intenta resolver una debilidad recurrente en las implementaciones de agentes. Muchos agentes iniciales toman prestado el token de acceso de un usuario o dependen de una credencial estática almacenada dentro de un flujo de trabajo.
El acceso prestado puede hacer que la atribución no esté clara. Si un agente modifica un registro usando la identidad de un empleado, un registro de auditoría podría no distinguir la acción del software de una acción humana directa.
Las credenciales estáticas crean otro problema. Pueden permanecer activas más tiempo del necesario y aparecer en archivos de configuración, registros o entornos de desarrollo. Un secreto expuesto puede proporcionar a un atacante acceso persistente.
Una identidad de agente dedicada separa al actor de su patrocinador. El propietario empresarial sigue siendo responsable, pero el sistema de seguridad puede aplicar políticas diferentes al agente y a la persona.
Esa separación admite el principio de mínimo privilegio, que limita una identidad al acceso mínimo necesario para su tarea asignada. También puede admitir tokens de menor duración y una retirada más clara cuando un agente deja de utilizarse.
Okta afirma que Auth0 for AI Agents puede ayudar a los desarrolladores a crear agentes que funcionen con XAA. Esos agentes pueden almacenar credenciales con distintos proveedores de identidad, en lugar de requerir un entorno exclusivo de Okta.
La apertura refuerza el argumento de Okta ante clientes preocupados por la dependencia de una plataforma. Una empresa puede utilizar agentes de Microsoft, Google, Salesforce, equipos de desarrollo internos y proveedores más pequeños dentro del mismo entorno.
Una capa de autorización portátil permitiría que esos agentes encontraran decisiones de acceso coherentes. También podría reducir el trabajo de integración personalizada para los desarrolladores que venden a empresas con distintos sistemas de identidad.
Sin embargo, un estándar publicado no crea interoperabilidad automáticamente. Las aplicaciones deben implementarlo, los marcos de agentes deben transportar el contexto requerido y los proveedores de identidad deben interpretar las solicitudes de forma coherente.
Los equipos de seguridad también deben confiar en los metadatos utilizados en cada decisión. Un agente puede tener una identidad válida y, aun así, recibir instrucciones manipuladas o elegir una acción insegura.
La identidad responde quién o qué solicita acceso. No determina de forma independiente si un plan generado es preciso, ético o está alineado con la intención empresarial.
Por tanto, el mecanismo de Okta es significativo, pero limitado. XAA puede hacer que la autorización sea más explícita y auditable. No puede sustituir las salvaguardas del modelo, la gobernanza de datos, los controles de red ni la validación a nivel de aplicación.
La empresa se beneficia si XAA se convierte en un estándar de conexión neutral. Enfrenta mayor presión si las plataformas de agentes mantienen la aplicación de identidad dentro de sus propios planos de control integrados.
Esa presión ya es visible a través de la expansión de la pila de identidad para agentes de Microsoft.
Microsoft Convierte la Seguridad de Identidad en una Batalla de Distribución
El principal desafío competitivo de Okta es la capacidad de Microsoft para integrar la identidad de los agentes con las aplicaciones, los servicios en la nube y las herramientas de administración que las empresas ya utilizan.
Microsoft Entra Agent ID pasó a estar disponible de forma general en abril de 2026. Proporciona estructuras de identidad, autenticación, autorización, gobernanza y controles de seguridad diseñados para agentes de IA.
Su argumento subyacente se parece mucho al de Okta. Los agentes deben tener propietarios identificables, ciclos de vida gestionados, acceso limitado y actividad auditable. Microsoft también admite OAuth, MCP y protocolos de agente a agente.
La diferencia está en la distribución. Microsoft controla una amplia colección de aplicaciones empresariales, servicios para desarrolladores, infraestructura en la nube, plataformas de datos y productos de seguridad.
Agent 365 actúa como el catálogo unificado y la capa de gestión de la empresa. Entra proporciona la base de identidad que lo sustenta, según la documentación de identidad para agentes de Microsoft.
Microsoft puede conectar una identidad de agente con Conditional Access, Identity Protection, Microsoft Graph y su entorno de gobernanza más amplio. Los clientes que ya operan dentro de esa pila pueden preferir una experiencia administrativa consolidada.
Un ejemplo práctico aparece en la integración de Microsoft con Dataverse. Un agente de desarrollo de ventas puede recibir una identidad dedicada y un rol limitado para leer clientes potenciales, registrar contactos y actualizar registros autorizados.
Los administradores pueden excluir tablas no relacionadas o campos sensibles. Las acciones siguen siendo atribuibles al agente, en lugar de aparecer bajo una cuenta compartida de empleado o aplicación.
Ese escenario demuestra el riesgo estratégico para Okta. Microsoft no necesita vender la identidad de agentes como una categoría independiente cuando puede integrar la gobernanza en la aplicación donde se realiza el trabajo.
La respuesta de Okta es la independencia. Su valor aumenta cuando una empresa utiliza múltiples nubes, creadores de agentes y ecosistemas de software. Una capa de identidad neutral puede ofrecer políticas coherentes a través de esos límites.
Kelleher destacó que la identidad agéntica combina características de las identidades humanas y no humanas. Okta ya gestiona ambas categorías, lo que le da experiencia en gobernanza del ciclo de vida, acceso a aplicaciones y señales de seguridad.
Su catálogo de integraciones también proporciona a la empresa un punto de partida considerable. Okta afirmó en marzo que su red incluía más de 8.200 integraciones, con soporte para agentes que involucraba a Boomi, DataRobot y Google Vertex AI.
Esa amplitud solo importa si las integraciones ofrecen una aplicación efectiva. Una entrada de catálogo que registra un agente es distinta de una que autoriza llamadas individuales a herramientas y permite una revocación rápida.
Microsoft enfrenta la misma prueba dentro de su ecosistema. La identidad centralizada puede describir permisos, pero las aplicaciones deben aplicar correctamente esos permisos durante flujos de trabajo rápidos y de varios pasos.
Otros proveedores de seguridad añaden otra capa de competencia. Las empresas de acceso privilegiado pueden gestionar credenciales sensibles, mientras que los proveedores de seguridad de endpoints y nube pueden analizar el comportamiento alrededor de un agente.
Los especialistas en seguridad de IA pueden centrarse en la inyección de prompts, la selección insegura de herramientas, la filtración de datos y el comportamiento del modelo. Esas amenazas no desaparecen después de que el agente recibe una identidad dedicada.
La arquitectura empresarial probable incluirá varias capas de control. La cuestión disputada es qué plataforma se convierte en el lugar central para la propiedad, las políticas y la investigación.
Okta quiere que ese lugar sea el tejido de seguridad de identidad. Microsoft quiere que Agent 365 y Entra proporcionen un plano de control unificado, especialmente en las aplicaciones de Microsoft.
Los clientes evaluarán esas afirmaciones en entornos mixtos. Una plataforma que gobierna solo sus agentes nativos dejará a los equipos de seguridad con inventarios y políticas fragmentados.
La independencia de Okta ofrece una respuesta creíble a la fragmentación. La profundidad de integración de Microsoft ofrece una respuesta creíble a la complejidad operativa.
Esta es la principal contienda del artículo: una capa de identidad neutral frente a un plano de control integrado de aplicaciones y nube. La confusión ayuda a Okta a iniciar la conversación, pero la interoperabilidad determinará quién la controla.
Los Controles de Identidad No Pueden Juzgar la Intención de un Agente
Okta puede restringir a qué puede acceder un agente, pero unas credenciales válidas no garantizan un razonamiento seguro ni una acción correcta.
Un agente puede autenticarse correctamente y mantenerse dentro de un ámbito de permisos aprobado, pero aun así causar daños. Puede malinterpretar una solicitud, seguir una instrucción maliciosa o combinar acciones permitidas para producir un resultado no deseado.
La inyección de prompts ilustra esta brecha. Un atacante puede colocar instrucciones ocultas o engañosas dentro del contenido que lee un agente. El agente puede tratar esas instrucciones como parte de su tarea.
Los controles de identidad pueden limitar el radio de impacto resultante. No siempre pueden reconocer que el proceso de decisión del agente fue manipulado.
La misma limitación se aplica a la planificación incorrecta. Un agente financiero autorizado podría seleccionar la cuenta equivocada, duplicar una acción o aplicar una regla de aprobación a la transacción incorrecta.
Un interruptor de emergencia se vuelve valioso después de detectar un comportamiento sospechoso. Sin embargo, los agentes autónomos pueden ejecutar muchas acciones antes de que una persona reconozca el patrón y revoque el acceso.
La autorización en tiempo de ejecución intenta reducir esta ventana. En lugar de conceder un acceso permanente y amplio, un sistema evalúa solicitudes individuales utilizando identidad, contexto, riesgo y acción prevista.
La calidad de esa evaluación depende de un contexto fiable. Las políticas deben distinguir la variación normal del comportamiento inseguro sin bloquear flujos de trabajo legítimos.
Las organizaciones también necesitan registros fiables. Registrar las llamadas a herramientas de un agente ayuda a los investigadores a reconstruir los eventos, pero los registros deben conectar al agente, al patrocinador humano, la instrucción, la decisión de autorización y el cambio resultante.
Un registro que solo muestra una llamada API exitosa ofrece una rendición de cuentas limitada. Los equipos de seguridad necesitan saber por qué el agente llamó a la API y qué datos influyeron en su decisión.
Las funciones de registro del sistema y gobernanza de Okta abordan partes de esa cadena. La empresa afirma que las llamadas a herramientas, los intentos de acceso y las decisiones de autorización pueden fluir hacia los sistemas de gestión de eventos e información de seguridad.
Estas capacidades siguen siendo afirmaciones de la empresa hasta que los clientes las prueben en diversos marcos de agentes y aplicaciones. El propio anuncio de Okta también advierte que las funciones no lanzadas pueden llegar tarde o no llegar en absoluto.
La evidencia independiente sigue siendo limitada porque los despliegues empresariales de agentes son recientes. El trabajo académico ha comenzado a examinar la gestión de identidad para sistemas agénticos, pero los estándares de referencia de producción aún están en desarrollo.
Otra preocupación es la calidad de la propiedad. Asignar un patrocinador humano crea responsabilidad sobre el papel, pero esa persona debe comprender los datos, permisos, dependencias y condiciones de retirada del agente.
La propiedad puede volverse ceremonial cuando las organizaciones despliegan agentes más rápido de lo que los gestores pueden revisarlos. Las certificaciones de acceso corren entonces el riesgo de convertirse en otra cola de aprobaciones con contexto insuficiente.
La proliferación de agentes agrava el problema. Un agente principal puede crear subagentes temporales para investigación, análisis o ejecución. La política de seguridad debe determinar si esas identidades temporales heredan permisos.
La herencia amplia es fácil de administrar, pero aumenta la exposición. Exigir una aprobación separada para cada agente de corta duración puede socavar la velocidad que hace atractivos los flujos de trabajo agénticos.
Este es el equilibrio central en la seguridad de agentes de IA de Okta. Las empresas quieren que los agentes operen rápidamente entre sistemas, mientras que los equipos de seguridad necesitan que cada acción permanezca delimitada, atribuible y reversible.
Muy poco control crea un riesgo inaceptable. Demasiada fricción convierte un flujo de trabajo autónomo en una lenta serie de aprobaciones humanas.
Los despliegues más sólidos comenzarán con tareas acotadas y límites explícitos de datos. Un agente de soporte podría clasificar tickets antes de recibir permiso para emitir créditos o modificar registros de clientes.
Los equipos deben probar las rutas de fallo, no solo las demostraciones exitosas. Necesitan evidencia que muestre cómo el sistema gestiona una propiedad vencida, entradas manipuladas, permisos excesivos y servicios de aplicación no disponibles.
Una base de conocimientos con función de búsqueda puede ayudar a los equipos a documentar propietarios, políticas y decisiones sobre incidentes. No sustituye el control de acceso, pero conserva el contexto que los revisores necesitan.
La estrategia de Okta resulta más convincente cuando los clientes pueden conectar las decisiones de identidad con privilegios reducidos y una contención de incidentes más rápida. Los anuncios de productos por sí solos no pueden demostrar ese resultado.
Tres Señales Mostrarán si el Impulso de Okta Está Funcionando
La adopción de estándares, la expansión de clientes y la aplicación entre plataformas determinarán si Okta convierte la confusión en una categoría duradera de seguridad de identidad.
La primera señal es la adopción de Cross App Access más allá de los propios productos de Okta. Los desarrolladores de agentes, proveedores de aplicaciones y proveedores de identidad competidores deben implementar el protocolo para que se convierta en una infraestructura significativa.
Okta afirmó en la conferencia de septiembre que se acercaban anuncios más amplios. El detalle importante no será el número de socios nombrados. Los compradores deben examinar qué acciones pueden autorizar realmente esas integraciones.
El soporte para el registro proporciona inventario. El soporte para una autorización contextual y con alcance definido proporciona control. El soporte para una revocación rápida proporciona contención cuando un agente se desvía de su función prevista.
Un conjunto creciente de integraciones operativas reforzaría el argumento de Okta como plataforma neutral. Una adopción limitada dejaría a XAA como una función útil dentro del entorno de Okta, en lugar de una capa de control para la industria.
La segunda señal es la forma de las renovaciones y expansiones de clientes. Kelleher afirmó que la mayoría de las primeras transacciones agénticas utilizan términos de un año, lo que da a los clientes y a Okta tiempo para comprender el uso.
Esas renovaciones revelarán si las empresas avanzan más allá de la evaluación. Los compradores deben buscar despliegues que gobiernen agentes de producción en varios procesos empresariales, no demostraciones aisladas.
La expansión hacia plataformas de agentes adicionales respaldaría la afirmación de que la identidad ofrece un plano de control común. El crecimiento vinculado solo a proyectos experimentales sugeriría que la confusión sigue siendo una barrera para las ventas.
Los precios ofrecerán otra pista. El incremento por usuario de Okta simplifica las compras iniciales, pero el volumen y la actividad de los agentes no necesariamente siguen el número de empleados.
El modelo podría evolucionar hacia agentes protegidos, conexiones, transacciones o eventos de autorización. Cualquier cambio revelará qué valoran los clientes y cuáles son los costes operativos más importantes.
Un modelo estable y comprensible ayudaría a que la categoría madure. Una tarificación de uso compleja podría reintroducir la incertidumbre que el modelo de Okta pretende eliminar.
La tercera señal es la respuesta competitiva de Microsoft y otros proveedores de identidad. El modelo Agent 365 de Microsoft ya combina un inventario unificado con identidad y gobernanza respaldadas por Entra.
Si Microsoft amplía una gobernanza sencilla para agentes de terceros, la promesa de independencia de Okta se enfrentará a una prueba directa. Si Microsoft sigue siendo más fuerte dentro de su propio entorno, Okta ganará margen en las empresas heterogéneas.
Los clientes deberían comparar la aplicación de controles en Microsoft 365, Google Workspace, Salesforce, plataformas cloud y aplicaciones personalizadas. El ganador necesitará más que una lista central de agentes.
Deberá preservar la identidad del agente entre los límites de las aplicaciones, aplicar el principio de mínimo privilegio, mostrar la propiedad y revocar el acceso de forma coherente. También deberá proporcionar evidencias que los equipos de seguridad puedan utilizar durante investigaciones y auditorías.
El apoyo de los competidores a estándares comunes validaría la tesis más amplia de Okta, aunque reduzca la diferenciación del producto. Los enfoques propietarios convertirían la identidad de los agentes en otro límite de plataforma.
El mensaje de Okta en la conferencia merece atención porque evita tratar la seguridad de los agentes de IA como una única función de detección. La empresa está planteando el problema en torno a la responsabilidad y el acceso durante todo el ciclo de vida de un agente.
Este enfoque coincide con el desafío operativo. Una empresa necesita saber quién creó un agente, por qué existe, a qué recursos puede acceder y cómo detenerlo.
Sin embargo, la identidad es un plano de control entre varios. Las salvaguardas del modelo, la validación de aplicaciones, la monitorización de red, la gobernanza de datos y la revisión humana siguen siendo necesarias.
Por tanto, los compradores de seguridad deberían tratar el modelo de Okta como un marco de pruebas. Pueden pedir a cada proveedor que demuestre descubrimiento, autorización, propiedad, registro y revocación en un flujo de trabajo real.
La mejor prueba procederá de un despliegue de producción deliberadamente limitado. Los equipos pueden empezar con un agente que lea información restringida y proponga acciones para la aprobación humana.
Después podrán medir las solicitudes de permisos excesivos, las denegaciones de políticas, el tiempo de investigación y la precisión de la retirada. Esos resultados revelan más que una demostración autónoma pulida.
La seguridad de los agentes de IA de Okta es, en última instancia, una apuesta por que las empresas no gestionarán el software autónomo mediante credenciales dispersas y controles aislados. El mercado avanza hacia identidades dedicadas, propiedad explícita y autorización continua.
La cuestión sin resolver es quién proporcionará esa capa en entornos mixtos. Primero, siga las integraciones de XAA; después, las renovaciones en producción; y, en tercer lugar, el alcance de Microsoft con terceros.
Si Okta avanza en los tres frentes, la confusión se convertirá en una oportunidad duradera para la identidad. Si la adopción sigue fragmentada, las plataformas integradas conservarán la ventaja.
Para los equipos empresariales, el siguiente paso es práctico: seleccione un agente, trace cada conexión y documente cada acción permitida. Después, pregúntese si su sistema de identidad actual puede ver, restringir, auditar y revocar ese agente sin trabajo personalizado.
