Время на прочтение7 мин

Охват и читатели7.6K

Всем привет! Меня зовут Ваня, по призванию системный архитектор в 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, как можно увидеть на схеме выше, выполняет следующие функции:

• шлюз до LLM‑провайдеров;

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

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

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

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

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

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

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

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

У читателя может возникнуть резонный вопрос: «А другие продукты вы рассматривали?» — «Да», — отвечу я. И сейчас объясню, почему остановились на 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 будет такая страница:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В процессе обработки шлюзом различных запросов 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, поэтому политика или пользовательское поле журнала логирования, считывающее заголовок, продолжают работать.

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

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

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

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

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