Команда включает AI-инструмент в ограниченной среде: ему можно работать с задачей, но нельзя обращаться к внешнему интернету. На бумаге это выглядит как простой запрет. На практике сеть сложнее: прокси, разрешённые домены, встроенные инструменты, сторонние сервисы и перенаправления могут создать обходной путь.
Опасность не в том, что модель «захотела» нарушить правило. Опасность в архитектуре, где запрет записан в подсказке или политике продукта, но не подтверждён сетевым слоем. Если среда действительно не должна иметь интернет, это должно доказываться DNS, прокси, сетевой экран и журналами вызовы инструментов.
Практическая цель — построить исходящий трафик-контроль, который работает даже при ошибке модели, неправильной подсказке или неожиданном маршруте. Все внешние обращения должны идти через управляемый слой, а не через случайный встроенный инструмент.
Этот материал нужен владельцам AI-платформ, SOC и инфраструктурным командам, которые разрешают моделям выполнять действия рядом с внутренними данными.
Где обычно ломается запрет
Слабое место возникает там, где разные слои понимают запрет по-разному. Модель считает, что интернет запрещён, но инструмент может вызвать внешний сервис. Прокси блокирует часть категорий, но разрешает домен-посредник. DNS видит одно направление, а приложение показывает другое.
Поэтому контроль строится от сети к приложению, а не наоборот. Подсказка модели — это пояснение, но не защитная граница.
- запрет не должен жить только в подсказке;
- DNS и прокси должны видеть все обращения;
- разрешённые домены проходят список разрешений;
- категории посредников блокируются отдельно;
- вызовы инструментов пишутся с параметрами;
- среда выполнения не хранит лишние ключи;
- тесты обхода запускаются перед релизом.
Карта журналов для расследования
Если появляется подозрение на обход, аналитик связывает задачу пользователя, вызов инструмента, сетевое назначение и ответ внешнего сервиса. Без этой связи событие выглядит как обычный сетевой шум.
Журнал должен показывать не только успешные подключения, но и отказанные попытки. Отказы часто становятся ранним индикатором того, что сценарий пытается найти обходной путь.
- запрос пользователя и рабочая задача;
- название инструмента и параметры вызова;
- DNS-запрос и конечный IP;
- прокси-категория и решение политики;
- объём переданных данных;
- отказанные соединения и причины;
- изменение политики после инцидента.
Какие журналы нужны с первого дня
Команда должна заранее решить, какие события доказывают путь от входного сигнала до действия. Если журналы собираются только после инцидента, часть фактов уже потеряна: короткие токены истекли, временные файлы удалены, сессии закрыты, а владелец действия спорит с владельцем системы.
Для AI-сценариев полезен сквозной идентификатор операции. Он связывает пользователя, источник данных, модель, политику, действие, сетевое направление и результат. Тогда расследование не превращается в ручной поиск по разным консолям.
- идентификатор пользователя и рабочей роли;
- источник документа или внешнего события;
- версия модели и версия политики;
- целевой ресурс и тип действия;
- решение контроля и причина отказа;
- сетевое направление и объём данных;
- время действия и владелец исключения.
Контроли до режима блокировки
Начинать лучше с наблюдения. Команда собирает нормальные сценарии, проверяет шум, согласует владельцев и только затем переводит часть действий в запрет. Такой порядок особенно важен там, где модель работает рядом с бизнес-процессом и может остановить легитимную операцию.
Но режим наблюдения не должен быть вечным. Для опасных действий нужен срок: после анализа шума включается запрет по умолчанию, а исключения получают владельца и дату пересмотра.
- наблюдать перед блокировкой;
- запретить опасные действия по умолчанию;
- разделить данные, инструкции и выполнение;
- требовать подтверждение для необратимых операций;
- ограничить сеть и права среды;
- автоматически отзывать подозрительные токены;
- пересматривать исключения по расписанию.
Как SOC, AppSec и владельцы данных делят ответственность
SOC видит сигнал и собирает доказательства. AppSec проверяет границы приложения, код и доверие к источникам. Владелец данных решает, может ли конкретный пользователь видеть или изменять ресурс. Инфраструктура отвечает за сеть, секреты, журналирование и аварийный откат.
Если эта карта не описана заранее, AI-инцидент быстро превращается в организационный спор. Поэтому роли фиксируются вместе с архитектурой и проверяются на учениях.
- SOC формирует гипотезы и временную шкалу;
- AppSec проверяет поток данных и действия;
- владелец данных утверждает доступ;
- инфраструктура меняет ключи и сетевые политики;
- юридическая функция оценивает уведомления;
- руководитель риска принимает остаточные исключения.
Проверка эффективности
Контроль считается рабочим, если он сокращает время расследования и уменьшает число ручных догадок. Отчёт должен показывать не только срабатывания, но и полноту доказательств: видно ли, кто начал операцию, что повлияло на решение модели и какой ресурс был затронут.
Метрики должны быть понятны не только технической команде. Руководитель должен видеть риск, владелец продукта — влияние на процесс, а SOC — качество сигнала.
- время от сигнала до первичного разбора;
- доля событий с полным набором журналов;
- число заблокированных опасных действий;
- доля ложных срабатываний;
- число постоянных исключений;
- скорость отзыва токенов и сессий;
- результаты учений по восстановлению.
Дополнительный технический сценарий
Перед вводом контроля в работу команда проводит короткое учение. Берётся безопасный тестовый объект, имитируется подозрительное событие и проверяется, видят ли его SOC, AppSec и владелец данных. Цель не в красивом отчёте, а в доказательстве, что сигнал проходит через всю цепочку и приводит к понятному действию.
После учения фиксируются пробелы: где не хватило поля в журнале, где не было владельца, какой запрет оказался только документом, а не технической мерой. Эти пробелы переводятся в задачи с датами и ответственными.
- создать безопасный тестовый сценарий;
- проверить поступление события в SIEM;
- связать событие с пользователем и ресурсом;
- проверить блокировку или отказ политики;
- собрать временную шкалу без ручных догадок;
- оформить найденные пробелы как задачи;
- повторить проверку после исправлений.
