Model Context Protocol (MCP) стал де-факто стандартом подключения ИИ-агентов к внешним инструментам — базам данных, API, файловым системам и сторонним сервисам. Но в продакшене простого подключения недостаточно: нужны аудит, фильтрация чувствительных данных и соответствие внутренним политикам безопасности. AWS предложила архитектурный паттерн, который решает эту задачу без переписывания существующей инфраструктуры.
Суть решения — бессерверный MCP-прокси, развёрнутый на Amazon Bedrock AgentCore Runtime. Прокси встаёт между MCP-клиентом (агентом) и upstream MCP-сервером, перехватывает все запросы, применяет кастомную логику и прозрачно пересылает их дальше. Для клиента прокси неотличим от обычного MCP-сервера: он видит тот же каталог инструментов и получает те же ответы. Upstream-сервер, в свою очередь, воспринимает прокси как авторизованного MCP-клиента.
Технически прокси реализован на FastMCP. При запуске он отправляет стандартный запрос tools/list к upstream-серверу, получает полный список доступных инструментов и динамически регистрирует их локально — каждый со своим обработчиком, который перенаправляет вызовы tools/call обратно на upstream. Собственных инструментов прокси не определяет и заранее ничего не знает о том, что предоставляет upstream. Это позволяет подключать его к любому MCP-совместимому эндпоинту: серверам на AgentCore Runtime, self-hosted решениям или сторонним MCP-сервисам.
При старте прокси запрашивает список инструментов у upstream MCP-сервера и динамически регистрирует их локально — клиент не видит разницы.
AgentCore Runtime обеспечивает управляемую вычислительную среду: автоматическое масштабирование, встроенную наблюдаемость через Amazon CloudWatch и OpenTelemetry, а также AgentCore Identity для аутентификации и авторизации. Авторизация выстроена независимо на каждом слое архитектуры — между агентом и прокси, и между прокси и upstream-сервером, — что создаёт раздельные границы доверия.
Паттерн адресован конкретной категории организаций: тем, у кого уже есть готовая логика фильтрации MCP-трафика, тесно связанная с внутренними библиотеками или on-premises системами комплаенса. Переписывать её в Lambda-функции (которые поддерживает AgentCore Gateway через механизм interceptors) нецелесообразно. Прокси на Runtime даёт альтернативу: логика остаётся в виде самостоятельного MCP-сервера, портируемого между системами и гибридными средами.
AgentCore Gateway при этом не исчезает из архитектуры — он может выступать upstream MCP-сервером для прокси. В таком случае организация получает и управляемое обнаружение инструментов, и управление учётными данными, и применение политик на стороне Gateway, и кастомную логику на стороне прокси. В демонстрационном примере от AWS именно Gateway используется как upstream, поскольку предоставляет готовый MCP-совместимый эндпоинт с зарегистрированными целями — без необходимости поднимать отдельный MCP-сервер для тестирования.
Реализация опубликована как open-source на GitHub. AWS описывает полный цикл: архитектуру, схему авторизации на каждом слое, автоматизированный скрипт развёртывания и сквозное тестирование с тестовым агентом.
