MCP-шлюз: зачем нужен gateway между AI-агентами и корпоративными инструментами

Подключить первый MCP-сервер просто: добавили конфиг на ноутбук, вставили токен, заработало. Десятый сервер — уже mesh из токенов, а двадцатый никто не помнит кто подключал. Каждый агент ходит напрямую в каждый инструмент, политики копируются руками, аудит рассыпан по логам. MCP-шлюз решает это собирая все подключения в одну точку: hub-and-spoke вместо mesh.

Проблема: прямые подключения не масштабируются

Без шлюза каждый клиент хранит адреса и секреты всех серверов. Обновление токена — обход всех рабочих мест. Отзыв — поиск всех копий. Новый инструмент появляется только если разработчик сам его добавил в конфиг. В такой схеме нет единой точки где применить политику «этому агенту можно читать Jira, но нельзя писать в прод-БД» и нет единого журнала кто что вызывал.

Для комплаенса это провал: нельзя доказать какие инструменты были доступны конкретному агенту в момент вызова и какие данные вернулись.

Что такое MCP gateway

MCP gateway — Layer 7 прокси на пути Model Context Protocol между AI-агентом и MCP-серверами. Агент указывает один endpoint шлюза вместо адресов каждого сервера. Шлюз говорит с агентом по MCP (stdio, HTTP, SSE, Streamable HTTP) и с каждым сервером — тоже по MCP, применяя на границе:

аутентификацию и проверку audience/scope (OAuth 2.1);
allowlist инструментов на этапе tools/list;
сканирование описаний и ответов на tool poisoning и prompt injection;
подстановку секретов без попадания в контекст агента;
аудит каждого tools/call с привязкой к LLM-вызову через OpenTelemetry.

Важно: шлюз — не «еще один MCP-сервер». Сервер исполняет инструмент, шлюз управляет доступом к множеству серверов.

Two-plane архитектура

Рабочие реализации 2026 года делят шлюз на две плоскости.

Control plane — вне горячего пути: хранит реестр MCP-серверов, каталог инструментов, политики, привязки секретов и поиск по аудиту. Админ-консоль, версионирование политик, экспорт логов — здесь.

Data plane — на каждом живом запросе: Auth handler, identity resolver, policy engine, discovery filter, session router, backend router, credential broker, audit emitter. Именно data plane решает за 5–30 мс на p99 пускать ли вызов и куда его маршрутизировать.

Такое разделение позволяет держать control plane в SaaS, а data plane — целиком у заказчика (hybrid) или весь шлюз on-prem — требование многих enterprise с приватным трафиком инструментов.

6 шагов запроса через шлюз

Аутентификация. Проверка токена агента, PKCE, audience. Не авторизован — не доходит до списка инструментов.
Резолв идентичности. Кто агент, какой tenant, какое окружение, кто human delegator, какой экземпляр агента.
Filtered discovery. На tools/list шлюз возвращает только разрешенные инструменты. Неразрешенные агент даже не видит — снижается Excessive Agency (OWASP LLM06).
Оценка политики. Cedar/OPA-правило вида principal, action, resource, context с explicit deny. Версионируется и симулируется до применения.
Маршрутизация с подстановкой секретов. Выбор upstream MCP-сервера или OpenAPI→MCP адаптера, подстановка scoped секрета, защита от SSRF, таймауты и лимиты размера.
Стриминг ответа и аудит. Поток SSE/JSON обратно агенту, маскирование чувствительных полей, выпуск OTel-спана и записи аудита с аргументами и результатом.

На этом пути шлюз также бриджует транспорты: агент на stdio получает доступ к удаленному HTTP/SSE-серверу без изменения клиента.

MCP gateway vs API gateway vs AI gateway

Три шлюза дополняют друг друга, а не конкурируют:

API gateway — политики на HTTP-транспорт: маршруты, rate limit по пути, валидация схемы.
AI gateway — перед LLM-провайдерами: роутинг между моделями, кэш, бюджеты, фолбэк.
MCP gateway — перед MCP-серверами: семантика инструментов — какой агент, какой tools/call, с какими аргументами и под какой политикой.

Типовой вызов агента 2026: агент → AI gateway → LLM → tool-call → MCP gateway → MCP server → ответ → LLM → AI gateway. Считать их альтернативами — архитектурная ошибка: в проде стоят все три слоя, иногда в одном бинаре.

3 шага внедрения

Зарегистрируйте upstream’ы и включите filtered discovery. Заведите каждый MCP-сервер в реестре шлюза, выдайте пилотному агенту минимальный allowlist и проверьте что tools/list возвращает только разрешенное.
Привяжите политики и секреты. Переведите токены из конфигов ноутбуков в брокер шлюза: агент не хранит секрет, шлюз подставляет свой scoped credential. Подключите Cedar/OPA-политики с deny по умолчанию и лимиты tools/call на агента и на инструмент.
Переключите клиентов и включите наблюдаемость. Поменяйте endpoint агента с прямых адресов на прокси-URL шлюза, включите OTel-экспорт и аудит. Проверьте что отзыв прав применяется мгновенно (без кэша tools/list дольше TTL) и что каждая запись содержит кто/что/когда/чем вызвано.

Где Codenik

Codenik построен как MCP gateway: единая точка входа для всех MCP-инструментов, каталог с владельцами и scope, filtered discovery по правам пользователя, OAuth 2.1 и Cedar-политики, брокер секретов без локальных токенов, session affinity и полный аудит каждого вызова. Команда добавляет интеграцию один раз в шлюз — дальше её получают все агенты с правильными правами, без копирования секретов по ноутбукам.

Короткий вывод

Без шлюза MCP масштабируется как хаос прямых интеграций. Со шлюзом — как управляемая платформа: один endpoint, одна политика, один аудит. Если в компании больше трех MCP-серверов или больше одной команды агентов — пришло время ставить gateway на границу инструментов.