Asegurando la Enterprise agentic: el plan en la práctica

Los agentes son poderosos. También son una superficie de ataque.

Un agente de IA es tan útil como los sistemas a los que le permites acceder. Los usuarios útiles están aprobando reembolsos, registrando transacciones y modificando los registros de los clientes en los sistemas que proteges con mayor cuidado, a los que se accede a través de conectores SaaS, servidores Model Context Protocol (MCP) y API. 

Para actuar, un agente debe contar con la confianza de sistemas que nunca ha conocido, en nombre de otra persona y sin que nadie supervise el momento en que toma una decisión. Un solo agente bajo supervisión es fácil de entender y controlar (Figura 1). 

El problema comienza cuando los agentes pasan de los programas piloto a la producción y la adopción se extiende por toda la empresa. Una conexión supervisada se convierte en miles de conexiones no supervisadas. La autoridad otorgada a cada uno se establece de una vez y de forma general, lo que resulta en un caos de acceso (Figura 2).

Un agente. Muchas herramientas y recursos.

Cada enlace llega a los datos de sus clientes, su IP y los sistemas operativos que ejecutan su negocio.

Usuarios × agentes × conversaciones × herramientas = caos de acceso

Cada enlace es una superficie de ataque. La autorización debe regir cada una, en cada llamada, a la velocidad de la máquina.

Ese caos parece una amenaza para la seguridad, pero no llega como suele ocurrir. Los agentes no entran a la fuerza. Se crean, conectan o se conceden acceso, y cuando el tráfico llega a un firewall, el agente ya está dentro.

La verdadera pregunta es qué pasará después: 

• ¿De qué agente se trata?
• ¿Quién lo autorizó?
• ¿Qué puede alcanzar? 
• ¿Qué puede hacer para esta tarea? 
• ¿Cómo revocamos su acceso?

Estas son preguntas de identidad y autorización, y aunque los alcances generales pueden determinarse por adelantado, no se pueden responder de antemano; las decisiones por tarea deben tomarse en tiempo de ejecución. La autoridad de un agente debe determinarse en el momento de la acción, basándose tanto en las identidades humanas como en las del agente. Esto garantiza que la autorización tenga un alcance preciso para la tarea y que la persona responsable esté vinculada a cada solicitud. Este principio fundamental sirve como base para toda la arquitectura.

El plan de seguridad existe. El presupuesto no lo permite.

El desplazamiento ya es visible en el borde de ataque. Uber publicó recientemente un relato detallado de cómo dio a los agentes una identidad real, centrar en la identidad criptográfica del agente y en un intercambio de tokens por salto que lleva la cadena de actores desde el humano hasta la herramienta. Es una validación estable de que el problema es real y que la arquitectura es conocible. También hizo falta una organización de ingeniería que la mayoría de las compañías nunca tendrán, construida y operada internamente. 

La lección que vale la pena extraer es sobre los estándares: una capa de identidad para agentes solo se sostiene si viaja a través de los límites del proveedor y de SaaS que los agentes cruzan constantemente, lo que significa que debe construirse utilizando estándares consistentes que cada parte implemente de la misma manera y entregarse como una capa en lugar de diseñarse empresa por empresa. Eso es Okta para agentes de IA.

Cómo Okta protege la Enterprise agentic

Okta for IA Agents convierte ese principio en una capa operativa: identidad verificable para cada agente, autorización decidida en el momento de la acción y el humano responsable presente en toda la cadena. El resto de esta publicación describe la arquitectura utilizando una Enterprise como ejemplo.

Una implementación empresarial agentic típica 

Para que este hipotético sea concreto, tomemos como ejemplo a Streamward Inc., un conjunto de las empresas con las que trabajamos. Un usuario realiza una solicitud a través de un asistente de chat, y un orquestador de agente maestro analiza la intención y delega subtareas a través de la malla por capacidad empresarial (Figura 3). Para acceder a sistemas de etapa final, API propietarias y servicios de terceros, los agentes utilizan una combinación de tipos de recursos en tiempo de ejecución: servidores MCP, extremos REST regidos por especificaciones OpenAPI y data warehouses nativos en la nube.

Ejemplo de arquitectura de malla multiagente

• Salesforce Agentforce: Se encarga del análisis del pipeline de CRM, la puntuación de clientes potenciales y la búsqueda de cuentas.
  • Servidor MCP conectado: coteja los ID de cuenta de Salesforce con la facturación en vivo a través de un servidor ERP MCP empresarial, llamando a get_customer_payment_history.
