MoEngage открыла ИИ-агентам 400 закрытых API через AgentCore Gateway без своих MCP-серверов

Компания MoEngage делает платформу, через которую более 1350 потребительских брендов отправляют персонализированные push, email, SMS, WhatsApp и RCS-сообщения. Когда в компании взялись за ИИ-агентов, выяснилось, что всё нужное уже работает: создание кампаний, запросы к сегментам, статистика доставки. Это около 400 внутренних REST API, их написали 25 команд, и живут они в закрытых облачных сетях (VPC) семи регионов AWS. Наружу их не выставляют из-за требований к хранению данных в регионе. Задача была в том, чтобы безопасно подпустить к ним агентов. Решение: управляемый шлюз Amazon Bedrock AgentCore Gateway. По оценке MoEngage, он сэкономил около шести месяцев платформенной разработки. Это внутренняя оценка компании, независимо её никто не проверял.

Почему 20 MCP-серверов — плохая идея

MCP (Model Context Protocol) — стандарт, по которому агент узнаёт, какие у него есть инструменты, и вызывает их. Очевидный путь: каждая команда поднимает свой MCP-сервер. MoEngage посчитала, во что это выльется:

• больше 20 развёртываний, которые надо мониторить, патчить и подгонять под эволюцию протокола; • агентам, которым нужны данные из разных доменов (кампания, её сегмент, статистика доставки), придётся подключаться к нескольким серверам и сводить ответы; • каждой продуктовой команде понадобится экспертиза в MCP, не связанная с её настоящей работой.

Поэтому правило такое: команды MCP не пишут. Они делают REST API и размечают, какие операции считать инструментами. Весь слой MCP ведёт команда AI Platform. Зона ответственности продуктовой команды заканчивается хорошо написанной спецификацией OpenAPI.

Под это правило компания сформулировала четыре жёстких условия, которые должны выполняться одновременно:

• никаких публичных адресов: ни NAT-шлюзов, ни прокси, ни VPN на каждую интеграцию, иначе умножаем на семь регионов; • личность вызова не решение модели: tenant, пользователь, роль и контекст базы данных не могут быть параметрами, которые модель способна ошибочно поменять или которые её можно уговорить изменить; • каталог из 400 инструментов не должен лезть в контекст: при примерно 50 токенах схемы на инструмент полный список — это свыше 20 000 токенов на каждое подключение; • фильтр на клиенте не считается защитой: если каталог уже передан, агент увидел лишнее.

Как AgentCore Gateway закрывает эти условия

Шлюз работает как полностью управляемый MCP-сервер. Вы регистрируете спецификации OpenAPI как цели, а он сам генерирует инструменты и маршрутизирует вызовы. Каждая операция получает имя вида Target___operationId, например CampaignsAPI___searchCampaigns. Добавили эндпоинт в спецификацию — инструмент появился, убрали — исчез. Ни деплоя, ни согласований с платформенной командой.

Доступ ограничивают политики на языке Cedar. Каждый агент аутентифицируется под собственной IAM-ролью. Движок политик отбирает инструменты ещё до формирования ответа на tools/list. Бот для проверки кампаний, например, получает группу инструментов campaigns-read и явный запрет на группу write-actions. Инструментов записи в его списке просто нет: их не отправили, а не скрыли на клиенте.

Связность обеспечивает управляемый выход (egress) через Amazon VPC Lattice. Входящий трафик идёт только через интерфейсную точку VPC с приватным DNS. Новый API добавляет цель в шлюз и не меняет сетевую топологию. Сеть настраивается один раз.

Ещё три решения, которые стоит перенять:

• SigV4 вместо JWT: внутренние агенты и так сервисы с IAM-ролями, так что они подписывают запросы теми ключами, что уже есть, и ничего нового выдавать и ротировать не надо. Публичный MCP-сервер MoEngage для людей из Claude и других клиентов отдельно работает на OIDC JWT; • личность в заголовках: клиентская библиотека превращает небольшой объект Identity в заголовки X-MOE-*. Модель их не видит. Поскольку SigV4 занимает заголовок Authorization, чужой bearer-токен пересылают в отдельном заголовке с префиксом MoEngage; • поиск вместо списка: модели показывают один мета-инструмент search_tools. Агент описывает задачу, семантический поиск шлюза возвращает кандидатов, и только они становятся вызываемыми до конца хода. Если get_segment_user_count переименуют в get_segment_size, поиск по смыслу всё равно найдёт его.

Подключение API за часы и опыт трёх месяцев в проде

Команда добавляет в свою спецификацию блок x-moe-mcp. Выставление наружу — явное согласие: нет блока, нет инструмента, и CI об этом не предупреждает. Прогрев кэша и миграции агентам не нужны. Флаги internal и external независимо открывают операцию внутренним агентам, публичному MCP-серверу или обоим.

Отдельное наблюдение: описание API для разработчика плохо работает как описание инструмента для модели. Когда MoEngage вставляла «Returns a paginated list» дословно, модели выбирали инструмент по деталям реализации, а не по намерению. Теперь поля tool_description и param_overrides дают место для текста, написанного для модели, не трогая документацию для людей. Остальное делает CI: проверяет блок, регистрирует цель в шлюзе и применяет политику Cedar.

Сейчас система работает в семи регионах и обслуживает около 400 операций для 10 внутренних агентов. Среди них агент проверки кампаний (правила таргетинга и контент до запуска), агент здоровья доставки (скорость отправки и всплески bounce по каналам) и конструктор сегментов (превращает описание аудитории на естественном языке в запрос). У каждого своя роль и свой набор инструментов. Новые агенты стартуют без жёстко прописанных имён инструментов: описали намерение, получили кандидатов, вызвали. Переименование или новая операция подхватывается без правки кода. Подключение нового API, по словам компании, теперь занимает часы вместо дней.

Для инженеров вывод такой: если у вас много внутренних API, не раздавайте каждой команде MCP-сервер. Держите единый слой, ограничивайте доступ на стороне сервера и не пускайте идентичность в параметры, видимые модели. Оговорка: это блог AWS о продукте AWS, написанный вместе с клиентом, а AgentCore доступен не во всех регионах.