«Данные остаются у подразделений, агент один»: AWS описала мультиаккаунтную схему на AgentCore Gateway и MCP

Что именно предлагает AWS

Команда AWS Machine Learning Blog опубликовала разбор референсной архитектуры, в которой агент работает централизованно, а данные остаются распределёнными по аккаунтам линий бизнеса (line of business, LOB). Платформенный аккаунт запускает агента через Amazon Bedrock и AgentCore, а каждая линия бизнеса выставляет свои данные как MCP-сервер со своим авторизатором — так команда подразделения сама решает, кого пускать к своим инструментам.

Ключевая идея в том, что платформа не получает копий данных: у неё появляется единая точка аутентифицированного доступа к инструментам, а хранение и права остаются в аккаунте подразделения. Масштабирование заявлено как добавление одной цели (target) в Gateway: агент обнаруживает новые инструменты на следующем вызове, а не требует переписывания кода.

Четыре аккаунта и путь одного запроса

В примере развёрнуты четыре аккаунта: платформенный и три линии — retail banking, transaction banking и lending & wealth. Пользователь логинится через Okta и получает JWT; запрос идёт через Amazon CloudFront на веб-приложение на Amazon ECS с Fargate (React и FastAPI), оттуда — в AgentCore Runtime, где работает Strands-агент с авторизатором custom JWT.

Дальше агент обращается к Amazon Bedrock (в примере — Claude Sonnet с Guardrails: reasoning и фильтр PII), а авторизацию вызова инструментов выполняет Policy in AgentCore: агент передаёт дальше пользовательский JWT, и Cedar-движок проверяет утверждения (claims) до маршрутизации каждого вызова. Сам Gateway работает по протоколу MCP с семантическим поиском по инструментам, а за качество отвечает контур AgentCore Evaluations и Optimization, тогда как Agent Registry отвечает за обнаружение линий бизнеса.

В каждой линии бизнеса развёрнут свой AgentCore Runtime как MCP-сервер с авторизатором OAuth M2M: в примере это шесть инструментов розничного банка, четыре платёжных и шесть кредитных. Данные лежат локально — Amazon DynamoDB с клиентами, счетами, платежами и кредитными скорами, а кредитная линия дополнительно поднимает Amazon Bedrock Knowledge Bases с PDF-политиками на S3 и OpenSearch Serverless.

Аутентификация: M2M-токены и отказ по умолчанию

Gateway настраивается с авторизатором CUSTOM_JWT: в конфигурации указываются discovery-URL Okta и разрешённая аудитория (в примере — lobfederation), а поддерживаемая версия MCP зафиксирована как 2025-03-26. Для исходящих вызовов к MCP-серверам линий бизнеса платформа регистрирует провайдера учётных данных в AgentCore Identity и использует OAuth 2.0 client credentials — машинный обмен токенами (M2M): Identity получает свежий access token у Okta и подставляет его в заголовок Authorization.

Авторы честно оговаривают причину выбора: в примере применён M2M, потому что используемый разработческий аккаунт Okta не поддерживает обмен токена с действующим пользователем (on-behalf-of, OBO). AgentCore Gateway также поддерживает authorization code grant и API-ключи; OBO нужен там, где MCP-сервер сам должен применять построчные ограничения доступа.

Права подразделений защищены отдельно: линия бизнеса сама настраивает, кто может вызывать её MCP-сервер, через конфигурацию JWT-авторизатора. Даже если платформа добавит новую цель в Gateway, MCP-сервер отклонит неаутентифицированный запрос — это согласование не зависит от платформенной команды. Policy in AgentCore работает в режиме ENFORCE по модели default-deny: в примере чтение (get_balance и другие read-only инструменты) разрешено всем аутентифицированным пользователям, перевод средств (transfer_funds) ограничен конкретной ролью, а удаление клиента (delete_customer) запрещено полностью.

Эксплуатация: оценки, версии и наблюдаемость

