Почему агенту нужен отдельный контроль исходящего трафика
ИИ-агент собирает URL из документов, писем, результатов поиска и вывода модели. Даже безопасный tool может получить атакующий адрес как аргумент. Если runtime имеет свободный интернет, prompt injection превращается в SSRF, сканирование внутренней сети или канал вывода данных.
Egress control применяет политику в точке, которую модель не может переубедить: на уровне сети и прокси перед фактическим соединением.
Tool allowlist не равен network allowlist
Tool policy отвечает: «можно ли вызвать fetch_url?» Сетевая политика отвечает: «куда реально ушёл TCP-сеанс?» Между ними находятся DNS, redirects, proxy settings, SDK и код в sandbox.
Оставляйте оба слоя. Даже разрешённый браузер не должен обращаться к loopback, private, link-local и служебным сетям. А сетевое разрешение на API не означает право вызвать любой endpoint или отправить любой payload.
Модель deny-by-default
Запретите исходящие соединения по умолчанию и открывайте минимальные маршруты для конкретного workload. Индексатору документации нужны HTTPS и доверенные источники; агенту поддержки — CRM через внутренний gateway; генератору текста внешний интернет может не требоваться вовсе.
Политика включает среду, identity workload, protocol, port, destination и срок исключения. Не создавайте общий профиль «всем AI-сервисам разрешён интернет».
Три рубежа защиты
| Рубеж | Что проверяет | Чего не видит |
|---|---|---|
| Tool gateway | Намерение, роль, аргументы, approval | Реальный DNS/IP после SDK |
| NetworkPolicy/firewall | Источник, IP, протокол, порт | HTTP path, method, объём и тип данных |
| Egress proxy | Host, TLS, method, path, redirects, байты | Бизнес-смысл без контекста tool |
Слои должны дополнять друг друга и fail closed. Обход proxy прямым сокетом блокируется сетью.
Что даёт Kubernetes NetworkPolicy
NetworkPolicy выбирает pods и ограничивает ingress/egress, если сетевой plugin поддерживает enforcement. Создайте default-deny egress в namespace, затем разрешите DNS к контролируемому resolver и соединение только с egress gateway.
Обычная IP-политика не является полноценным доменным allowlist: адреса SaaS меняются и могут быть общими для множества tenants. Проверяйте возможности конкретного CNI и тестируйте фактическую блокировку.
Egress proxy как policy enforcement point
Runtime передаёт запрос доверенному proxy, а тот сопоставляет workload identity с rule: разрешённые scheme, host, port, method, path и максимальный размер. Proxy сам выполняет DNS resolution, устанавливает TLS и обрабатывает ответ.
Запретите переменные окружения и пользовательские настройки, позволяющие выбрать другой proxy. Для mTLS и API credentials используйте broker: агент не должен получать ключ в prompt или произвольном коде.
Канонизация URL до проверки
Принимайте только необходимые схемы, обычно https. Разберите URL стандартной библиотекой, нормализуйте IDN, регистр host и port, отклоните userinfo, неоднозначный синтаксис и неожиданные схемы вроде file:, gopher: или data:.
Не ищите разрешённый домен подстрокой: api.example.com.attacker.tld — другой host. Сравнивайте нормализованное имя целиком или по корректной границе поддомена.
Проверка IPv4 и IPv6 после DNS
Получите все A и AAAA records и отклоните ответ, если хотя бы один адрес относится к loopback, private, link-local, multicast, unspecified или другому запрещённому диапазону. Затем соединяйтесь именно с уже проверенным адресом, сохраняя исходный host для TLS.
Проверяйте библиотекой IP-адресов, а не регулярным выражением: альтернативные представления и IPv4-mapped IPv6 часто обходят самодельные фильтры.
DNS rebinding и гонка между проверкой и соединением
Если приложение проверило DNS, а HTTP-клиент разрешил имя повторно, атакующий может вернуть публичный IP сначала и внутренний позже. Это классическая TOCTOU-ошибка.
Resolution и connect должны быть одной контролируемой операцией. Proxy фиксирует проверенный адрес на время запроса, применяет короткий разумный cache и повторяет полный контроль при новом соединении.
Redirect — это новый сетевой запрос
Разрешённый сайт может ответить redirect на внутренний адрес или домен атакующего. Безопасный default — отключить автоматические redirects. Если они нужны, ограничьте количество переходов и заново проверьте scheme, host, port и все resolved IP каждого Location.
Не переносите Authorization и cookies на другой origin. Логируйте всю redirect chain как единое решение policy.
Блокировка cloud metadata и внутренних сервисов
В AWS metadata доступны по link-local адресам 169.254.169.254 и fd00:ec2::254. Блокируйте их для agent workloads локальным firewall и egress policy; где возможно, требуйте IMDSv2 и минимизируйте роль instance.
В deny-set также входят loopback, RFC1918/private сети, link-local IPv4/IPv6, cluster service CIDR, control plane, internal DNS names и административные панели. Учтите эквиваленты metadata своего cloud.
FQDN allowlist: полезен, но не магический
Доменная политика удобнее нестабильных IP, однако разрешённый SaaS может обслуживать пользовательский контент, webhooks или открытые redirects. CDN-IP часто разделяется между несвязанными клиентами.
Разрешайте точный API hostname и нужные paths, фиксируйте TLS trust, отключайте произвольные ports. Для критичного провайдера полезны private endpoint либо собственный adapter с узким контрактом.
Ограничение эксфильтрации на разрешённый адрес
Allowlist не мешает отправить секрет в поле поискового запроса или загрузить всю базу в разрешённое хранилище. Вводите лимиты: bytes per request, response size, requests per run, уникальные hosts и суммарный outbound budget.
Tool contract разрешает только ожидаемые поля; DLP-контроль классифицирует payload до отправки. Write, upload и webhook требуют отдельного permission и при высоком риске — approval.
Наблюдаемость без новой утечки
Записывайте workload, agent run, tool call, policy version, canonical host, resolved IP, method, status, byte counts, redirect chain и reason allow/deny. Свяжите событие с audit trail агента.
Не сохраняйте query strings, headers и body целиком: там бывают tokens и персональные данные. Применяйте структурное редактирование и ограниченный доступ к security-логам.
Тесты, которые должны входить в CI
Проверьте localhost, private и link-local IPv4/IPv6, metadata endpoints, IP в нестандартном формате, userinfo, запрещённую схему, DNS с несколькими адресами, rebinding, redirect на внутренний host и перенос Authorization между origins.
Добавьте попытку прямого соединения в обход proxy, превышение byte budget и обращение после истечения временного исключения. Тест успешен только при блокировке на фактической сетевой границе.
Чек-лист внедрения egress control
- Для agent namespace действует default-deny egress.
- Runtime выходит наружу только через доверенный proxy.
- Правила привязаны к workload identity и среде.
- URL канонизируется до policy decision.
- A и AAAA проверяются перед каждым connect.
- Private, link-local, loopback и metadata заблокированы.
- Каждый redirect валидируется заново.
- Credentials не переносятся между origins.
- Есть лимиты запросов, ответов и outbound bytes.
- SSRF и proxy-bypass сценарии запускаются в CI.