AgentCore сохраняет права пользователя при вызове ServiceNow без самописного обмена токенов

Корпоративный AI-агент умеет открыть инцидент в ServiceNow, но возникает неприятный вопрос: от чьего имени он это делает? Если все запросы приходят под технической учётной записью приложения, ServiceNow перестаёт видеть реального инициатора. Журнал аудита показывает шлюз вместо сотрудника, пользовательские ограничения не работают как задумано, а агент может получить больше прав, чем нужно.

AWS добавила в Amazon Bedrock AgentCore Gateway нативный обмен токенов по схеме On-Behalf-Of, или OBO. Шлюз принимает токен пользователя, обращается к Microsoft Entra ID и получает другой токен — уже предназначенный для API ServiceNow, но по-прежнему связанный с исходным пользователем. Самописный посредник для такого обмена больше не требуется.

Как это выглядит на простом примере

Допустим, сотрудник просит агента показать активные инциденты. Сначала пользователь получает JWT для приложения агента. В поле audience этого токена указан идентификатор агента, поэтому ServiceNow такой токен не примет: корпоративная система ожидает токен, выпущенный для её собственного API-коннектора.

Агент передаёт JWT в AgentCore Gateway. Шлюз отправляет его в Entra ID вместе с учётными данными приложения, целевым scope и параметром requested_token_use со значением on_behalf_of. Entra проверяет разрешённое делегирование и выпускает новый токен с audience коннектора ServiceNow, сохраняя данные пользователя.

Дальше Gateway вызывает REST API ServiceNow. Платформа сопоставляет claim preferred_username, например рабочую почту, с существующей записью сотрудника и применяет его роли. Если человек может только читать инциденты, агент также не сможет их менять. В журнале остаётся понятный след: действие связано с пользователем, который дал команду.

Что придётся настроить

В Microsoft Entra ID нужны две регистрации приложений: одна представляет AI-агента, другая — API-коннектор ServiceNow. Коннектор публикует делегированный scope user_impersonation, а приложению агента выдаётся разрешение запрашивать этот scope.

В ServiceNow создаётся входящая OAuth-интеграция с OIDC-провайдером Entra. Важно правильно сопоставить пользовательский claim и ограничить auth scope только теми API, которые действительно нужны агенту. Например, шлюзу для просмотра инцидентов незачем открывать доступ ко всем таблицам платформы.

В AgentCore создаётся исходящая OAuth-конфигурация с JWT authorization grant. Затем поднимается Gateway с версией MCP 2025-11-25: более ранние версии не поддерживают нативный OBO. Для REST-цели указываются scope коннектора и параметр requested_token_use:on_behalf_of. После этого обмен выполняется автоматически при каждом запросе.

Где можно ошибиться

Нативный обмен токенов не отменяет аккуратную настройку доступа. Пользователь из preferred_username должен существовать в ServiceNow, приложение агента обязано иметь делегированное разрешение, а auth scope — разрешать вызываемый endpoint. Ошибка в любом из этих мест закончится отказом авторизации.

Отдельного внимания заслуживает защита от повторного использования токена. Entra передаёт внутренний claim uti вместо стандартного jti. AWS предлагает рассмотреть его сопоставление с jti, чтобы ServiceNow мог применять дополнительную проверку и блокировку токенов. Guardrails тоже не заменяют авторизацию: они фильтруют содержимое, тогда как OBO определяет, имеет ли пользователь право выполнить действие.

Практический вывод простой: если агент работает с корпоративными системами, не прячьте всех пользователей за одной сервисной учётной записью. Передавайте личность по всей цепочке, сужайте scope до необходимых операций и отдельно тестируйте сценарии для сотрудников с разными ролями. Именно на границе между агентом и бизнес-системой решается, станет автоматизация управляемой или превратится в новую привилегированную дыру.