MCP-шлюз: единое окно для множества ИИ-агентов

Протокол MCP (Model Context Protocol) становится стандартом для подключения ИИ-агентов к корпоративным данным и инструментам. Каждый сервис — от хранилища документов до трекера задач — обзаводится собственным MCP-сервером. По мере перехода от пилотов к промышленной эксплуатации растет число агентов, инструментов и связей между ними. Пока MCP-серверов единицы, ими еще можно управлять вручную, но когда счет идет на десятки, то для каждой связки «агент — сервер» приходится отдельно настраивать подключение, авторизацию, синхронизацию и журналирование, а затраты на сопровождение растут вместе с числом связей. Управлять каждым сервером поодиночке невозможно, и в корпоративной архитектуре появляется новый класс решений — MCP-шлюз.

Рис. 1. MCP-шлюз — единое окно доступа к MCP-серверам

MCP-шлюз становится единым окном доступа ко всем MCP-серверам компании (рис. 1) — все запросы агентов проходят через одну прослойку, в которой централизованно настраиваются доступы, отслеживаются операции и применяются политики безопасности.

Важно не путать шлюз с соседними классами решений. API Gateway управляет взаимодействием классических микросервисов вне ИИ-слоя. LLM Gateway отвечает за работу с моделями: инференс, контроль версий, настройки, лимиты токенов. MCP-шлюз ориентирован на взаимодействие агентов с инструментами, определяя, какие MCP-серверы и кому доступны, какие данные агент может получать, а какие — нет.

Аутентификации — минимальная функция MCP-шлюза: он должен точно понимать, кто к нему обращается — пользователь, агент или пользователь через агента и какими полномочиями этот субъект обладает. Права раздаются по ролевой (RBAC) или атрибутивной (ABAC) модели.

Маршрутизация и трансформация запросов, версионирование, кэширование, квотирование объемов выдаваемых данных и ограничение частоты вызовов — также сфера ответственности шлюза. Наконец, он должен уметь журналировать все операции и связывать их в единую трассировку — если что-то пошло не так, весь путь запроса восстанавливается и разбирается.

К дополнительным механизмам относятся инспекция промптов на инъекции, защитные ограничения (guardrails) и запуск инструментов в изолированной среде.

На старте проекта MCP разумно опираться на базовый набор, наращивая защитные контуры по мере роста числа агентов и критичности сценариев.

Безопасность и полномочия

Главный риск MCP-инфраструктуры — выполнение недопустимых действий в реальной корпоративной системе: ИИ-агент что-то запустит, заблокирует или удалит лишнее, вплоть до репозитория. Через промптинъекцию ограничения может обойти и пользователь, и сам ИИ-агент. Модель будет считать, что корректно выполняет запрос, а по факту совершит операцию, прав на которую у нее не было. В закрытом контуре данные вряд ли утекут наружу, однако сотрудник может получить через агента информацию не для своего уровня доступа. Поэтому права следует привязывать прежде всего к пользователю. Наделять полномочиями самого агента — значит снять ответственность с человека: если машина совершит ошибку, спросить будет не с кого. При этом агент не должен получать учетные данные пользователя или выдавать себя за него. По цепочке вызовов работает делегирование — агенту передаются ровно те ограниченные полномочия, которые нужны для выполнения конкретной операции.

Для контроля и расследования инцидентов шлюз сохраняет всю цепочку: исходный запрос пользователя, действия агента, вызванные инструменты, полученные данные и итоговый результат. Администратору доступна полная картина по всем пользователям, а пользователь видит трассировку своей сессии и может подтверждать или отклонять действия ИИ-агента. На ранних этапах внедрения критические операции стоит подтверждать человеком, по мере накопления доверия число таких проверок сокращается.

Центральная шина

В мультиагентной системе MCP-шлюз выступает центральной шиной доступа — в нем зарегистрированы все ИИ-агенты и через него каждый из них обращается к разрешенным MCP-серверам. Шлюз контролирует маршруты запросов, число повторных вызовов и расход токенов — агент, ушедший в бесконечный цикл повторных попыток, способен быстро потратить бюджет. Шлюз должен останавливать подобные циклы и возвращать пользователю ошибку вместо очередной итерации.

Различные цифровые сотрудники обычно выполняют разные роли: агент-планировщик разбивает исходный запрос на подзадачи; агент-исследователь дополняет недостающий контекст, при необходимости уточняя детали у пользователя; агент-оценщик рассчитывает стоимость выполнения и оптимальный состав участников; контролирующий агент проверяет доступность данных для каждого шага и корректирует план; агент-исполнитель запускает работу и возвращает результат. Набор узкоспециализированных агентов справляется с разнотипными задачами лучше, чем один монолитный. Однако передача задач между агентами — это зона отдельных протоколов «агент — агент», определяющих, как один агент понимает, кому и как передать задачу, тогда как MCP отвечает за доступ каждого агента к инструментам. Здесь и нужен шлюз, выполняющий роль центральной шины.

Экономика шлюза

Рис. 2. Место шлюза в корпоративной ИИ-платформе

MCP-шлюз может быть как отдельным продуктом, так и компонентом корпоративной ИИ-платформы (рис. 2). Крупные компании с уже сложившимся парком цифровых помощников и MCP-серверов обычно закладывают шлюз в архитектуру собственной платформы как отдельный сервис. Компаниям меньшего масштаба интереснее готовые решения — такие продукты уже появляются на рынке, в том числе российском. Один из показательных примеров — технологическое подразделение онлайн-школы иностранных языков Skyeng, создавшее внутреннего ИИ-помощника, интегрированного с Jira, корпоративными репозиториями и другими корпоративными сервисами. Для безопасного доступа к этим ресурсам был разработан собственный MCP-шлюз, наследующий права конкретного сотрудника, контролирующий обращения к корпоративным данным и журналирующий действия ИИ-агентов. Yandex Cloud развивает MCP Gateway и MCP Hub для централизованного подключения, управления и контроля MCP-серверов. Крупные ИТ-холдинги уже столкнулись с задачей интеграции шлюза в свои ИИ-платформы, в частности, для создания единого слоя между агентами и корпоративными системами. Такой слой должен обеспечивать регистрацию и обнаружение инструментов, маршрутизацию запросов, управление правами пользователя и агента, контроль за секретами, журналирование действий и дополнительный мониторинг операций, изменяющих данные.

Сам по себе шлюз не создает бизнесэффекта — это инфраструктурный инструмент и оценивать его можно только через экономию: сокращение сроков подключения систем, переиспользование интеграций, снижение затрат на сопровождение, ускорение вывода новых сценариев. В качестве технических метрик можно назвать снижение числа ошибок и уменьшение времени их обнаружения, сокращение количества неправомерных запросов и стоимости вычислительных ресурсов. Однако для получения точной оценки требуется сравнить стоимость владения со шлюзом и без.

***

Протокол еще слишком молод, и у него еще много ограничений. Мало промышленных кейсов, которые можно взять на вооружение, — каждая компания выстраивает свою уникальную практику через собственные пробы и ошибки. Не решены до конца вопросы защиты от промпт-инъекций и манипуляций с инструментами, нет единых стандартов мультиагентного взаимодействия. Однако по мере увеличения числа работающих в компании ИИ-агентов и MCP-серверов будет расти и потребность в шлюзе как центральной точке контроля.

Татьяна Сеземина (TSezemina@inno.tech) — руководитель «Платформы ИИ-агентов» направления Т1 ИИ (ИТ-холдинг Т1) (Москва).