• Amazon Bedrock AgentCore: Ejecuta la generación aumentada de recuperación (RAG) sobre el conocimiento corporativo.
  • Servidor MCP conectado: se conecta a una base de datos de vectores AWS Aurora PostgreSQL a través de MCP para ejecutar búsquedas semánticas, llamando a query_knowledge_base y fetch_unstructured_contract_pdf.
• Google Vertex IA: entornos de ejecución código bajo que impulsan flujos de trabajo autónomos del cliente.
  • Puerta de enlace OpenAPI conectada: enruta llamadas a través de una puerta de enlace de Workday y ServiceNow compatible con OpenAPI, llamando a read_latest_incident_tickets y activando create_workday_expense_claim.

Las cuatro brechas de seguridad comunes en la implementación

Ahora trazaremos una solicitud ordinaria a través de esta malla para resaltar las brechas de seguridad comunes: una búsqueda en la base de conocimientos corporativa que debe llegar a la base de datos. Sin una estructura de identidad central, falla de cuatro maneras, como se ve en el token que lleva el agente (Figura 4). La falta está en lo que le falta al token.

IA en la sombra 

Los agentes propios o de terceros que se ejecutan dentro de Amazon Bedrock AgentCore a menudo son configurados o implementados por equipos sin registrarlos a través del proveedor de identidad (IdP). Dado que no se inyecta un SDK de seguridad en estos entornos, los agentes se activan dinámicamente y se conectan a recursos internos en los límites de las políticas de acceso corporativo. Sus tokens sin procesar muestran un cliente de máquina, pero carecen de una declaración iss (emisor), no hay ningún humano validando detrás de ellos y ningún propietario responsable de su ciclo de vida. Simplemente no puede controlar un agente de Bedrock que nunca emitió.

Acceso con Privileged Access 

La declaración alcance en el token de un agente no administrado expone un riesgo excesivo. Para permitir que el agente de Bedrock se conecte a la base de datos de destino sin interrumpir constantemente el flujo de ejecución para volver a autenticarse a través de los límites del sistema, los desarrolladores tienden a asignar el agente a una cuenta de servicio amplia y de larga duración. El alcance del token cubre una superficie administrativa permanente y amplia, mucho más allá de lo que necesita una consulta de texto específica. Cada alcance sobredimensionado crea una vía de acceso vulnerable a la inyección de prompts o la exfiltración de datos; sin embargo, revocar el agente interrumpe todos los demás flujos de trabajo automatizados que comparten esa única cuenta de servicio.

Suplantación, no delegación

A medida que la búsqueda cruza de Bedrock AgentCore al servidor Aurora DB MCP de destino, la identidad se reduce por completo a un principal de máquina genérico. El motor de la base de datos registra una cuenta de servicio que llama a query_knowledge_base(), sin registrar la identidad del operador humano que inició la tarea ni el subagente específico que ejecuta la consulta. Sin el linaje de delegación criptográfica dentro del token, el límite del recurso no puede aplicar permisos de datos a nivel de usuario, lo que resulta en la eliminación completa de la identidad y un registro de auditoría roto.

Sin gobernanza

Cuando el agente activa la invocación de una herramienta o una lectura inesperada de la base de datos, el token de máquina no administrado no incluye ni la identidad de la transacción ni el contexto del consentimiento humano. La acción se ejecuta a la perfección sin pausas durante el tiempo de ejecución para su aprobación, lo que deja a los equipos de seguridad completamente a oscuras. Después del hecho, se vuelve imposible vincular criptográficamente la transacción automatizada a un controlador humano, lo que significa que no se puede probar legalmente quién autorizó qué movimiento de datos.

La mayoría de las empresas corrigen uno o dos de estos.

Las cuatro brechas de seguridad comunes que se observan en el token

Tenga en mente esa única solicitud. El tutorial más adelante en esta publicación muestra al agente Agentcore accediendo a la herramienta Aurora DB MCP, esta vez con Okta en la ruta, y tiene éxito sin ninguno de los cuatro errores.

Okta para agentes de IA aborda las brechas de seguridad 

Okta convierte el límite de confianza en una capa de gobernanza incrustada en la ruta de ejecución (Figura 5). Streamward enruta todo el tráfico MCP a través de un Gateway de Agente en Tiempo de Ejecución en línea, el punto de aplicación de políticas (PEP), con Okta como punto de decisión de política (PDP) detrás. El agente nunca tiene una credencial original para las herramientas MCP. Esta es la idea del plano de control hecha física: cada petición se detiene en un punto que conoce las identidades implicadas y decide, en el momento, qué está permitido.

