AgentCore preserva as permissões do usuário ao chamar o ServiceNow sem troca de tokens personalizada

Um agente de IA corporativo consegue abrir um incidente no ServiceNow, mas surge uma pergunta incômoda: em nome de quem ele faz isso? Se todas as requisições chegam com a conta técnica do aplicativo, o ServiceNow deixa de enxergar o verdadeiro solicitante. O log de auditoria mostra o gateway em vez do funcionário, as restrições de usuário não funcionam como planejado e o agente pode acabar com mais permissões do que precisa.

A AWS adicionou ao Amazon Bedrock AgentCore Gateway a troca nativa de tokens pelo esquema On-Behalf-Of (OBO). O gateway recebe o token do usuário, consulta o Microsoft Entra ID e obtém outro token, já destinado à API do ServiceNow, mas ainda vinculado ao usuário original. Não é mais necessário um intermediário próprio para essa troca.

Como isso funciona em um exemplo simples

Suponha que um funcionário peça ao agente para mostrar os incidentes ativos. Primeiro, o usuário obtém um JWT para o aplicativo do agente. No campo audience desse token consta o identificador do agente, por isso o ServiceNow não o aceitará: o sistema corporativo espera um token emitido para o seu próprio conector de API.

O agente entrega o JWT ao AgentCore Gateway. O gateway o envia ao Entra ID junto com as credenciais do aplicativo, o scope de destino e o parâmetro requested_token_use com o valor on_behalf_of. O Entra verifica a delegação permitida e emite um novo token com o audience do conector do ServiceNow, preservando os dados do usuário.

Em seguida, o Gateway chama a API REST do ServiceNow. A plataforma associa o claim preferred_username, por exemplo o e-mail corporativo, a um registro de funcionário existente e aplica seus papéis. Se a pessoa só pode ler incidentes, o agente também não poderá alterá-los. No log fica um rastro claro: a ação está vinculada ao usuário que deu o comando.

O que será preciso configurar

No Microsoft Entra ID são necessários dois registros de aplicativo: um representa o agente de IA e o outro, o conector de API do ServiceNow. O conector publica um scope delegado, user_impersonation, e o aplicativo do agente recebe permissão para solicitar esse scope.

No ServiceNow, cria-se uma integração OAuth de entrada com o Entra como provedor OIDC. É importante mapear corretamente o claim do usuário e limitar o auth scope apenas às APIs de que o agente realmente precisa. Por exemplo, um gateway que apenas consulta incidentes não tem motivo para abrir acesso a todas as tabelas da plataforma.

No AgentCore, cria-se uma configuração OAuth de saída com JWT authorization grant. Depois, sobe-se um Gateway com a versão de MCP 2025-11-25: versões anteriores não oferecem suporte ao OBO nativo. Para o destino REST, informam-se o scope do conector e o parâmetro requested_token_use:on_behalf_of. A partir daí, a troca ocorre automaticamente a cada requisição.

Onde é possível errar

A troca nativa de tokens não dispensa uma configuração de acesso cuidadosa. O usuário de preferred_username precisa existir no ServiceNow, o aplicativo do agente deve ter a permissão delegada e o auth scope tem de permitir o endpoint chamado. Um erro em qualquer um desses pontos terminará em recusa de autorização.

A proteção contra a reutilização de tokens merece atenção especial. O Entra passa um claim interno uti em vez do padrão jti. A AWS sugere considerar seu mapeamento para jti, para que o ServiceNow possa aplicar validação adicional e bloqueio de tokens. Os guardrails também não substituem a autorização: eles filtram o conteúdo, ao passo que o OBO determina se o usuário tem direito de executar a ação.

A conclusão prática é simples: se um agente trabalha com sistemas corporativos, não esconda todos os usuários atrás de uma única conta de serviço. Repasse a identidade por toda a cadeia, restrinja o scope às operações necessárias e teste separadamente os cenários para funcionários com papéis diferentes. É na fronteira entre o agente e o sistema de negócio que se decide se a automação será governável ou se tornará uma nova brecha privilegiada.