- Дата публикации
Amazon Bedrock AgentCore Gateway научили ходить в OAuth‑защищённые MCP‑серверы без хранения токенов в коде
Что появилось / что изменилось
Amazon добавила в AgentCore Gateway поддержку OAuth 2.0 Authorization Code Flow для подключения к защищённым MCP‑серверам.
Главные изменения:
- AgentCore Gateway можно использовать как единый endpoint для множества MCP‑серверов — от внутренних до сторонних (AWS, GitHub, Salesforce, Databricks).
- Появилась поддержка Authorization Code Flow через Amazon Bedrock AgentCore Identity: агент авторизуется от имени пользователя, не храня логин/пароль или токены в коде.
- Два режима подключения OAuth‑защищённых MCP‑серверов:
- Имплицитная синхронизация: админ проходит Authorization Code Flow при создании или обновлении цели (CreateGatewayTarget, UpdateGatewayTarget, SynchronizeGatewayTargets), а Gateway сам подтягивает и кэширует список инструментов MCP‑сервера.
- Схема инструментов заранее: админ сразу передаёт схему инструментов в CreateGatewayTarget или UpdateGatewayTarget. Gateway парсит схему и кэширует инструменты, без интерактивной авторизации на этапе создания.
- Для второго метода операция SynchronizeGatewayTargets недоступна, потому что список инструментов задаёт админ, а не MCP‑сервер.
- Пользователь AgentCore Gateway может вызывать
list/toolsи получать кэшированный список инструментов без мгновенной авторизации в MCP‑сервере. Authorization Code Flow запускается только при реальном вызове инструмента.
Как это работает
AgentCore Gateway становится прослойкой между AI‑агентами (IDE, клиенты MCP) и набором MCP‑серверов.
Роли:
- Gateway user — конечный пользователь, который через MCP‑клиент ходит только на один URL AgentCore Gateway и пользуется доступными ему инструментами.
- Admin user — администратор, который подключает MCP‑серверы, инструменты и API к Gateway и настраивает, какие цели доступны пользователям.
- MCP‑сервер — сервер инструментов, защищённый OAuth 2.0 Authorization Code Flow и требующий участия пользователя в авторизации.
Authorization Code Flow работает так:
- Агент через Gateway пытается вызвать инструмент на MCP‑сервере.
- Если у Gateway нет валидного токена для этого пользователя и сервера, он инициирует Authorization Code Flow через настроенный провайдер идентичности.
- Пользователь проходит аутентификацию у своего identity‑провайдера или авторизационного сервера MCP.
- Gateway получает authorization code, обменивает его на access token и кэширует токен.
- Дальше Gateway вызывает MCP‑сервер уже от имени пользователя, используя полученный токен.
Два сценария подключения MCP‑таргета:
- Имплицитная синхронизация: админ при создании/обновлении цели сам проходит OAuth‑авторизацию. Gateway по этому токену ходит в MCP‑сервер, забирает список инструментов, кэширует и обновляет их через SynchronizeGatewayTargets.
- Схема заранее: админ сразу даёт схему инструментов. Gateway не обращается к MCP‑серверу за списком инструментов, а использует предоставленное описание. Это удобно, если автоматизация не позволяет интерактивно логиниться при каждом обновлении, или если нужно скрыть часть инструментов MCP‑сервера.
Что это значит для вас
Если вы строите агентов на Amazon Bedrock и у вас несколько MCP‑серверов с OAuth 2.0 Authorization Code Flow, теперь не нужно настраивать авторизацию в каждом IDE и клиенте отдельно. Всё замыкается на один URL AgentCore Gateway.
Кому это полезно:
- Энтерпрайз‑командам с десятками MCP‑серверов (внутренние API, GitHub, Salesforce, Databricks и другие). Управление авторизацией, политиками и маршрутизацией переезжает в один центр.
- Разработчикам агентов: не нужно вшивать секреты в код, хранить токены, писать свою логику обновления токенов и обрабатывать разные OAuth‑реализации.
- Безопасности и комплаенсу: можно централизованно контролировать, какие инструменты MCP доступны конкретным пользователям и группам, и не раздавать прямой доступ к каждому серверу.
Где это особенно удобно:
- Когда один Gateway подключён к нескольким MCP‑серверам. Пользователь видит единый список инструментов, а авторизация запускается только при первом вызове конкретного инструмента.
- Когда нельзя интерактивно проходить OAuth на CI/CD или в автоматизированных скриптах — тогда имеет смысл заранее описывать схему инструментов и не использовать синхронизацию.
Где будет сложнее:
- Если у вас только один простой MCP‑сервер без OAuth, добавление AgentCore Gateway может быть лишним уровнем сложности.
- Если бизнес‑процесс требует очень частых изменений схемы инструментов, а вы выбрали метод с ручной схемой, админам придётся чаще обновлять конфигурацию.
Amazon Bedrock официально недоступен в России. Для работы придётся использовать аккаунт в поддерживаемом регионе и, вероятно, VPN и зарубежную платёжную инфраструктуру.
Место на рынке
AgentCore Gateway решает задачу, на которую у конкурентов пока нет стандартизированного ответа: единый шлюз именно для MCP‑серверов с централизованной авторизацией и кэшированием инструментов.
Сравнивать по скорости, цене запросов или объёму контекста здесь некорректно — это не LLM, а инфраструктурный слой поверх уже выбранных моделей и MCP‑серверов. Он не ускоряет сами модели и не удешевляет токены, а убирает операционный и безопасностный хаос вокруг множества точек интеграции.
Если вы уже сидите на экосистеме Amazon Bedrock и начинаете разрастаться по числу агентов и MCP‑серверов, AgentCore Gateway с поддержкой Authorization Code Flow выглядит логичным центром управления. Если же ваш стек строится вокруг других облаков и вы не используете MCP, выгода от перехода будет минимальной, и придётся учитывать миграционные риски и юридические ограничения по доступу к AWS из России.