Arquitectura de malla multiagente de muestra con Okta para agentes de IA

El flujo de acceso seguro, salto por salto

La solicitud final que llega a cualquier herramienta de backend incluye una identidad verificable que contiene tanto el contexto humano (la declaración sub) como el principal de la carga de trabajo del agente (la declaración act). 

Aquí está la misma consulta de la base de conocimientos de antes, ahora ejecutándose a través de Okta. El siguiente diagrama lo rastrea de principio a fin, y los saltos que siguen recorren cada paso, mostrando cómo se construye e intercambia el token en el camino (Figura 6).

El flujo de acceso seguro de extremo a extremo

La solicitud final que llega a cualquier herramienta de backend contiene una identidad verificable que incluye tanto el contexto humano (la declaración sub) como el principal de la carga de trabajo del agente (la declaración cid). 

Salto 1: usuario humano a front-end

El usuario inicia sesión en el portal de Streamward a través de un flujo de OpenID Connect (OIDC) y Okta emite un token de acceso de usuario estándar.

Salto 2: del front-end al orquestador

El front-end gestiona el mensaje en lenguaje natural y pasa el contexto de la tarea al orquestador del agente maestro, transportando el token de acceso del usuario como un «token bearer».

Salto 3: orquestador a Okta, intercambio A2A

El orquestador determina que la tarea necesita procesamiento analítico en Bedrock AgentCore a través del agente Corp-Knowledge-Agent. Envía el token de usuario y el alcance aplicar al endpoint del token de Okta (/oauth2/v1/token) e inicia el flujo de Acceso Cross-App (XAA) (Autorización de Asertura de Identidad). Okta evalúa la política de acceso a agentes y devuelve un token ID-JAG de corta duración y uso único (urn:ietf:params:oauth:token-type:id-jag), asignado a la tarea.

Salto 4: orquestador a Okta, intercambio de tokens

El orquestador crea una afirmación de cliente con la clave privada del orquestador e intercambia el token ID-JAG en el servidor de autorización personalizado asignado al agente Agentcore de destino. Okta evalúa la política de acceso del usuario allí y devuelve un token de acceso con alcance destinado al agente Corp-Knowledge-Agent.

Salto 5.º: orquestador a Bedrock AgentCore

El orquestador pasa el token con alcance como parte de la llamada real de agente a agente (A2A) al agente AgentCore Corp-Knowledge-Agent. AgentCore verifica el token y permite que la llamada proceda en el contexto del agente orquestador y la identidad humana iniciadora.

Salto 6: AgentCore a la puerta de enlace

Corp-Knowledge-Agent invoca la herramienta query_knowledge_base en el servidor Aurora DB MCP a través de la puerta de enlace, pasando el token entrante y el permiso (ámbito) deseado para la herramienta de salida.

Salto 7: puerta de enlace a Okta, acceso entre aplicaciones 

La puerta de enlace inicia el flujo XAA de nuevo, enviando el token de entrada y el alcance solicitado al extremo de token de Okta (/oauth2/v1/token). Okta evalúa la política de acceso del agente y devuelve un token ID-JAG de corta duración y de un solo uso, con permisos reducidos para la tarea.

Salto 8: puerta de enlace a Okta, intercambio de tokens 

La puerta de enlace crea una aserción de cliente con la clave privada del Corp-Knowledge-Agent de Agentcore e intercambia el token ID-JAG en el servidor de autorización personalizado asignado al servidor Aurora DB MCP de destino. Okta evalúa la política de acceso del usuario y devuelve un token de acceso con alcance destinado al servidor MCP.

La herramienta al final recibe una solicitud que puede atribuir completamente: quién es la persona, qué agente actuó, su alcance y un reclamo de cadena de custodia (act) que vincula toda la cadena a un solo registro. La autoridad se decidía en tiempo de ejecución, se limitaba a la tarea y nunca se separaba de la persona responsable de ella.

Las cuatro fallas de seguridad centrales que resuelve la arquitectura

Al enrutar el flujo de ejecución de Bedrock AgentCore a través de esta arquitectura estandarizada, Streamward neutraliza con éxito los cuatro errores de identidad comunes que interrumpen las configuraciones de agentes no administrados:

Remediación de la IA en la sombra 

En lugar de permitir que el Corp-Knowledge-Agent de Bedrock se ejecute a ciegas alrededor del IdP central sin un emisor verificable, el agente se registra directamente en Universal Directory como un principal de carga de trabajo distinto. La gobernanza de TI mantiene una propiedad clara sobre su ciclo de vida y visibilidad sobre las conexiones de su red.

