Agentgateway объединяет LLM, MCP и A2A-трафик в одном open-source прокси

Системный архитектор RED Security Иван опубликовал на Habr разбор Agentgateway, open-source-шлюза, через который можно пропустить сразу три типа ИИ-трафика: запросы к языковым моделям, вызовы инструментов по MCP и общение агентов друг с другом по A2A. Идея понятна любому, кто видел, как ИИ расползается по компании: вместо десятка прямых подключений с ключами в коде и без единого журнала появляется одна управляемая точка.

Оговорка: в ленте доступен только анонс статьи, полный текст лежит на Habr. Поэтому ниже контекст по публичной документации проекта, а не пересказ деталей авторского разбора.

Какую проблему закрывает шлюз

Когда команды подключают LLM по одной, всё выглядит безобидно. Один сервис ходит в OpenAI, другой в Anthropic, третий в Gemini. Потом появляются агенты, которые вызывают внутренние API через MCP-серверы и друг через друга. У каждого соединения свои ключи, свои лимиты, свои логи. Или их нет вовсе.

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

Что известно о самом проекте

Agentgateway создала компания Solo.io, затем проект передали Linux Foundation. Это важно для тех, кто боится привязки к одному вендору: код открыт, а управление выходит за рамки одной компании. Ядро написано на Rust, что обычно означает небольшой расход памяти и предсказуемую задержку на горячем пути.

Ключевые возможности по документации:

• три типа трафика в одном прокси: LLM-запросы, MCP, A2A;
• маршрутизация к нескольким провайдерам моделей, включая облачные платформы и OpenAI-совместимые API;
• авторизация и политики доступа, в том числе на основе JWT и выражений CEL;
• лимиты и учёт расхода, привязанные к токенам, а не только к числу запросов;
• защитные фильтры для промптов и ответов;
• метрики и трассировка через OpenTelemetry;
• интеграция с Kubernetes Gateway API и встроенный интерфейс для отладки.

Где подвох

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

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

С чего начать внедрение

Практичный путь выглядит так. Сначала поднимите шлюз в тестовом контуре и проведите через него один некритичный сервис с LLM. Сравните задержку и убедитесь, что логи содержат то, что нужно аудиту. Затем перенесите ключи провайдеров из приложений в конфигурацию шлюза и закройте прямой выход в интернет для тех сервисов, которые ходят к моделям.

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