Настройка сетевого эгресса для хостинговых агентов в Foundry Agent Service
Обзор новой функции Azure AI Foundry, позволяющей управлять исходящими подключениями хостинговых агентов через политики RAI. В материале описан процесс создания правил, привязки к агенту и тестирования в режимах Audit и Enforced.
Microsoft представила превью функции контроля исходящего сетевого трафика для хостинговых агентов в Azure AI Foundry. Функция позволяет задавать явные правила доступа к внешним ресурсам, отделяя сетевую политику от бизнес-логики приложения.
Главные тезисы
- Функция контроля эгресса находится в превью и не имеет SLA.
- Политика RAI отделяет сетевые правила от бизнес-логики агента.
- Режим Audit регистрирует попытки, Enforced — блокирует запросы.
- Поддерживаются правила Transform и Rewrite для изменения заголовков и назначения.
Разделение сетевой политики и логики агента
Контроль исходящих подключений (network egress) в Foundry Agent Service позволяет задавать явные правила назначения для агентов. Это решает проблему, когда агент выполняет запросы к непредвиденным ресурсам, например, при загрузке документов или использовании новых библиотек. Сетевая политика становится отдельным артефактом, который можно проверять, в то время как приложение сохраняет ответственность за бизнес-логику и аутентификацию.
Функция работает на уровне определения хостингового агента, а не внутри HTTP-оберток инструментов. Это обеспечивает контроль даже при использовании стандартных исходящих HTTP-вызовов.
Создание и применение политики RAI
Для настройки контроля используется структура ARM-ресурса с политикой RAI (Responsible AI). Процесс включает следующие шаги:
- Определение допустимых направлений. Создайте JSON-файл политики, указав режим Audit и действие по умолчанию Deny. Добавьте правила для конкретных FQDN (например, finance.contoso.example и vendors.contoso.example).
- Создание политики через Azure CLI. Используйте команду az rest для отправки JSON-тела запроса на создание ресурса RAI. Убедитесь, что ID политики сохранен для последующего использования.
- Проверка конфигурации. Выполните GET-запрос к URL политики, чтобы подтвердить, что режим сети установлен в Audit, а список хостов корректен.
Привязка политики к версии агента
Политика прикрепляется к версии хостингового агента через Python SDK. Для этого используется класс RaiConfig и параметр rai_policy_name в определении агента.
При создании версии агента необходимо:
- Указать полный ARM ID политики.
- Использовать пакет azure-ai-projects версии 2.2.0 или выше.
- Настроить протокол AgentEndpointProtocol.RESPONSES.
Важно: разрешение на исходящее подключение не дает прав на самом целевом ресурсе. Аутентификация и авторизация остаются задачей приложения.
Тестирование границ эгресса
Для проверки работы политик рекомендуется использовать диагностические инструменты внутри тестового образа агента, так как управляемые контейнеры не предоставляют интерактивной оболочки.
Тестирование проводится в два этапа:
- Режим Audit. Политика регистрирует попытки доступа. Запросы к разрешенным хостам проходят успешно, а к запрещенным — фиксируются как события would-deny. Отсутствие события не означает успешное соединение.
- Режим Enforced. При переключении режима на Enforced запросы к запрещенным хостам блокируются (возвращается 403). Разрешенные хосты продолжают работать.
При тестировании следует отключать перенаправления (redirects), чтобы точно определять конечную точку запроса, и обязательно включать проверку TLS.
Расширенные правила: Transform и Rewrite
Простого списка разрешенных адресов может быть недостаточно. Функция поддерживает правила Transform (изменение заголовков) и Rewrite (изменение назначения).
- Transform: позволяет добавлять или заменять заголовки (например, workload tag) в исходящих запросах.
- Rewrite: позволяет изменять конечный пункт назначения, если сервис переехал.
Порядок правил имеет значение: если срабатывает правило Allow, последующие правила Transform могут не выполниться. Необходимо тестировать, что именно получает конечный сервер.
Ограничения и рекомендации
Функция контроля эгресса находится в стадии превью и не имеет SLA. Она не предназначена для использования в production. Функция охватывает только HTTP/HTTPS пути хостинговых агентов и не распространяется на другие протоколы или типы агентов.
Ссылка на политику не является инструкцией для промпта. Вопросы «Куда подключается агент?» и «Кем он действует?» решаются раздельно. Сетевая политика отвечает только на первый вопрос, не отменяя необходимости проверки авторизации и безопасности данных на уровне приложения.