Saneamiento de Privileged Access con privilegios excesivos 

En lugar de ejecutarse en una cuenta de servicio amplia y permanente con permisos de acceso permanente que exponen toda la capa de la base de datos a amenazas de inyección de comandos, el agente recibe un token de corta duración generado dinámicamente en tiempo de ejecución. Sus ámbitos se intersectan matemáticamente y se reducen estrictamente a la operación de base de datos individual requerida para ese bloque de ejecución específico (Aurora-DB:read).

Prevención de la suplantación de identidad 

Al integrar la cadena de delegación act de múltiples saltos directamente en el contexto del token, la identidad no se reduce a una credencial de máquina genérica. El límite de recursos puede dar seguimiento a con precisión el linaje de la custodia, previniendo la eliminación de identidad y aplicando controles de datos de acuerdo con los permisos reales del humano iniciador.

Aplicación de la gobernanza

Cada paso del intercambio de tokens genera eventos estructurados y explícitos (app.oauth2.token.grant.id_jag) vinculado a un identificador de transacción inmutable. Este historial de auditoría permanente proporciona a los equipos de cumplimiento y respuesta ante incidentes evidencia de qué humano autorizó qué acción automatizada.

Los componentes de Okta para agentes de IA

Veamos los componentes de Okta para agentes de IA involucrados en la solución anterior.

Registro y detección de agentes  

Este componente convierte agentes autónomos desconocidos en principales de carga de trabajo conocidos y verificables al registrarlos en Universal Directory, donde cada uno obtiene un ciclo de vida, un propietario humano asignado y un lugar en la política. 

Dado que los agentes no administrados aparecen más rápido de lo que nadie puede registrarlos manualmente, la gestión de postura de seguridad de identidad (ISPM) los descubre en nubes y redes MCP, incluidos los agentes sin código que de otro modo permanecerían invisibles, y asigna cada uno a un propietario. Un agente que no puede ver es uno que no puede autorizar ni responsabilizar.

Incorporación automática de agentes

Los agentes creados en Salesforce, AWS, Microsoft y ServiceNow se importan directamente a Universal Directory, por lo que el registro se mantiene al día con su aparición.

Acceso entre aplicaciones 

XAA utiliza el Identity Assertion Authorization Grant para evitar la pérdida de identidad en flujos de trabajo de múltiples saltos. En lugar de un agente que actúa como una cuenta de servicio anónima, el humano (la reclamación sub) y el agente (la reclamación act) viajan ambos en el token (Figura 7), produciendo una reclamación de actor que es una cadena en lugar de un único principal. XAA es lo que mantiene la autorización ligada a un humano real cuando una solicitud cruza los límites del proveedor.

El flujo XAA

Consentimiento intermediado

Para el acceso inicial de agente a SaaS en nombre de un usuario, el Servicio de Token Seguro (STS) de Okta gestiona el consentimiento de forma dinámica. El agente hace una pausa mientras el usuario autoriza el acceso una vez, fuera de banda, antes de que la llamada continúe. El consentimiento se establece en la capa de identidad en lugar de estar integrado en cada agente, por lo que incluso un agente que no puede modificar hereda el control.

Autorización de agente a agente  

En una malla de agentes, Okta gestiona cada transferencia. Un solo paso configura la conexión entre dos agentes (Figura 8), y el permiso efectivo es la intersección de los derechos del usuario y los del agente que llama, lo que significa que un subagente nunca excede la combinación de privilegios mínimos. La afirmación del actor anidado se extiende desde el ser humano a través de cada agente hasta el servicio final, con autoridad controlada por políticas en cada salto y manteniendo al ser humano responsable en la cadena.

Configuración de la conexión de recursos agente a agente en Okta

Auditoría centralizada

Dado que un agente no es una persona jurídica y no puede responder por sí mismo, la persona responsable debe ser identificable al final de cada cadena. Un registro captura cada transacción con eventos de concesión explícitos que prueban quién actuó y en nombre de quién (Figura 9), que es el registro que un regulador, un tribunal o una junta solicitarán.

Registro del sistema de Okta para auditoría centralizada

Control seguro de tiempo de ejecución

Okta implementa el Inline Runtime agente puerta de enlace como el punto central de aplicación de políticas (PEP) frente a los recursos de etapa final, con Okta actuando como el punto de decisión de políticas (PDP) para cada solicitud (Figura 10).

