Централизуем использование ИИ при помощи Agentgateway

Всем привет! Меня зовут Ваня, по призванию системный архитектор в RED Security. Хочу познакомить вас с open-source-решением для контроля и централизации работы с ИИ — Agentgateway. 

Мое знакомство с ним произошло не так давно. Был будний день, я спокойно сидел работал, как вдруг ко мне ворвался тимлид группы по ИИ: 

— Нам нужен шлюз!

— Шлюз? — спросил я? 

— Да, для ИИ! Через который пользователи бы подключались к LLM-провайдерам, различным MCP, можно было бы устанавливать лимиты на потребление токенов и ограничивать опасные MCP-команды!

Как вы уже можете догадаться — у нас все получилось. А о продукте, который мы использовали, я и расскажу далее. Надеюсь, вам понравится. Поехали!

Что это за покемон  

“First things first” — начнем с краткого обзора самого продукта. Agentgateway (буду сокращать до AGW) — мастер-оркестратор для ИИ. Написан на Rust компанией Solo.io и входит в Linux Foundation. Первый релиз был версии v0.0.2, появился на свет в марте 2025 года. Сейчас, спустя полтора года, проект дошел до тега v1.6.0. Одна из его, как я считаю, суперособенностей — открытый исходный код проекта на GitHub.

Схема использования AGW. Из официальной документации

AGW, как можно увидеть на схеме выше, выполняет следующие функции:

— шлюз до LLM-провайдеров;

— шлюз для MCP/A2A (Agent-to-Agent, агент к агенту);

— управление трафиком;

— направление инференса.

Что подразумевается под управлением трафиком:

— контроль количества потраченных токенов и создание лимитов;

— добавление или удаление заголовков в запросе;

— проверка содержимого запросов.

Способов развертывания данного продукта два: standalone и kubernetes.

Почему именно AGW

У читателя может возникнуть резонный вопрос: «А другие продукты вы рассматривали?» — «Да», — отвечу я. И сейчас объясню, почему остановились на AGW. До того как мы добрались до проекта компании Solo.io, рассматривались еще lunar.dev и MCPJungle.

После проведения исследования docker-образов этих продуктов, их разворачивании, тестирования основных функций, оценки простоты использования и наличия необходимых возможностей выяснилось, что либо настройка продуктов слишком сложная и непонятна из коробки, либо они не могут работать без доступа к интернету. Причем в одном из образов были прописаны переменные с кредами и внешним хостом для отправки на него логов (нам это, конечно же, не понравилось).

К использованию AGW мы пришли не сами — спасибо за рекомендацию коллегам из другого отдела. В дальнейшем мы с ними проводили встречи, чтобы перенять их best practices и не допускать дополнительных ошибок.

Как запустить

Думаю, теории достаточно — наступило время практики. Приведу пример настройки standalone-версии 1.5.0. Нам понадобится установленный Docker и docker-образ AGW.

1) Пуллим образ:

docker pull cr.agentgateway.dev/agentgateway:v1.5.0

2) Создаем директорию для маппинга в контейнер, в которой будут находиться конфигурация AGW (config.yaml) и файл базы данных SQLite:

mkdir agw-config

3) Запускаем AGW (в данной команде я специально указал 127.0.0.1, чтобы UI не был доступен всем из интернета, так как мы еще не настраивали на него авторизацию):

docker run -d 
  --name agentgateway 
  --user "$(id -u):$(id -g)" 
  -v "$PWD/agw-config:/config" 
  -p 127.0.0.1:4000:4000 
  cr.agentgateway.dev/agentgateway:v1.5.0

После успешного запуска можно увидеть следующие логи:

2026-09-27T13:48:59.369007Z	info	state_manager	loaded config from File("/config/config.yaml")
2026-09-27T13:48:59.371219Z	info	state_manager	Watching config file: /config/config.yaml
2026-09-27T13:48:59.374769Z	info	agent_core::readiness	Task 'state manager' complete (39.383334ms), still awaiting 1 tasks
2026-09-27T13:48:59.375171Z	info	app	serving UI at http://localhost:4000/ui
2026-09-27T13:48:59.375186Z	info	agent_core::readiness	Task 'agentgateway' complete (39.800792ms), marking server ready
2026-09-27T13:48:59.375190Z	info	management::hyper_helpers	listener established	address=127.0.0.1:15000 component="admin"
2026-09-27T13:48:59.375195Z	info	management::hyper_helpers	listener established	address=[::1]:15000 component="admin"
2026-09-27T13:48:59.375204Z	info	management::hyper_helpers	listener established	address=[::]:15020 component="stats"
2026-09-27T13:48:59.375297Z	info	proxy::gateway	started bind	bind="bind/4000"

Теперь можно открыть UI, перейдя в браузере на http://localhost:4000/ui

Включаем настройки для LLM и MCP, кликнув на них:

Прямоугольники должны изменить цвет:

После нажатия Continue будет такая страница:

Мы запустились и включили все настройки для дальнейшей работы. Отлично!

Ненадолго вернемся к теории. 

Основные понятия AGW

Gateways (ворота)

Ворота — это сущность, которая отвечает за вход в наш шлюз. Она представляет собой именованный порт и эндпоинты, через которые проходит трафик. Кроме порта можно также выбрать протокол (HTTP, HTTPS, TCP, TLS) и подключить сертификаты.

