AgentCore conserva los permisos del usuario al llamar a ServiceNow sin un intercambio de tokens propio

Un agente de IA corporativo puede abrir un incidente en ServiceNow, pero surge una pregunta incómoda: ¿en nombre de quién lo hace? Si todas las solicitudes llegan con la cuenta técnica de la aplicación, ServiceNow deja de ver al verdadero iniciador. El registro de auditoría muestra el gateway en lugar del empleado, las restricciones de usuario no funcionan como se pensó y el agente puede obtener más permisos de los necesarios.

AWS ha añadido a Amazon Bedrock AgentCore Gateway el intercambio nativo de tokens con el esquema On-Behalf-Of (OBO). El gateway recibe el token del usuario, se dirige a Microsoft Entra ID y obtiene otro token, ya destinado a la API de ServiceNow pero todavía vinculado al usuario original. Ya no hace falta un intermediario propio para este intercambio.

Cómo se ve en un ejemplo sencillo

Supongamos que un empleado le pide al agente que muestre los incidentes activos. Primero, el usuario obtiene un JWT para la aplicación del agente. En el campo audience de este token figura el identificador del agente, por lo que ServiceNow no lo aceptará: el sistema corporativo espera un token emitido para su propio conector de API.

El agente entrega el JWT a AgentCore Gateway. El gateway lo envía a Entra ID junto con las credenciales de la aplicación, el scope de destino y el parámetro requested_token_use con el valor on_behalf_of. Entra verifica la delegación permitida y emite un nuevo token con el audience del conector de ServiceNow, conservando los datos del usuario.

A continuación, Gateway llama a la API REST de ServiceNow. La plataforma hace corresponder el claim preferred_username, por ejemplo el correo de trabajo, con un registro de empleado existente y aplica sus roles. Si la persona solo puede leer incidentes, el agente tampoco podrá modificarlos. En el registro queda un rastro claro: la acción está vinculada al usuario que dio la orden.

Qué hay que configurar

En Microsoft Entra ID se necesitan dos registros de aplicación: uno representa al agente de IA y el otro, al conector de API de ServiceNow. El conector publica un scope delegado, user_impersonation, y a la aplicación del agente se le concede permiso para solicitar ese scope.

En ServiceNow se crea una integración OAuth entrante con Entra como proveedor OIDC. Es importante hacer corresponder correctamente el claim de usuario y limitar el auth scope únicamente a las API que el agente realmente necesita. Por ejemplo, un gateway que solo consulta incidentes no tiene motivo para abrir el acceso a todas las tablas de la plataforma.

En AgentCore se crea una configuración OAuth saliente con JWT authorization grant. Después se levanta un Gateway con la versión de MCP 2025-11-25: las versiones anteriores no admiten OBO nativo. Para el destino REST se indican el scope del conector y el parámetro requested_token_use:on_behalf_of. A partir de ahí, el intercambio se realiza automáticamente en cada solicitud.

Dónde se puede fallar

El intercambio nativo de tokens no sustituye una configuración de acceso cuidadosa. El usuario de preferred_username debe existir en ServiceNow, la aplicación del agente debe tener el permiso delegado y el auth scope debe permitir el endpoint al que se llama. Un error en cualquiera de estos puntos terminará en un rechazo de autorización.

La protección frente a la reutilización de tokens merece una atención aparte. Entra transmite un claim interno uti en lugar del estándar jti. AWS sugiere valorar su correspondencia con jti para que ServiceNow pueda aplicar una validación adicional y el bloqueo de tokens. Los guardrails tampoco sustituyen la autorización: filtran el contenido, mientras que OBO determina si el usuario tiene derecho a ejecutar la acción.

La conclusión práctica es sencilla: si un agente trabaja con sistemas corporativos, no oculte a todos los usuarios tras una única cuenta de servicio. Transmita la identidad a lo largo de toda la cadena, reduzca el scope a las operaciones necesarias y pruebe por separado los escenarios para empleados con distintos roles. Es en la frontera entre el agente y el sistema de negocio donde se decide si la automatización será gobernable o se convertirá en un nuevo agujero con privilegios.