Песочница для ИИ-агентов: как защитить системы, когда нейросеть может действовать сама

ИИ-агенты умеют управлять браузером, запускать команды и работать с файлами — но без ограничений это прямой путь к катастрофе. Разбираемся, как изолировать нейросеть так, чтобы она не навредила.

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

Зачем вообще изолировать нейросеть

Представьте, что вы наняли помощника для рутины: ответить на письма, обновить таблицу, найти информацию в интернете. Помощник быстрый, старательный, но абсолютно бесстрашный и не понимает последствий. Он может случайно удалить базу данных, отправить отчёт не тому человеку или переслать пароли на внешний сервер — просто потому, что ему так «показалось логичным» на основе текста запроса.

ИИ-агент — это примерно такой же помощник, только ещё быстрее и с доступом к реальным инструментам: браузеру, командной строке, файловой системе, исполняемому коду. И если классическое приложение выполняет заранее прописанные сценарии, то нейросеть может генерировать действия в реальном времени — и заранее предсказать все её шаги невозможно.

Именно поэтому безопасность ИИ-агентов строится на песочнице: жёстком ограничении того, куда агент может обратиться, что изменить и куда отправить данные. Это не просто «настройки прав» — это целая архитектура изоляции, контроля и наблюдения.

Начинайте с угроз, а не с контейнеров

Распространённая ошибка — выбирать технологию изоляции наугад. «Давайте запустим в Docker» — звучит быстро, но не всегда безопасно. Правильный подход — сначала понять, чем именно агент будет заниматься и какой вред может нанести, если что-то пойдёт не так.

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

Вот простое правило:

• Контейнеры (Docker и аналоги) подходят для задач, где входные данные предсказуемы, код проверен, а результат воспроизводим. Это парсинг, сборка, тестирование, конвертация. Контейнеры запускаются быстро и потребляют мало ресурсов, но они разделяют ядро операционной системы с основной машиной — и это их главное слабое место.

• Временные виртуальные машины (microVM вроде Firecracker, Kata Containers) — для всего, что связано с непроверенным кодом, незнакомыми сайтами или конфиденциальными данными. Они запускаются медленнее и дороже, зато каждый запуск работает в собственном изолированном ядре. Если агент попытается «вырваться» из контейнера, удар придётся в стену, а не в основную систему.

Если задача неопределённая, есть доступ в интернет или агент обрабатывает пользовательский ввод — выбирайте более сильную изоляцию. Не нужно применять тяжёлые виртуальные машины к каждому запуску, но рискованные сценарии должны быть в отдельной, более защищённой среде.

Четыре поверхности, которые нужно закрыть

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

Браузер

Если агент управляет браузером — переходит по ссылкам, заполняет формы, скачивает файлы — изоляция должна быть строгой. Каждая сессия работает в собственном профиле, без доступа к буферу обмена основной системы. Скачивание файлов — только в строго определённую папку, или вообще запрещено, если задача этого не требует.

Трафик идёт через отдельный прокси-сервер с явными правилами: какие адресы разрешены, какие — нет. Обязательно блокируется доступ к внутренним сервисам и облачным метаданным (тот самый адрес 169.254.169.254, который даёт информацию о сервере изнутри). Это не вопрос наблюдательности — это вопрос предотвращения.

Для работы с незнакомыми сайтами однозначно лучше использовать виртуальные машины, а не обычные контейнеры. Браузерные эксплойты реальны, и общее ядро — слишком тонкая защита.

Командная строка

Доступ к командной строке должен быть неинтерактивным. Никаких долгих сессий, никакого SSH, никаких псевдотерминалов. Команды запускаются как отдельные задания — с фиксированной рабочей директорией, ограничением по времени, процессору и памяти.

Идеальный вариант — белый список разрешённых команд. Если это слишком жёстко, разрешите узкий набор инструментов, но заблокируйте установку пакетов, сетевые сканеры, монтирование дисков, управление пользователями. Корневая файловая система — только для чтения, рабочая директория — строго изолированная папка конкретной задачи.

Мелкие исключения в скриптах со временем превращаются в долг безопасности. Лучше пусть правила будут простыми и читаемыми.

Файловая система

Агент видит только те пути, которые нужны для конкретной задачи. Справочные данные — только для чтения. Временные файлы, которые агент создаёт в процессе, живут в собственной папке и удаляются после завершения.

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

Исполняемый код

Запуск произвольного кода — самый опасный инструмент из всех. Здесь нужны жёсткие лимиты ресурсов: память, процессорное время, количество процессов, общее время выполнения. Языковые среды — только из утверждённого списка, установка пакетов — запрещена или только из внутреннего зеркала.

Для менее рискованных задач подойдут укреплённые контейнеры с ограничениями на системные вызовы. Для непроверенного пользовательского кода — только виртуальные машины с собственным ядром.

