Okta y AgentCore ponen bajo control a los agentes de IA: revocacion de acceso en 1 segundo

Un agente que actualiza un ticket o consulta la ficha de un cliente opera en nombre de una persona y dentro de aplicaciones a las que esa persona tiene acceso. Esto plantea una pregunta incomoda para los equipos de seguridad: exactamente que agente tiene derecho a actuar por que usuario en que aplicacion, y como se lo puede detener. El consentimiento OAuth por aplicacion y las cuentas de servicio compartidas no responden a esa pregunta. En la primera parte de su guia, AWS propone una respuesta basada en Okta Cross App Access (XAA) y Amazon Bedrock AgentCore.

Quien se encarga de cada cosa

El reparto es sencillo. Okta es el plano de control: decide que agente puede actuar por que usuario y sobre que recurso. AgentCore Identity es el plano de ejecucion: almacena las credenciales del agente, convierte la decision de Okta en un token aceptado por el recurso y conserva en el ambas identidades, la del usuario y la del agente.

En cada solicitud intervienen tres tokens. El token de ID indica quien es el usuario. El ID-JAG es la propia decision de Okta: es de un solo uso y tiene una vigencia de 5 minutos. El token de acceso es el que acepta el recurso de destino; tambien dura 5 minutos, identifica tanto al usuario como al agente e incluye los grupos del usuario.

La cadena funciona asi. El usuario inicia sesion en el frontend (BFF) mediante OpenID Connect. El BFF canjea su token de ID por un ID-JAG en Okta conforme a RFC 8693 y se autentica como el agente.

Okta comprueba que el agente este activo, que el usuario tenga el agente asignado y que un administrador haya conectado el agente al servidor de autorizacion correcto con los scopes necesarios. Despues, el BFF invoca al agente en el runtime de AgentCore usando el ID-JAG como token bearer, y el autorizador JWT del runtime solo admite ID-JAG emitidos por Okta especificamente para ese agente. A continuacion, AgentCore Identity canjea el ID-JAG por un token de acceso conforme a RFC 7523, con el que el agente accede a los servidores MCP.

El gestor de tareas verifica que el token haya sido obtenido por un agente registrado y que el grupo y el scope del usuario permitan usar la herramienta concreta.

Donde es facil tropezar

Los autores enumeran con franqueza los problemas con los que ellos mismos se encontraron.

Primero, Okta rechaza una solicitud de ID-JAG si incluye scopes de OpenID Connect como openid o profile, y devuelve el error invalid_scope. Se necesita al menos un scope personalizado y ningun scope estandar.

Segundo, el token de ID debe proceder de la misma aplicacion vinculada al agente. Un token de otra aplicacion rompe el canje con un error que indica que el cliente no esta registrado para delegacion.

Tercero, cada agente necesita su propio proveedor de credenciales de Okta. Intentar canjear el ID-JAG de un agente en nombre de otro termina en rechazo porque los valores client_id no coinciden.

Cuarto, el SDK guarda el workload access token en BedrockAgentCoreContext, no en los encabezados de la solicitud. La primera version de los autores lo buscaba en los encabezados, no lo encontraba y desviaba las 21 solicitudes probadas a una ruta alternativa con una segunda workload identity. El token debe leerse desde el contexto.

Por ultimo, en la politica de IAM el segmento del ARN se escribe oauth2credentialprovider, sin guion; con guion, todas las llamadas fallaban con AccessDeniedException. Para el rol del agente bastan dos statements: GetResourceOauth2Token y permiso para leer el secreto del proveedor.

Cifras y limitaciones

Despues de que un administrador retirara al usuario la asignacion al agente, Okta empezo a rechazar nuevas solicitudes en aproximadamente 1 segundo, mientras que los tokens ya emitidos caducaron en un plazo de 5 minutos. La primera llamada, incluido el canje del ID-JAG, tardo alrededor de medio segundo, y AgentCore Identity agrego en total unos 0,6 segundos a una solicitud de cerca de 30 segundos. Una segunda llamada a otro servidor MCP devolvio el mismo token desde el almacenamiento en una media de 58 ms, sin volver a canjear el ID-JAG de un solo uso. Un nuevo ID-JAG para el mismo usuario genera un token nuevo, por lo que cada solicitud refleja la decision vigente de Okta.

Advertencias: el codigo es un ejemplo educativo y no apto para produccion; los fragmentos muestran el patron, no una solucion lista para usar. Las pruebas se realizaron con el nivel gratuito Okta Integrator y en una sola region de AWS (Oregon). La guia lleva aproximadamente una hora. Para produccion se necesitan MFA, rotacion del secreto —o Private Key JWT en lugar de un secreto compartido— y la aprobacion de los equipos de seguridad y juridico.

Que hacer

Si sus agentes acceden a sistemas internos mediante una cuenta de servicio compartida, conviene replantear la arquitectura. Registre al agente como una entidad independiente en el IdP, limite sus scopes, mantenga los tokens con una vigencia corta y compruebe los permisos del usuario dentro de las propias herramientas, no solo en el punto de entrada. La segunda parte promete aplicar el mismo enfoque a AgentCore Gateway, las politicas de Cedar, un agente en EKS y la auditoria en CloudWatch.