AWS опубликовала вторую часть руководства по управлению доступом ИИ-агентов через Okta Cross App Access и Amazon Bedrock AgentCore, перенеся проверки токенов из отдельных MCP-серверов в центральный AgentCore Gateway. Схема добавляет политики Cedar, второго агента в Amazon EKS и совместный аудит в CloudWatch, а доработка занимает около 90 минут. Это важно, поскольку предприятия с сотнями агентов не могут поддерживать логику авторизации внутри каждого инструмента.
Шлюз, политики и аудит вместо проверок в серверах
В первой части использовался один агент задач в среде AgentCore runtime, два MCP-сервера и код авторизации внутри каждого сервера. Okta определяла, какой агент может действовать от имени какого пользователя, а AgentCore Identity погашала грант Okta внутри агента. Конфигурация Okta, провайдер учетных данных Identity и MCP-серверы сохраняются, а основой служит пример AWS 08-okta-xaa-delegation-chain на GitHub. Фрагменты кода в публикации носят концептуальный характер и предназначены только для непроизводственного использования.
AgentCore Gateway становится единой точкой входа и погашает грант Okta для каждой цели через TOKEN_EXCHANGE с помощью существующего провайдера учетных данных. Его входящий авторизатор использует сервер авторизации организации Okta как issuer, отдельный сервер авторизации как audience и allowedClients, привязанный к одному агенту. Каждый MCP-сервер становится целью шлюза, причем области доступа цели должны совпадать с областями ID-JAG. Агент A теперь передает входящий ID-JAG шлюзу, а не обращается к Identity самостоятельно.
Надежность целей шлюза определяют три детали реализации. Целям нужна статическая схема инструментов с listingMode DEFAULT и встроенной mcpToolSchema, чтобы имена инструментов в политиках Cedar оставались фиксированными. Шлюз разбивает tools/list по целям на страницы, поэтому клиент должен следовать курсору пагинации, иначе инструменты поздних целей исчезнут. Identity сохраняет токен обмена шлюза, поэтому один одноразовый ID-JAG обслуживает все вызовы инструментов сессии, а в тестах — и вторую сессию в пределах 5 минут жизни.
Что означает централизованный контроль доступа агентов
Для компаний с несколькими агентами изменение убирает разрешения на обмен токенами и секреты из ролей исполнения агентов и концентрирует их в роли шлюза. Каждый агент получает собственный шлюз и провайдера учетных данных, поскольку провайдер аутентифицируется как один агент Okta. Агент отчетности B выполняет тот же код в EKS с собственной регистрацией Okta, шлюзом, провайдером и соединением ресурсов только с xaa: read. EKS Pod Identity ограничивает под вызовом моделей и записью собственных журналов и трассировок.
Применение политик выполняет механизм AgentCore Policy, подключенный к шлюзу в режиме ENFORCE, с разрешающими политиками Cedar. Cedar раскрывает утверждения JWT как теги, связывает инструменты с агентом и делегированной областью и требует проверок hasTag, поскольку политика с отсутствующим тегом пропускается. Сопоставление областей трактует xaa: write как целое значение, поэтому xaa: write-admin не подходит, а параллельная политика разрешает инструменты чтения с xaa: read. Механизм с несозданными политиками оставляет шлюз отклоняющим все вызовы, поэтому политики должны иметь статус ACTIVE.
Наблюдаемость связывает спены Runtime, Gateway, Identity и Policy со спенами приложений через Transaction Search и доставку трассировок в CloudWatch. Системный журнал Okta System Log передается в CloudWatch Omni как traces. default, поэтому один запрос соединяет грант ID-JAG с последующими разрешениями и запретами. В примере пользователя Alice грант xaa: read xaa: write сменяется запретом create_task через 16.7 секунды и разрешением list_tasks. Настройка ADOT требует botocore для определения региона и подписи, а также OTEL_PYTHON_DISABLED_INSTRUMENTATIONS, чтобы контекст трассировки BFF доходил до агента.
