Okta и AgentCore берут ИИ-агентов под контроль: отзыв доступа за 1 секунду

Агент, который обновляет тикет или читает карточку клиента, работает от имени человека и внутри приложений, куда у этого человека есть доступ. Для команды безопасности отсюда вытекает неудобный вопрос: какой именно агент вправе действовать за какого пользователя в каком приложении, и как его остановить. Согласия OAuth в каждом приложении по отдельности и общие сервисные аккаунты на него не отвечают. AWS в первой части разбора предлагает ответ на связке Okta Cross App Access (XAA) и Amazon Bedrock AgentCore.

Кто за что отвечает

Распределение простое. Okta — плоскость управления: она решает, какой агент может действовать за какого пользователя и в отношении какого ресурса. AgentCore Identity — плоскость исполнения: хранит учётные данные агента, превращает решение Okta в токен, который примет ресурс, и сохраняет в нём обе личности — и пользователя, и агента.

В каждом запросе участвуют три токена. ID-токен говорит, кто пользователь. ID-JAG — это собственно решение Okta: он одноразовый и живёт 5 минут. Access-токен — то, что принимает целевой ресурс; он тоже живёт 5 минут, называет и пользователя, и агента и несёт группы пользователя.

Цепочка выглядит так. Пользователь входит во фронтенд (BFF) через OpenID Connect. BFF меняет его ID-токен на ID-JAG в Okta по RFC 8693, аутентифицируясь как агент. Okta проверяет, что агент активен, пользователь к нему назначен, а администратор подключил агента к нужному серверу авторизации с нужными скоупами. Дальше BFF вызывает агента в AgentCore runtime с ID-JAG в качестве bearer-токена, а JWT-авторизатор рантайма пропускает только ID-JAG, выданные Okta именно этому агенту. Затем AgentCore Identity обменивает ID-JAG на access-токен по RFC 7523, и агент ходит с ним на MCP-серверы. Task manager проверяет, что токен получил зарегистрированный агент и что группа и скоуп пользователя разрешают конкретный инструмент.

Где легко споткнуться

Авторы честно перечисляют грабли, на которые наступили сами.

Во-первых, Okta отклоняет запрос ID-JAG, если в нём есть скоупы OpenID Connect вроде openid или profile (ошибка invalid_scope). Нужен минимум один кастомный скоуп и ни одного стандартного.

Во-вторых, ID-токен должен прийти из того же приложения, что связано с агентом. Токен из другого приложения ломает обмен с ошибкой о том, что клиент не зарегистрирован для делегирования.

В-третьих, для каждого агента Okta нужен свой credential provider: попытка погасить ID-JAG одного агента от имени другого заканчивается отказом из-за несовпадения client_id.

В-четвёртых, SDK хранит workload access token в BedrockAgentCoreContext, а не в заголовках запроса. Первая версия авторов искала его в заголовках, не находила и на всех 21 проверенном запросе уходила в запасной путь со вторым workload identity. Токен нужно читать из контекста.

Наконец, в IAM-политике сегмент ARN пишется как oauth2credentialprovider, без дефиса; с дефисом каждый вызов падал с AccessDeniedException. Роли агента при этом достаточно двух statement: GetResourceOauth2Token и чтение секрета провайдера.

Цифры и ограничения

После того как администратор снял назначение пользователя на агента, Okta отказывала новым запросам примерно за 1 секунду, а уже выданные токены истекали в течение 5 минут. Первый вызов с погашением ID-JAG занял около полусекунды, а AgentCore Identity в сумме добавил примерно 0,6 с к запросу длиной около 30 с. Второй вызов к другому MCP-серверу вернул тот же токен из хранилища в среднем за 58 мс, без повторного погашения одноразового ID-JAG. Новый ID-JAG для того же пользователя даёт новый токен, так что каждый запрос отражает актуальное решение Okta.

Оговорки: код — учебный пример для непродакшена, фрагменты показывают паттерн, а не готовое решение. Тесты шли на бесплатном Okta Integrator, в одном регионе AWS (Орегон). Walkthrough занимает около часа. Для продакшена нужны MFA, ротация секрета (или Private Key JWT вместо общего секрета) и согласование с безопасностью и юристами.

Что делать

Если ваши агенты ходят во внутренние системы через общий сервисный аккаунт, это повод пересмотреть схему. Заведите агента как отдельную сущность в IdP, ограничьте скоупы, держите токены короткими, а права пользователя проверяйте в самих инструментах, а не только на входе. Вторая часть обещает то же с AgentCore Gateway, политиками Cedar, агентом на EKS и аудитом в CloudWatch.