Для мультиаккаунтной схемы, где агент вызывает инструменты многих подразделений, AWS предлагает непрерывную оценку качества: online evaluation автоматически оценивает выборку живого трафика (например, 10% сессий) встроенными оценщиками — точностью выбора инструмента, корректностью и долей достигнутых целей. Результаты видны в дашборде AgentCore Observability на базе Amazon CloudWatch, где можно включить оповещения при падении качества; изменений в коде не требуется, если агент уже отправляет трейсы OpenTelemetry.

Это ловит тихую деградацию, которую не заметить по задержкам и ошибкам: например, агент начал отправлять кредитные запросы не в ту линию бизнеса. Для CI/CD есть on-demand evaluation: набор сценариев с ожидаемыми ответами, траекториями инструментов и утверждениями о цели прогоняется на каждое изменение, причём используются те же оценщики, что и в проде. Замыкает контур AgentCore Optimization — разбирает трейсы и рекомендует правки промптов и описаний инструментов с проверкой до выката.

Версии разводятся по эндпоинтам prod, staging и dev, указывающим на конкретные версии агента: при обновлении промпта или модели публикуется новая версия и переключается эндпоинт, а MCP-серверы подразделений не затрагиваются, потому что интерфейс инструментов не меняется. Перед повышением версии можно разделить живой трафик между текущей и кандидатной версиями через A/B-тестирование в Gateway и закрепить победившую конфигурацию по достижении статистической значимости.

Сеть, guardrails и аудит

Пример работает в публичном сетевом режиме AgentCore Runtime: трафик идёт по HTTPS с OAuth, что авторы называют подходящим для разработки, но не для продакшена. Для продакшена AgentCore Runtime поддерживает подключение к VPC через elastic network interfaces, интерфейсный VPC-эндпоинт поверх AWS PrivateLink для приватного входа в Gateway и параметр allowedWorkloadConfiguration, ограничивающий вызов runtime только своим Gateway.

Guardrails применяются централизованно в платформенном аккаунте: Amazon Bedrock Guardrails отвечает за фильтрацию контента, удаление PII и тематические ограничения, и поскольку инференс централизован, одна конфигурация покрывает взаимодействия агента со всеми инструментами подразделений. Как более новый вариант AWS предлагает применять Guardrails прямо как политики на AgentCore Gateway — тогда проверки выполняются на уровне шлюза, вне кода агента.

Аудит строится из двух слоёв: доставка логов Gateway в Amazon CloudWatch Logs фиксирует вызовы инструментов и метаданные запросов, а AWS CloudTrail по умолчанию пишет операции контрольной плоскости — создание и изменение шлюзов, runtime, целей и политик. Чтобы захватывать и отдельные вызовы инструментов, нужно включить логирование событий данных с расширенным селектором; для централизованного аудита настраивается трейл уровня организации, собирающий логи платформенного и бизнес-аккаунтов в отдельный аккаунт логирования.

Стоимость, границы и что осталось за кадром

Архитектура даёт естественные границы затрат: расходы на данные (DynamoDB, Knowledge Bases, вычисления MCP-серверов) остаются в аккаунте подразделения и видны в AWS Cost Explorer, а инференс модели и вызовы Gateway накапливаются в платформенном аккаунте. Чтобы разнести их по линиям бизнеса, роль агента несёт теги (например, lob или costCenter): после активации тега распределения затрат в консоли биллинга они попадают в AWS Cost and Usage Report, а трейс инструментов показывает, какая линия что вызывала, — это и даёт пропорциональное отнесение затрат.

Стоит помнить, что это референсная реализация, а не отчёт о работающей системе: авторы не приводят ни клиентов, ни замеров производительности, а сам пример демонстрирует M2M вместо OBO из-за ограничений разработческого аккаунта Okta. Для уборки после развёртывания в репозитории приложен скрипт очистки: он удаляет ресурсы четырёх аккаунтов в обратном порядке — сначала агента и MCP-серверы, затем цели Gateway и конфигурацию Policy in AgentCore, затем CDK-стек с таблицами DynamoDB, бакетами S3, репозиториями ECR и кластерами ECS.

Материал подписали Senthil Kamala Rathinam (старший solutions architect по данным и аналитике для банков), Karthik Tharmarajan (старший solutions architect по генеративному ИИ в финансовом секторе) и Shashi Makkapati (старший solutions architect по банковским клиентам) — все из AWS.