¿Qué es una puerta de enlace de agente?
Agent puerta de enlace es una capa de control de identidad en tiempo de ejecución dentro de Okta para agentes de IA. Valida cada solicitud de agente a herramienta comparándola con las políticas de identidad mediante el intercambio de tokens RFC 8693. A diferencia de las puertas de enlace tradicionales que dependen de claves de servicio compartidas, Agent Gateway requiere credenciales que identifiquen tanto al agente de IA que actúa como al usuario humano, lo que evita ataques de intermediario confundido y la herencia de permisos no autorizada.
Si un agente de IA en su entorno se descontrolara ahora mismo, ¿podría decir para quién actuaba, qué tocó y cuándo? Muchos equipos de seguridad no pueden.
Los agentes de IA se están implementando más rápido que los controles destinados a regularlos. Las puertas de enlace pueden conectar agentes con herramientas. Sin embargo, no muchas pueden decirle en nombre de quién actúa un agente. Esa es una vulnerabilidad que los atacantes pueden explotar, y no se hará evidente hasta que algo ya haya salido mal.
Las puertas de enlace se venden como un control, pero la mayoría no puede verificar quién está realmente detrás de una solicitud. Sin eso, no controlan nada: simplemente enrutan las llamadas y registran lo sucedido, utilizando la autoridad que se les ha otorgado. Sin la identidad como fundamento, una puerta de enlace es un punto de control sin reglas que hacer cumplir, sin agente al que atribuir y sin gobernanza que aplicar.
Puerta de enlace del agente de Okta cierra esa brecha. Es la capa de aplicación de reglas en tiempo de ejecución dentro de Okta para agentes de IA. Siempre que un agente de IA pueda configurarse para llamar a un Protocolo de Contexto de Modelo (MCP) externo, Agent puerta de enlace valida cada llamada del agente a la herramienta con respecto a la política, aísla las credenciales en el momento de la acción y produce un registro de auditoría unificado.
Okta para agentes de IA añade la base de identidad y gobernanza en torno a Agent puerta de enlace: detección de agentes, registro como identidades de primera clase, flujos de trabajo de acceso, campañas de certificación y correlación de auditoría entre sistemas. Agent puerta de enlace ya está disponible de forma general como parte de Okta para agentes de IA. Responde a la tercera pregunta del plan maestro para la Enterprise con agentes seguros: "¿Qué están haciendo mis agentes?".
En este blog, aprenderá sobre uno de los principales problemas de la mayoría de las puertas de enlace de agentes: pueden conectar a un agente con una herramienta, pero no pueden verificar en nombre de quién actúa dicho agente. Y verá en qué se diferencia la puerta de enlace Agent Gateway de Okta: no procesará una llamada a menos que la credencial incluya tanto al usuario como al agente que la gestiona, lo que ayuda a garantizar que la autoridad no se tome prestada, se comparta o se herede por accidente.
¿Por qué las puertas de enlace MCP tradicionales no logran proteger a los agentes de IA?
Las puertas de enlace MCP tradicionales pueden enrutar las solicitudes de los agentes a las herramientas, pero a menudo carecen de una medida de seguridad fundamental: no pueden verificar en nombre de quién actúa un agente.
Explicación de la vulnerabilidad del agente confundido
Comencemos con un ejemplo práctico en el que sus agentes no tienen una puerta de enlace:
- Amplio aprovisionamiento de credenciales: Su equipo crea un asistente de recursos humanos para responder preguntas sobre los expedientes de los empleados. Para que funcione para quien lo solicite, alguien le proporciona una cuenta de servicio con acceso de lectura a todos ellos.
- Solicitud de usuario no autorizado: Katie es proveedor de servicios. Ella le pregunta al agente por la remuneración del director ejecutivo.
- Omisión de políticas: El agente se lo otorga utilizando el acceso que posee legítimamente.
- Error de auditoría: La solicitud aparece completamente limpia en el registro de auditoría.
No se produjo ningún ataque informático. Lo único que separaba a Katie de esos datos era el criterio del propio agente.
Ese es el problema del agente confuso: la solicitud lleva la consulta del usuario, pero no su autorización. El agente actúa en función de la información a la que tiene acceso, no de lo que la persona que pregunta tiene permitido saber. Es un fallo que lleva décadas en el funcionamiento de los permisos, y es precisamente lo que ocurre cuando se otorga a un agente un acceso amplio y se confía en que se autogestione.
Limitaciones de las arquitecturas MCP tradicionales
Revocación de todo o nada
Revocar una credencial de puerta de enlace compartida interrumpe el acceso de todos los agentes conectados, lo que lleva a los administradores a dejar permanentemente activas credenciales demasiado permisivas:
- El administrador configura una puerta de enlace conectada a un servidor MCP de GitHub utilizando una credencial compartida
- Cada agente que se conecta a través de esa puerta de enlace hereda el mismo acceso amplio
- Revocar la credencial interrumpe el acceso para todos los agentes que operan detrás de ella
- El resultado: Nadie lo revoca
Tokens de portador de identidad única
MCP fue diseñado teniendo en cuenta el problema del diputado confundido. Pero existe una limitación fundamental: MCP funciona con token de portador OAuth 2.1, que solo identifican una identidad. Una puerta de enlace no puede transmitir el token del agente —tiene que generar uno nuevo. Así que, aunque una puerta de enlace quiera decirle a GitHub “este es el agente de codificación de Katie, que actúa en nombre de Katie”, no puede. Cualquier identidad que elija se convierte en la única que ve GitHub.
Las medidas de seguridad de la ingeniería de prompts fallan
Podría intentar solucionar esto en el prompt indicándole al agente que nunca acceda a los datos de compensación. Probablemente no. Pero la credencial aún abre todo, por lo que la medida de seguridad más eficaz es que el agente opte por no mirar, que era el problema original.
Agent puerta de enlace de Okta: una aplicación en tiempo de ejecución nativa de la identidad para agentes de IA que se conectan a herramientas Enterprise
Agent puerta de enlace, una nueva funcionalidad de Okta for IA Agents, es el punto de control en tiempo de ejecución que determina a qué puede conectarse un agente y qué puede hacer durante cada acción. No procesará una llamada a menos que quien realiza la llamada presente una credencial que identifique a ambas partes: el usuario que solicita la acción y el agente que realiza la solicitud. Este requisito de verificar la identidad es lo que lo diferencia de una puerta de enlace que simplemente retransmite el tráfico.
Configuración de un agente puerta de enlace.
Una puerta de enlace típica puede autenticar que algo tiene permiso para conectarse. agente puerta de enlace verifica a qué usuario va dirigida la solicitud, qué agente de IA está actuando y si ese agente ha sido autorizado para actuar en nombre de ese usuario;a continuación, aplica la política en el momento en que se realiza la llamada a la herramienta.
Cada llamada a una herramienta se atribuye a una identidad de agente gestionado, un usuario final, una herramienta y un resultado.
Supongamos que Katie es empleada y que un agente está a punto de hacer una llamada en su nombre. Algunas puertas de enlace autentican al emisor con una clave de plataforma y toman al usuario como parámetro:
POST /mcp HTTP/1.1
Authorization: Bearer <platform api key>
{ "user_id": "Katie", "tool": "read_file", ... }
Una puerta de enlace construida de esta manera puede verificar la clave, pero no puede verificar a Katie. Su nombre es solo texto en la solicitud, escrito por quien realizó la llamada, por lo que cualquiera que tenga esa clave puede afirmar ser quien quiera.
Agente puerta de enlace no acepta este tipo de credenciales en absoluto. En cambio, agente puerta de enlace implementa la delegación RFC 8693, que requiere que cada llamada a la herramienta presente una credencial emitida por su proveedor de identidades que contenga dos declaraciones de identidad distintas:
- El sujeto (
sub): el usuario final autenticado que solicita la acción - El actor (
act): el agente de IA registrado que ejecuta la solicitud
Esto es lo que agente puerta de enlace espera en cada llamada:
{
"sub": "00uKatie456",
"aud": "https://acme.gateway.okta.com/mcp/servers/eng-tools",
"act": {
"sub": "0oafxqCAJWWGELFTYASJ",
"sub_profile": "ai_agent web_app"
}
}
La llamada es para sub, y act indica quién la realiza. sub_profile indica que quien llama es una aplicación y un agente.
No se hereda nada, por lo que agente puerta de enlace no puede inventar un usuario. El usuario sub en esa credencial es el único en cuyo nombre puerta de enlace de agente puede actuar durante esta llamada. Cuando Puerta de enlace del agente necesita una credencial para el servidor MCP, intercambia la credencial del agente con Okta y recibe una vinculada al mismo usuario, lo que se ajusta a la semántica “en nombre de” definida en la RFC 8693. Okta solo puede devolver esa credencial porque el usuario previamente dio su consentimiento en el servidor MCP mediante una conexión registrada por el administrador.
Por lo tanto, un agente no puede convencer a Agent puerta de enlace para que actúe en nombre de otra persona. Katie aún puede preguntar. Sin embargo, ahora agente puerta de enlace actúa en su nombre con una credencial vinculada a ella, lo que garantiza que el agente solo pueda hacer lo que Katie podría hacer por sí misma.
Matriz de capacidades de aplicación de la identidad
En general, una puerta de enlace solo puede actuar sobre la información que ya contiene la credencial que recibe. En el momento de su creación, se decide si dicha credencial contiene la identidad real del usuario y del agente, o ninguna en absoluto.
| Tipo de credencial recibida por una puerta de enlace | Contexto del usuario capturado | Contexto del agente capturado | Contexto del agente capturado |
|---|---|---|---|
| Clave de servicio compartido | Ninguno | Ninguno | Bajo: No es posible la gobernanza ni la atribución. |
| Token exclusivo para el usuario | Solo para usuarios | Ninguno; todos los agentes se ven iguales | Medio: No se puede distinguir la actividad del agente de la actividad del usuario |
| Token delegado (RFC 8693) | Usuario verificado | Agente verificado | Alto: aplicación y atribución completas de la política en tiempo de ejecución |
La puerta de enlace de agente de Okta solo opera en la tercera fila. No procesará una llamada a menos que la credencial sea un token delegado y verificado que identifique tanto al usuario como al agente.
Reglas de acceso de agentes efectivas
En la práctica, lo que un agente puede hacer realmente está limitado por la intersección exacta de los permisos de Agent Gateway y los derechos del usuario:
Lo que el agente puede hacer = Lo que permite la puerta de enlace ∩ Lo que el usuario ya puede hacer
Lo que permite la puerta de enlace ← impuesto por la puerta de enlace
Lo que el usuario ya puede hacer ← impuesto por el servidor MCP
Agent puerta de enlace sabe qué agente está llamando y qué herramientas están expuestas. El servidor MCP conoce sus propios registros y qué usuarios pueden acceder a ellos. Necesita ambos.
Agente Puerta de enlace es una carga de trabajo registrada con su propio principal y sin acceso permanente para acceder a nada. Un administrador configura dos cosas antes de que se resuelva cualquier llamada:
- Enlace de delegación: Otorga a un agente específico permiso para delegar en nombre del usuario a esta puerta de enlace. Sin uno, el intercambio es rechazado.
- Conexión de recursos: Otorga a esta puerta de enlace permiso para acceder a un servidor MCP específico y define exactamente qué herramientas de ese servidor están expuestas.
Ni la persona que llama ni la credencial del agente otorgan permiso. El acceso se limita a los permisos de delegación y de recursos que configure el administrador.
Identity Governance es también la base de la gobernanza de los costos.
Los agentes de IA no solo crean riesgos de acceso, sino que también pueden generar gastos a velocidad de máquina. Un agente que llama repetidamente a una API premium, activa Workflows costosos o invoca herramientas de alto consumo puede generar costos inesperados mucho antes de que un humano se dé cuenta.
La gobernanza de los costos comienza con la atribución. Si varios agentes comparten una credencial, resulta difícil responder a preguntas básicas, como por ejemplo: ¿Qué agente generó la actividad? ¿Para quién actuaba? ¿Qué herramienta o recurso fue el que generó el costo?
agente de puerta de enlace de Okta crea el contexto de identidad necesario para responder a esas preguntas. Dado que cada solicitud está vinculada tanto al usuario como al agente que actúa en su nombre, las organizaciones pueden correlacionar la actividad del agente con las herramientas y los recursos a los que accede. Esto crea una base más sólida para supervisar el uso, investigar actividades inesperadas y aplicar la gobernanza a medida que aumenta la escala de las implementaciones de agentes.
Próximamente: soporte con acceso entre aplicaciones y un interruptor de apagado a través de puerta de enlace de agente
Soporte de agente puerta de enlace para el acceso entre aplicaciones
Los agentes necesitan acceder a aplicaciones SaaS comunes, como Slack o Salesforce, y Okta cuenta con un protocolo de estándar abierto para ello: Cross App Access. Cuando se lance el soporte, Cross App Access permitirá que los agentes de IA accedan de forma segura a las aplicaciones en nombre del usuario, manteniendo intactas ambas identidades. El administrador aprueba una sola vez qué aplicaciones pueden usar los agentes, en lugar de que cada empleado tenga que aprobar cada aplicación individualmente.
Hacerlo a través de una puerta de enlace ofrece una ventaja real: proporciona un punto de control central para activar o desactivar el acceso de un agente, en lugar de gestionarlo aplicación por aplicación.
Agente puerta de enlace admitirá Cross aplicación Access en un futuro próximo. Esto permitirá que la puerta de enlace muestre “esta solicitud proviene de una concesión que ya aprobó” y luego intercambie esa afirmación por un nuevo token sin necesidad de realizar ningún cambio en la aplicación. Ese mecanismo se propone en el borrador de la IETF afirmación de continuación de identidad.
Interruptor de apagado basado en puerta de enlace de agente
Finalmente, dado que cada llamada a la herramienta pasa por un único punto de control en tiempo de ejecución, agente puerta de enlace puede detener las solicitudes en tiempo real. Cuando esté disponible, la función de desactivación automática permitirá la desactivación inmediata del agente, incluso de los tokens ya emitidos, al rechazar cualquier solicitud que contenga un token emitido a un agente desactivado. Dado que esta medida se aplicará en los límites de Okta, no será necesario esperar a que cada aplicación conectada vaya a revocar acceso de forma independiente.
Cómo evaluar una puerta de enlace de agente de IA: cuatro preguntas clave que debe hacerse
Cuatro preguntas le dirán en qué situación se encuentra cualquier puerta de enlace:
- Verificación del emisor: ¿Qué credencial recibe el servidor MCP y quién la emitió?
- Verificación de identidad del usuario: ¿Puede la puerta de enlace mostrar a qué usuario se dirige una llamada, o el usuario es un parámetro que proporciona quien realiza la llamada?
- Linaje del consentimiento: ¿El consentimiento de quién autorizó el acceso del agente a ese servidor MCP?
- Riesgo de elusión: ¿El agente dispone alguna vez de una credencial que funcione sin la puerta de enlace en la ruta?
Agente Puerta de enlace está diseñado para responder a las cuatro preguntas.
Puerta de enlace de agentes es solo una parte de un panorama más amplio: Okta para agentes de IA es la plataforma más completa que proporciona la visibilidad, el control y la gobernanza que necesita para proteger los agentes que implementa su empresa.
Puerta de enlace de agentes está disponible con Okta para agentes de IA sin costo adicional.
Clientes actuales: Comuníquense con su representante de cuenta para comenzar a usarlo hoy mismo.
¿Aún no es cliente de Okta para agentes de IA? Descargue nuestra hoja de datos para descubrir cómo Okta para agentes de IA puede ayudarle a gestionar de forma segura sus agentes de IA desde un único plano de control.
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.
Estos materiales tienen fines informativos generales y no constituyen asesoramiento legal, de privacidad, seguridad, cumplimiento o empresarial.
El contenido puede no reflejar los desarrollos más recientes en seguridad, legal y/o privacidad. Usted es el único responsable de obtener asesoramiento de su propio asesor legal y/o profesional y no debe basarse en estos materiales para decisiones de cumplimiento, implementación o compra.
Okta no hace declaraciones ni ofrece garantías respecto a este contenido y no se hace responsable de pérdidas o daños que puedan derivarse de la implementación de estas recomendaciones. La información sobre los compromisos contractuales de Okta con sus clientes se puede consultar en okta.com/agreements.