У каждого объекта gateway есть один или более listeners (слушателей). Несколько слушателей может понадобиться, когда у AGW имеется несколько хостнеймов. 

Listeners (слушатели)

Слушатели могут «разделять» ворота. Как было написано выше, они нужны, когда за шлюзом закреплено несколько хостнеймов и, следовательно, используются разные TLS-сертификаты. У шлюза под капотом всегда один слушатель. 

Routes (дороги)

Дороги занимаются обработкой и перенаправлением поступающего в шлюз трафика. Они определяются на верхнем уровне и привязываются к воротам по имени (одна дорога может использоваться несколькими воротами).

Вот схема того, как связаны между собой эти три понятия:

Backends (бэкенды)

Отвечают за перенаправление трафика IP-адресу, хостнейму, LLM-провайдеру или MCP-серверу.

Policies (политики)

Политики используются для управления трафиком, настройки мониторинга и установки правил безопасности.

Для разных объектов есть разные политики:

Посмотрим, как там дела с поставщиками LLM.

Подключение и настройка LLM-провайдера

Довольно просто добавить нового провайдера. Для этого нужно перейти в раздел Providers и нажать Add provider:

После нажатия на кнопку откроется следующее окно:

Можно увидеть множество различных провайдеров:

После этого добавить модели (раздел Models):

В пункте Provider я выберу провайдера, которого создал на прошлом шаге:

Подключение и настройка MCP

К шлюзу можно добавить MCP. Поддерживаются три транспортных протокола: Streamable HTTP, SSE (считается легаси) и Command Line.

Best practices

В завершение этого обзорного материала хотелось бы рассказать о лучших (или продовых) практиках, о которых мы с командой узнали, когда занимались изучением AGW.

Авторизация в админке с помощью OIDC 

По-хорошему авторизация в UI AGW должна быть доступна только администраторам шлюза. Почему? Потому что для пользователей есть ручка подключения и MCP, большее им скорее всего не понадобится. Это еще и обезопасит от доступа пользователей к настройкам. 

Если у вас есть система GitLab или что-то похожее, вы можете настроить авторизацию при помощи протокола OIDC. Данная настройка в AGW находится в разделе Settings → OIDC.

В политиках шлюза можно указать каким конкретно пользователям доступна авторизация Settings → Authorization:

Так мы разделяем зоны доступа и повышаем уровень спокойствия.

Неизменяемый конфиг

При работе в UI системы AGW и изменении каких-либо настроек — редактируется конфиг (config.yaml). Он доступен в разделе Tools → Raw configuration:

Однако для кого-то это может быть неудобно. В таком случае можно изменить права на файл (сделать read-only), чтобы AGW не мог его редактировать.

HTTPS

Шлюз позволяет настроить подключение HTTPS и подключить сертификаты. Так будет безопаснее, чем через HTTP. Рекомендую.

Sensitive headers

В процессе обработки шлюзом различных запросов HTTP-заголовки с конфиденциальными данными могут попасть в логи. Шлюз умеет замазывать необходимые заголовки, но для этого их необходимо указать в поле sensitiveHeaders:

# yaml-language-server: $schema=https://agentgateway.dev/schema/config
config:
  sensitiveHeaders:
  - x-api-key
  - cookie
  - x-tenant-secret

Поле находится в конфиге (config.yaml), поэтому шлюз читает значения в нем только при запуске. Необходимо перезапустить AGW после изменения поля sensitiveHeaders.

AGW замазывает указанные заголовки при поступлении запроса и повторно делает то же самое после выполнения преобразований запроса и бэкенда CEL (Common Expression Language, используется в политиках, трансформациях и правилах мониторинга).  

Таким образом, редактируется не только заголовок, отправленный клиентом, но и заголовок, созданный в результате преобразования. 

Редактирование затрагивает только вывод трассировки и дебага.  Шлюз по-прежнему передает реальное значение заголовка на бэкенд, и это значение все так же доступно для чтения в выражении CEL, поэтому политика или пользовательское поле журнала логирования, считывающее заголовок, продолжают работать.

Подключение по API-ключам

В AGW доступна авторизация по API-ключам. То есть, если пользователь хочет воспользоваться шлюзом, он обращается к админу AGW, который, в свою очередь, выпускает ключ. На каждый ключ можно задать лимиты по потреблению токенов, а также указать разрешенные для вызова модели:

Настройка цен за токены

Для каждой модели можно настроить свой прайсинг (в USD) за токены (input, output, cache read, cache write), отредактировав конфиг либо переопределив значения в UI:

Зачем это нужно?

Во-первых, чтобы полностью воспользоваться преимуществом API-ключей. Настройка цен позволяет шлюзу понимать стоимость потраченных токенов и корректно работать с устанавливаемыми на ключи лимитами.

Во-вторых, можно будет построить графики потребления токенов в самом AGW (да, даже такое там есть!):

Вот и все. Спасибо, что дочитали до конца! Хочу поблагодарить своих коллег Никиту Полосухина и Анатолия Зотова, благодаря которым я познакомился с Agentgateway и в итоге смог рассказать про него вам.

Мы разобрались с основными понятиями шлюза и его возможностями. Были рассмотрены и лучшие практики. Надеюсь, что вам было интересно! Поделитесь, какое впечатление вызывает продукт и работали ли вы с ним. Может, есть аналог, который вы бы порекомендовали?