Control de acceso de agentes de IA: qué valida cada capa

El control de acceso de un agente de IA determina qué identidad delegada presenta, qué herramientas puede usar y qué permisos conserva el usuario. En el diseño que AWS describió en un tutorial publicado el 6 de noviembre de 2026, Okta emite el token ID-JAG, Amazon Bedrock AgentCore Gateway lo valida, Cedar decide qué herramientas puede listar o invocar el agente y el servidor MCP vuelve a comprobar los grupos y el alcance del usuario. AWS explica el flujo y las pruebas de su implementación.

La separación importa porque autorizar al agente no equivale a autorizar todas sus acciones ni a sustituir los permisos del usuario. Cada capa responde a una pregunta distinta.

Al diseñar los permisos, revisa tanto cada llamada como lo que el agente podría deducir al combinar varias respuestas permitidas.

Qué comprueba cada capa

Okta emite un ID-JAG, un token de autorización delegada. El agente se lo presenta a su Gateway, que comprueba que coincidan el emisor, la audiencia, el cliente permitido y los ámbitos configurados. En el ejemplo, los ámbitos son xaa:read y xaa:write, y los del destino deben coincidir con los del ID-JAG.

Después, Cedar evalúa si ese agente puede consultar el catálogo de herramientas y si puede realizar una llamada concreta. AWS describe políticas de permiso explícito con denegación por defecto: si no se concede el permiso, la acción no se autoriza. El servidor MCP mantiene una comprobación aparte de los grupos y el alcance del usuario. Así, la política de Cedar limita las acciones del agente y el servidor comprueba la autorización del usuario para la operación solicitada.

En el patrón descrito, cada agente tiene su propio Gateway y proveedor de credenciales, porque cada proveedor se autentica como un agente de Okta. AWS indica que esta organización permite retirar del rol de ejecución del agente los permisos de intercambio de tokens y acceso a secretos del proveedor. Su agente de informes en Amazon EKS tenía su propio registro en Okta, Gateway y proveedor, y su conexión permitía el ámbito xaa:read.

XAA y consentimiento OAuth por usuario

Cross App Access (XAA) sirve para los destinos cuyo servidor de autorización acepta ID-JAG. En el modelo descrito por AWS, un administrador de Okta decide qué agente puede actuar en nombre de qué usuarios; la persona no recibe una solicitud de consentimiento y Okta evalúa la política cada vez que se pide un token. Para un destino con servidor de autorización propio, como GitHub en el ejemplo, AWS emplea consentimiento OAuth por usuario.

La prueba de AWS mostró comportamientos distintos al suspender a Alice en Okta. La tabla recoge esos resultados de la prueba concreta, no una regla general para todas las aplicaciones.

La diferencia práctica depende del servidor de autorización de cada destino. En la prueba de AWS, suspender a una persona no tuvo el mismo efecto sobre un ID-JAG de corta duración que sobre un token y un permiso OAuth ya guardados.

Qué muestran las pruebas y las mediciones de AWS

En la prueba descrita por AWS, el agente A mostró seis herramientas y el agente B cuatro: Cedar ocultó las herramientas de escritura de B. Alice y Carol no pudieron crear tareas con el agente A; Bob sí. El agente B tampoco tenía una herramienta de escritura para Bob. Los resultados ilustran cómo se combinan la política sobre herramientas y la comprobación de grupos del servidor MCP.

AWS midió los percentiles p50 y p90 de las trazas de Gateway A durante 24 horas. El p50 es la mediana; el p90, el valor por debajo del cual quedó el 90 % de las duraciones observadas en ese tramo.

AWS cifra en unos 0,2 segundos la suma de las medianas de los tramos de identidad y política de una llamada. La mediana del tramo Gateway.TargetInvocation, que corresponde a la invocación del servidor MCP en AgentCore Runtime, fue de 5.565 ms. Son medidas de la implementación probada por AWS, no una garantía de rendimiento para otros despliegues.

AWS también correlacionó las trazas de AgentCore con los eventos del registro de sistema de Okta en CloudWatch. En su prueba, los eventos llegaron aproximadamente un segundo después de que Okta los publicara.

Detalles que afectan a la configuración

AWS indica que las políticas que nombran herramientas no se acoplaron a destinos con catálogos dinámicos en sus pruebas. Su Gateway pagina tools/list por destino, así que el cliente debe seguir el cursor para recibir las herramientas de los destinos posteriores. Las políticas también deben estar en estado ACTIVE antes de asociarles el motor de políticas.

Para un ámbito de consulta limitado, una política debe autorizar los ámbitos que presenta el ID-JAG y el destino debe tener la misma configuración. En el diseño de AWS, la comprobación del Gateway y Cedar precede a la autorización del usuario en el servidor MCP; una capa no elimina la otra.

AWS describe sus fragmentos como conceptuales, no como una solución completa lista para desplegar, y destina el código de ejemplo a uso no productivo.

Qué pueden revelar varias respuestas permitidas

Un participante en un debate sobre acceso de agentes a datos de empresa planteó un escenario hipotético: una herramienta devuelve los totales de nómina por equipo y otra, el número de integrantes de cada equipo. Si un equipo tiene una sola persona, combinar ambas respuestas podría revelar su salario. El ejemplo no describe un incidente observado; plantea una pregunta distinta a comprobar si cada llamada está autorizada.

La propuesta del participante fue evaluar la consulta combinada dentro de una herramienta sujeta a políticas o impedir que las dos respuestas puedan cruzarse. En sistemas que consultan datos sensibles, ese caso invita a considerar qué información puede inferirse a partir de varias salidas, además de los permisos concedidos a cada herramienta por separado.