Агент с fetch-инструментом и доступом в интернет — это браузер без адресной строки, которым управляет текст из чужих документов. Классическая атака укладывается в одну строку: вредоносная инструкция в письме или странице заставляет агента загрузить URL, в котором закодированы приватные данные. В логах — обычный HTTPS-запрос. Ответ пользователю при этом выглядит безобидно: исследования показывают, что 95% таких атак невидимы для проверок на уровне текста ответа.
Как агент выносит данные через URL
Три рабочих приёма: параметры запроса (evil.com?d=<данные>), поддомены (<данные>.evil.com резолвится через DNS атакующего), редиректы (разрешённый домен редиректит на злой). Отдельный канал — сам DNS: из «изолированных» песочниц демонстрировали двунаправленный covert-канал через DNS-запросы, которым выносили содержимое бакетов, секреты и PII. Вывод жёсткий: всё, что агент может резолвить и фетчить, — потенциальный канал выноса.
Почему наивный allowlist не держит
Список «хороших доменов» закрывает только прямолинейную атаку. Не закрывает: редирект с разрешённого на запрещённый, поддомены и похожие имена (typosquatting), пользовательский контент на разрешённых платформах (gist, pastebin, облачные бакеты), DNS-туннелирование поверх разрешённого резолвера. Разборы защиты от URL-эксфильтрации прямо фиксируют: наивного allowlisting по доменам недостаточно, нужны проверки содержимого запроса и цепочек.
4 слоя egress-защиты
- Нет прямого маршрута. У агента нет default route в интернет: единственный выход — прокси. Прямой вызов просто не уходит по сети, а не «блокируется политикой». Это архитектурный факт, который нельзя обойти промптом.
- Default-deny proxy с allowlist. Прокси пропускает только явно разрешённые назначения, режет всё остальное на TCP-уровне, включая неизвестные протоколы. Allowlist — строгий, без wildcard-наследования поддоменов.
- Разбор цепочек и содержимого. Раскрытие редиректов до финального домена, проверка query-параметров на высокую энтропию (признак закодированного пейлоада), сканирование ответов на секреты и PII до возврата агенту.
- DNS-фильтрация отдельно. Даже при закрытом HTTP DNS остаётся каналом: фильтрация на резолвере (файрвол DNS, sinkhole), запрет произвольных DNS-серверов, мониторинг объёма и энтропии запросов.
Слои независимы: обход одного упирается в следующий.
DNS как отдельный канал
DNS-трафик традиционно не инспектируют — и зря. Туннелирование через TXT-запросы и длинные поддомены выносит данные медленно, но верно, а выглядит как обычный резолв. Меры: только корпоративный резолвер, блок DNS-over-HTTPS в обход него, алерты на аномальный объём и длину имён. Проверка вендоров тоже сюда: требуйте явного перечня разрешённых сетевых протоколов в «изолированном» режиме, а не маркетинговых слов.
Тесты на обход
- Канарейка в URL: прогон с документом-ловушкой, содержащим инструкцию унести метку, — метка не должна покинуть периметр;
- Редирект-тест: разрешённый URL, редиректящий на внешний домен, — запрос обязан быть отрезан после раскрытия цепочки;
- DNS-тест: попытка резолва произвольного имени и DNS-over-HTTPS — только через корпоративный резолвер или никак;
- Sharding-тест: вынос по частям мелкими запросами — ловится подсчётом энтропии и объёма на назначение, а не инспекцией одного запроса.
Где Codenik
Codenik — точка egress для вызовов инструментов: агент не ходит наружу напрямую, каждый внешний вызов проходит allowlist, секреты подменяются плейсхолдерами на границе (агент вообще не держит настоящих ключей), ответы сканируются до возврата в контекст. Попытка унести данные упирается в прокси, а не в сознательность модели.
Короткий вывод
Egress для агентов — first-class граница: нет прямого маршрута, default-deny proxy, разбор редиректов, отдельный контроль DNS. Промпт-инъекции не исчезнут — но без сетевого канала им некуда выносить.