El punto ciego de seguridad de la IA en su Enterprise
La capacidad de responder a tres preguntas determina si sus agentes de IA están bajo control:
- ¿Dónde están mis agentes?
- ¿Con qué se pueden conectar?
- ¿Qué pueden hacer?
Para la mayoría de los responsables de seguridad, no existe una respuesta clara a la segunda pregunta.
La razón por la que es tan difícil responder es que los agentes que ejecutan tareas críticas para el negocio no suelen desarrollarse internamente. Hasta ahora, no existía una forma estándar para que Claude Code, GitHub Copilot o Salesforce Agentforce solicitaran credenciales a Okta, se mantuvieran dentro del ámbito de aplicación o registraran sus acciones.
La solución habitual son las claves de API de larga duración: acceso amplio, sin atribución de usuario, sin registro de auditoría, a una sola credencial filtrada de una filtración. Y cuando algo sale mal, lo más probable es que no puedas proporcionar a tu auditor la información clave que necesita, como qué agente accedió a los datos, en nombre de quién actuó el agente y bajo qué política operó.
El resultado: una mayor probabilidad de que se produzca una filtración. Y cuando se produce una filtración, podría enfrentarse a problemas regulatorios, auditorías fallidas y el coste operativo de revocar manualmente acceso a todos los sistemas que el agente haya tocado.
Así es como se ve eso en la práctica. Un Developer necesita un agente para acceder a GitHub y Slack. Introducen un token de acceso personal y un token de Slack en la configuración del agente. Ahora hay un agente con acceso permanente al control de versiones y a los canales internos.
Las credenciales se encuentran en un archivo no protegido. Nadie puede decir qué acciones fueron del agente y cuáles fueron del ser humano. Si una solicitud manipulada compromete a ese agente, los tokens se pierden con él.
Las credenciales activas no caducan ni dejan registro de auditoría, lo que las convierte en una filtración en potencia. Multiplique eso por cada Developer y cada asistente de codificación que utilicen sus equipos.
Por qué la gobernanza de agentes de IA requiere identidad en tiempo de ejecución
La gestión de agentes requiere la verificación de identidad en tiempo de ejecución. Sin ella, pierde la capacidad de responder a las preguntas más importantes cuando algo sale mal.
El lugar más eficiente para capturar información clave, como qué agente accedió a estos datos, en nombre de quién y bajo qué política, es en el momento en que se ejecuta una llamada a la herramienta, no en el momento de la configuración ni posteriormente. Eso requiere una capa de identidad en la ruta de la solicitud.
Puertas de enlace tradicionales frente a puertas de enlace nativas de la identidad
| Capacidad | Puerta de enlace API/MCP tradicional | Puerta de enlace de agente nativo de identidad |
|---|---|---|
| Enfoque principal | Enrutamiento de tráfico, equilibrio de carga y limitación de velocidad. | Verificación de identidad y aplicación de políticas |
| Atribución de usuario | Ninguno (da seguimiento a la IP/sistema, no a usuarios individuales) | Asigna cada llamada a un agente y usuario humano específico. |
| Gestión de credenciales | Almacena o transmite claves API estáticas y de larga duración. | Los intermediarios generan tokens aislados y de corta duración de forma dinámica. |
| Revocación de acceso | Requiere rotar las claves en todas las aplicaciones de etapa final. | Revocación instantánea en el extremo de la puerta de enlace |
Cómo la puerta de enlace del agente protege las llamadas de herramientas con sus políticas de acceso.
Agente Puerta de enlace, una nueva funcionalidad de Okta para agentes de IA, cierra esa brecha. Los agentes de IA pueden acceder de forma segura a las herramientas Enterprise a través de un único extremo protegido por Okta. Puerta de enlace del agente gestiona las credenciales en tiempo de ejecución, atribuye las llamadas a las herramientas y no requiere cambios en el agente, sin código. El resultado: los equipos de seguridad pueden responder a sus preguntas de auditoría y los equipos de IA pueden entregar más rápido.
Okta es el proveedor de identidad en la ruta: verifica al agente, controla qué herramientas puede usar, almacena las credenciales para que el agente no pueda modificarlas y registra las llamadas a las herramientas en una identidad administrada.
agente puerta de enlace se sitúa en la ruta de las llamadas a herramientas que realizan sus agentes y responde a una pregunta fundamental del plan para la Enterprise agenteica segura: ¿a qué pueden conectarse sus agentes?
Agente Puerta de enlace aplica la política en tiempo de ejecución. Pero la aplicación de las políticas en tiempo de ejecución requiere saber quiénes son sus agentes, a qué deben tener acceso y qué políticas los rigen. Okta para agentes de IA proporciona la base de identidad y gobernanza al descubrir, incorporación, proteger y gestionar agentes en toda su Enterprise.
La arquitectura de agente puerta de enlace
agente puerta de enlace ofrece tres resultados fundamentales:
- Aplicación de políticas: controla el acceso de los agentes a las herramientas Enterprise desde un solo lugar y puede revocarlo instantáneamente.
- Seguridad: Los agentes solo poseen tokens de corta duración, por lo que los adversarios no pueden extraer credenciales de la etapa final.
- Visibilidad: Todas las acciones son auditables con atribución completa en todos los sistemas.
No es necesario que seas el propietario del código del agente. Agente puerta de enlace ofrece protección neutral del proveedor en diversas plataformas y nubes, incluyendo Claude Code, Cursor, GitHub Copilot, Salesforce Agentforce y cualquier agente que sus equipos puedan conectar a un extremo de MCP.
Integración de agente puerta de enlace en su infraestructura existente
Agente puerta de enlace no reemplaza su puerta de enlace MCP o API gateway existente. En cambio, añade una capa de identidad y políticas sobre su infraestructura actual.
Su puerta de enlace actual continúa gestionando el enrutamiento, la limitación de velocidad y la conectividad. Agente Puerta de enlace se encarga de la aplicación de las políticas de identidad.
Sus equipos apuntan sus clientes agentes al extremo de Agente Puerta de enlace. No se requieren cambios en el código de los agentes ni modificaciones en los sistemas de etapa final. El agente realiza una llamada y obtiene una respuesta. Lo que cambia es que ahora todas las llamadas a herramientas se realizan a través de la política de Okta.
Patrones de credenciales compatibles
Agent Gateway actualmente admite dos patrones de credenciales:
- Acceso entre aplicaciones (XAA): El nuevo protocolo que permite el acceso seguro de agente a aplicación para recursos habilitados para Okta.
- Consentimiento intermediado: El servicio de token seguro (STS) de Okta intermedia dinámicamente el consentimiento de OAuth para sistemas externos como GitHub y Slack.
La experiencia del agente es idéntica en ambos casos.
Cumpla con los requisitos de seguridad local con MCP Bridge.
Organizations con requisitos normativos estrictos, como el cumplimiento de FedRAMP, las redes privadas o las restricciones de residencia de datos, pueden implementar MCP Bridge.
Disponible a través de Okta Professional Services, MCP Bridge proporciona un refuerzo de identidad y un aislamiento de credenciales similares dentro de su propia infraestructura.
Cómo empezar a usar Agente Puerta de enlace hoy mismo
Si su equipo de seguridad revisara las llamadas realizadas la semana pasada a la herramienta de agente de IA, ¿podrían determinar qué agente actuó, en nombre de quién, a qué datos accedió y si se expusieron credenciales?
Una puerta de enlace MCP tradicional puede enrutar las llamadas de las herramientas, pero no puede proporcionar el contexto de identidad necesario para responder a esas preguntas.
Una puerta de enlace nativa de identidad. Muestra qué agente accedió a qué datos, para quién y bajo qué política, en el momento en que se ejecuta cada llamada.
Sé de los primeros en probar agente puerta de enlace. Ofrecemos esta nueva capacidad de Okta para agentes de IA como un lanzamiento de investigación. Para manifestar su interés, solicite unirse al Programa de Socios de Investigación.
Cualquier mención de productos, funciones, funcionalidades o certificaciones futuras en este blog es únicamente con fines informativos. Estas menciones no son compromisos de entrega y no deben considerarse como base para tomar decisiones de compra.