La puerta de enlace del agente de ejecución

• Servidor MCP virtual: La puerta de enlace se presenta como un servidor MCP, lo que permite a las organizaciones proteger agentes de código bajo y sin código que acceden a recursos empresariales sin que esos agentes necesiten comunicarse directamente con el intercambio de token.
• Aislamiento de credenciales: La puerta de enlace abstrae los tokens XAA de corta duración y los tokens SaaS gestionados de mayor duración, por lo que las credenciales de esos recursos nunca se exponen a los agentes.
• Seguridad por llamada de herramientas en línea: Las plataformas low-code enrutan cada llamada de herramienta saliente a través de la pasarela, que intercepta la llamada, verifica la relación con políticas detalladas a velocidad de cable e inyecta un secreto backend de corta duración en el borde antes de la ejecución. El token que emite se acuña en el momento de la solicitud, se ajusta al alcance de la tarea, está limitado a la audiencia y se puede revocar en segundos, lo contrario a una credencial permanente que se puede encontrar en un archivo y reutilizar.

A dónde vamos ahora: capacidades avanzadas de Okta para agentes de IA

Lo que esta arquitectura proporciona hoy en día es la base: cada agente obtiene una identidad verificable, y su autoridad se determina en tiempo de ejecución y se limita a la tarea. 

La primera fase de un interruptor de desconexión global ya está en marcha, utilizando el Shared Signals Framework (SSF) para convertir una señal de riesgo en revocación, que se expandirá a la terminación coordinada en tiempo real en cada sistema conectado, el control que los tokens de corta duración por sí solos no pueden proporcionar.

Lo que sigue es el mismo principio del plano de control que alcanza las partes de la vida de un agente que aún no toca, las preguntas que los equipos de gobernanza ya hacen sobre el acceso humano, ahora dirigidas a los agentes:

• Certificación de acceso de agente: garantiza que la autorización de cada agente se someta a la misma certificación y revisión que cualquier otro acceso, donde los propietarios de los recursos confirman lo que debe conservarse y revocan lo que está obsoleto. 
• Gráfico de acceso de identidad a recurso: Traza la ruta completa desde una persona, a través de cada agente que actúa en su nombre, hasta los recursos y los alcances que cada uno puede alcanzar, de modo que el radio de explosión sea visible antes de que algo salga mal y el objetivo de revocación sea obvio cuando sucede. 
• Aprobación con intervención humana: En el momento del aprovisionamiento y al realizar una acción delicada, mantiene a una persona en el proceso de toma de decisiones donde más importa. 
• Autoridad no supervisada: Los agentes comienzan a obtener autoridad no supervisada en función de su comportamiento, en lugar de que se les conceda la confianza por adelantado.

Nada de esto es un nuevo plano de control. Es el mismo, extendido desde el momento en que se crea un agente hasta el momento en que se revisa, restringe o retira su autoridad.

El plan para proteger a una empresa que usa agentes

Retrocede un paso y la arquitectura responde a las tres preguntas que se hace todo equipo de seguridad (Figura 11):

1. ¿Dónde están mis agentes? (Los que la empresa construyó y los que llegaron por su cuenta.) 
2. ¿A qué se pueden conectar? (Desde servidores MCP y aplicaciones SaaS hasta otros agentes, cuentas de servicio y sistemas de registro heredados). 
3. ¿Qué se les permite hacer? (Decidido en tiempo de ejecución, escalado a un humano donde importa y revocable cuando no sale según lo planeado).

Esas tres preguntas son la disciplina operativa detrás del Agentic Enterprise Blueprint.

El plan de Okta para proteger agentes de IA a escala

Empresas como Uber han demostrado la necesidad de crear este tipo de gobernanza para los agentes de IA.  Pero no todas las empresas tienen que arquitectar esto por sí mismas.

El hilo conductor a través de cada capa es el mismo: la identidad es el plano de control, la autorización se decide en tiempo de ejecución y se limita a la tarea, el humano responsable viaja con la solicitud, y todo se ejecuta en estándares abiertos para que se mantenga en todos los proveedores que toca un agente. 

Tratar a los agentes como identidades de primera clase en esos términos es la forma correcta de proteger la Enterprise, y Okta para agentes de IA lo convierte en una capa que se adopta en lugar de un sistema que se tarda un año en construir.  La arquitectura descrita en este artículo es algo que se adopta, no algo que se construye. 

Descubre cómo Okta y Auth0 protegen a los agentes de IA, o habla con nuestro equipo.