Важный принцип: предотвращение злоупотреблений и возможность наблюдать за происходящим — это разные механизмы. Логирование не заменяет изоляцию, а изоляция не заменяет логирование. Нужно и то, и другое.

Три обязательных слоя защиты

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

Сеть: запретить всё, потом разрешить нужное

Начинайте с полного запрета исходящих соединений. Затем добавляйте в белый список только те адреса, которые нужны для задачи. Весь трафик — через прокси-сервер с контролем на уровне имён и IP-адресов. Отключите прямой доступ к интернету из песочницы.

DNS должен соблюдать отдельные правила: только разрешённые резолверы, блокировка «сырых» DNS-запросов, запрет доступа к облачным метаданным и внутренним сетям. Это критично для браузерных сценариев и пользовательского кода — через подмену промпта безобидная задача может превратиться в утечку данных.

Файловая система: только чтение и строгая изоляция

Корневая файловая система — только для чтения по умолчанию. Каждая задача получает собственный изолированный том для временных данных, который удаляется после выполнения. Монтирование хостовых директорий — редко, узко, только по явной необходимости.

Для более рискованных задач добавляются ограничения на системные вызовы (seccomp, AppArmor или SELinux) или используется более сильная изоляция (gVisor, Kata Containers, временные виртуальные машины). Простые схемы монтирования легче контролировать и сложнее обойти.

Лимиты ресурсов: остановить дорогие сбои

На каждую задачу — квота процессора, лимит памяти, ограничение на количество процессов и общее время выполнения. Без этих ограничений агент, генерирующий код, может написать рекурсивный скрипт, исчерпать память, порождать дочерние процессы и «уронить» хост-машину.

С лимитами всё работает иначе: сначала срабатывает ограничение памяти, затем — на количество процессов, и наконец — тайм-аут гарантирует очистку ресурсов. Это базовая гигиена, без которой доверять агенту выполнение задач нельзя.

Человек на границе, секреты — за пределами

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

• Разрушительные команды: удаление файлов, установка пакетов, управление процессами, изменение системных настроек.
• Запись во внешние системы: отправка в Git, обновление тикетов, изменение базы данных, загрузка в хранилище, отправка писем.
• Чтение конфиденциальных данных: SSH-ключи, переменные окружения, конфигурации продакшена, экспорт пользовательских данных.
• Запуск кода на продакшн-данных — даже в укреплённой песочнице.
• Переход по незнакомым адресам, скачивание файлов, отправка форм в браузере.

Одобрение должно привязываться к возможностям и целевым объектам, а не к тексту запроса. Запросы должны быть конкретными, чтобы оператор оценивал реальный риск, а не нажимал на «подтвердить» из-за расплывчатого предупреждения.

Что касается паролей и токенов — они не должны находиться внутри песочницы. Используйте краткоживущие учётные данные, которые выдаются непосредственно перед выполнением и отзываются сразу после. Токены передаются через переменные окружения или временные файловые системы, а не хранятся в образах или на диске. Облачные метаданные блокируются, чтобы агент не мог подобрать credentials через системные сервисы.

Готовьтесь к попыткам побега

Контейнеры удобны, но разделяемое ядро — объективная точка уязвимости. Если агент работает с непроверенным кодом или бродит по незнакомым сайтам, используйте виртуальные машины с отдельным ядром. Регулярно обновляйте систему и разделяйте нагрузки: парсинг внутренних данных и работа с открытым интернетом не должны соседствовать на одном хосте.

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

Логирование: знать, что произошло

Если вы не можете восстановить, что именно агент делал, — вы не готовы к продакшену. Каждая задача должна оставлять аудиторский след: идентификатор агента, цель задачи, вызванные инструменты, фактические права доступа, решения об одобрении, адреса назначения, созданные файлы, хеши артефактов, тайминг и потребление ресурсов. Всё — в структурированном виде, с согласованными временными метками и идентификаторами.

Структурированные логи позволяют отличить нарушение политики от ошибки модели, оплошности оператора или нормального отклонения в работе задачи. Без этого разбор инцидентов превращается в гадание.

Три уровня изоляции по риску

Вот простой рубрикатор для выбора уровня защиты:

• Низкий риск: внутренний парсинг, преобразование данных, тестирование проверенного кода. Укреплённый контейнер с ограничениями на системные вызовы, контрольными группами и файловой системой только для чтения.

• Средний риск: редактирование файлов, установка пакетов, командная строка с ограниченным сетевым доступом. Более строгая песочница — gVisor или Kata Containers.

• Высокий риск: браузерная автоматика на незнакомых сайтах, пользовательский код, широкий доступ к сети. Временные виртуальные машины или microVM на базе Firecracker.

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

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