Агент без присмотра: куда он отправит запрос в три часа ночи

Контроль исходящего сетевого трафика для hosted-агентов пока в preview.

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

Мой тезис: ответ на этот вопрос нужно держать вне кода агента.

Без этого служба безопасности не выпустит автономного агента в прод, и будет права.

### Routines: запуск без человека Первое поколение агентов работало как чат: человек пишет, агент отвечает. Routines запускают агента по триггерам.

Агент разбирает новый issue в GitHub, реагирует на сообщение в канале Teams, собирает отчёт каждое утро или периодически проверяет долгий процесс, пока тот не завершится. Microsoft сама перечисляет, что раньше командам приходилось строить вокруг агента своими руками: планировщики, слушатели событий, вебхуки, очереди, инфраструктуру, аутентификацию, историю запусков и мониторинг.

Список точный: кто доводил агента до регулярной работы, знает, что сам агент занимает в таком проекте меньшую часть. ### Egress controls: граница исходящих вызовов

Вторая функция задаёт правила, куда hosted-агент может ходить по сети.

В чат-боте контроль обеспечивает человек: он видит каждый ответ и может остановить диалог. Routine, которая запустилась в три часа ночи, человек не видит. Microsoft показывает это на агенте для обработки счетов.

По задаче ему нужны два API: найти поставщика и проверить запись о платеже.

Потом приходит документ со ссылкой на незнакомый сервис загрузки.

Или новая вспомогательная библиотека обращается по URL, о котором разработчик не знал.

Список выданных агенту инструментов в обоих случаях не защищает: запрос уходит в обход него. В первом случае запрос отправит модель, которая прочитала в документе чужую инструкцию (prompt injection), во втором - транзитивная зависимость.

Поэтому безопасник должен спрашивать, куда этот процесс физически может отправить байты. Вопрос «какие инструменты выдали агенту»

Большинство наших клиентов в России Foundry использовать не могут.

Паттерн от Foundry не зависит и переносится на любой стек, включая GigaChat, YandexGPT и Qwen в собственном контуре.

Мы собираем его из пяти частей. 1. Период наблюдения.

Агент работает в тестовом контуре, все исходящие вызовы пишутся в журнал.

Через пару недель у команды есть фактическая карта: какие домены нужны, какие появились случайно. 2. Egress-прокси с явным allowlist.

Прокси блокирует вызовы к доменам вне списка и поднимает алерт.

Если новая библиотека обратится наружу, команда узнает об этом в первый же день. 3. LLM & Security Gateway для вызовов модели.

Шлюз маскирует персональные данные, держит лимиты расходов и хранит журнал запросов и ответов.

, доступа к базе целиком у него нет.

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

Шина и n8n уже дают историю запусков, повторы и мониторинг.

Писать собственный планировщик ради одного агента не придётся.

По нашему опыту, контур безопасности добавляет к запуску агента неделю-две. Руководители часто считают это задержкой. Без контура служба безопасности не пустит агента, который трогает платежи, дальше пилота, и время до пользы становится бесконечным. Я не раз видел такой сценарий: демо впечатляет правление, потом полгода висит в согласованиях и тихо умирает.

Бюджет потрачен, метрика не сдвинулась, и за пилот кому-то придётся отвечать. Сценарий «агент сам разбирает счета каждое утро»

выглядит простым, но требует скучной инженерии: журнал вызовов, прокси, шлюз, узкие инструменты, шина. Эту работу делают инженеры, и именно она отличает агента в проде от агента на презентации.