Песочницы для ИИ-агентов

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

Не существует единого уровня изоляции, закрывающего абсолютно все варианты сбоев. Зрелый подход строится на эшелонированной защите (defence-in-depth) на нескольких уровнях.

Четыре уровня

1. Изоляция файловой системы и процессов

Не даёт агенту прочитать учётные данные или записать файлы за пределы рабочей зоны.

Linux: на базе namespace'ов. bubblewrap-dev-env (конфигурация bubblewrap от Ciężarkiewicz) монтирует большую часть файловой системы в режиме только для чтения, разрешает запись только в каталог проекта и несколько каталогов состояния и запускает агента внутри этого окружения. Маршрутизация на уровне отдельных процессов в wirez близка по смыслу, но сфокусирована на сети, а не на файловой системе.
macOS: отдельный пользователь + Seatbelt. hazmat создаёт для агента выделенного пользователя macOS (что делает домашнюю директорию хоста структурно недосягаемой), а затем добавляет сессионный sandbox ядра Seatbelt с запретом доступа по умолчанию к путям с учётными данными даже внутри домашней папки самого агента.
macOS / Linux: microVM. superhq (и лежащий в его основе shuru-sdk) идёт ещё дальше: каждая сессия агента запускается внутри отдельной microvm со своим собственным ядром, поэтому побег из песочницы требует взлома гипервизора, а не просто трюка с системными вызовами. Запуск на каждую сессию обходится дороже, чем namespace'ы или Seatbelt, однако даёт самую сильную изоляцию на этом уровне. Полная панорама платформ на базе microVM (Fly.io Sprites, E2B, Vercel Sandbox, AWS Bedrock AgentCore, Microsandbox, Docker Sandboxes, Matchlock и др.) разобрана в microvm-2026; доминирующей архитектурой среди них становится шаблон matryoshka-isolation (контейнеры, вложенные в VM).

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

1b. Изоляция учётных данных на сетевом уровне

Дополнительный уровень, который изначально не входил в четырёхуровневую модель: даже при наличии сильной песочницы агент обычно держит API-ключ или OAuth-токен, и достаточно целеустремлённая утечка может отправить этот секрет на разрешённый эндпоинт. Шлюз аутентификации в superhq полностью выносит учётные данные за пределы песочницы - обратный прокси на стороне хоста сам подставляет секрет в исходящие вызовы API прямо на границе сетевого канала. Агент вообще никогда не видит ключ, поэтому угроза утечки учётных данных сводится к угрозе утечки трафика сессии (что тоже неприятно, но ограничено). Этот подход можно комбинировать со всеми четырьмя уровнями ниже.

onecli реализует ту же идею в виде отдельного инструмента: каждый агент получает ключ-заглушку, а self-hosted шлюз сопоставляет исходящий запрос по хосту и пути, расшифровывает реальные учётные данные и подставляет их на лету. Механически это уровень 3 - терминация TLS, инспекция и переписывание каждого запроса, - только направленный на учётные данные, а не на сетевую доступность. Соответственно, он наследует слабости этого уровня: скрытие ключа не уменьшает объём того, что этот ключ позволяет сделать.

2. Политики исходящего сетевого трафика

Предотвращают утечку данных и обращение к командным серверам (C2).

Правила фаервола pf (hazmat) - блокируют исходящие протоколы SMTP, IRC, FTP, VPN. Известные сервисы туннелирования (ngrok, pastebin, webhook.site) резолвятся в localhost через чёрный список DNS.
Дыра в виде HTTPS. Ни hazmat, ни конфигурации на базе bubblewrap не могут просто заблокировать порт 443, не сломав при этом вызовы к API. Агент может выполнить curl на любой URL по HTTPS и выгрузить данные наружу.

Здесь одних только сетевых политик становится недостаточно.

3. Перехват на уровне HTTP с применением политик

Встраивание в HTTPS-канал и инспекция каждого исходящего запроса.

crabtrap - HTTP-прокси от Brex с оценкой через LLM-судью. При настройке устанавливается CA-сертификат; TLS-трафик агента перехватывается; каждый запрос сначала сверяется со статическими правилами, а если совпадений нет, оценивается LLM-судьёй на соответствие политике, написанной на обычном английском. Пропуск, блокировка и логирование происходят в реальном времени.
Компромиссы. Требует, чтобы агент доверял CA прокси. Добавляет задержку на каждый запрос, не попавший под статические правила. Защиту всё ещё можно обойти, если политика разрешает эндпоинт, принимающий произвольный текст (комментарии к issue, сообщения в Slack).

Этот уровень дополняет предыдущие: песочница ОС блокирует очевидные действия, сетевые политики отсекают заведомо опасные протоколы, а уровень HTTP принимает взвешенные решения по оставшемуся HTTPS-трафику.

4. Перехват на уровне системных вызовов

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

syscall-binary-rewriting - замена инструкций syscall на ловушки INT3, перехват каждого вызова в обработчике и принятие решения о разрешении, модификации или запрете. Накладные расходы составляют менее микросекунды на системный вызов.
Другие подходы - seccomp-bpf (стандартный интерфейс фильтрации системных вызовов в Linux), мониторинг на базе eBPF (little-snitch-linux использует eBPF для сетевого мониторинга отдельных приложений).

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

Какой уровень выбрать

Примерное сопоставление угроз и уровней защиты:

Угроза	Чем закрывается
Агент читает учётные данные в ~/.aws	Уровень 1 (файловая система)
Агент пишет по произвольным путям	Уровень 1
Агент выгружает данные через SMTP/IRC/Tor	Уровень 2 (сеть)
Агент выгружает данные по HTTPS на произвольный хост	Уровень 3 (HTTP-политики) или Уровень 2 (DNS-блоклисты)
Агент повышает привилегии через системные вызовы	Уровень 4 (фильтрация системных вызовов)
Вредоносный npm postinstall	Уровень 1 (бинарники только для чтения) или переменная окружения (`npm ignore-scripts`)
Prompt injection, запускающий внешне легитимные действия	Уровень 3 (здесь работают только политики)

Большинство практических конфигураций комбинируют уровни 1 и 2 (изоляция на уровне ОС) с уровнем 3 (контроль HTTP с учётом политик), пропуская уровень 4, если эксплуатационные расходы на него не оправданы.

Чего песочницы не решают

Качество политик. Песочница обеспечивает соблюдение правил, но не пишет их. Если политика разрешает создавать issue на GitHub, а агент отправляет украденные секреты прямо в заголовке issue, CrabTrap не увидит ничего подозрительного.
Вмешательство в состояние агента. Если рабочий каталог агента содержит его собственные конфигурации или память (например, ~/.claude), скомпрометированная сессия может отравить последующие. Защита от этого существует лишь частичная (снимок до сессии, diff после неё - так делает hazmat с помощью Kopia).
Доверие к реализации песочницы. Bubblewrap опирается на user namespaces, за которыми тянется история CVE. Seatbelt не документирован Apple. LLM-судью в CrabTrap можно обойти с помощью prompt injection. Ни один из этих механизмов не даёт абсолютной изоляции - это компромисс уровня "достаточно хорошо по сравнению с полным отсутствием защиты". Даже полноценная VM автоматически не гарантирует абсолютной защиты от квалифицированного агента: gpt-cyber-vm-escape фиксирует три побега из гостевой системы QEMU/KVM, в то время как VM Firecracker с минимальной поверхностью атаки устояла.
Атаки на цепочку поставок на этапе сборки. Если бинарные файлы самого агента заражены, песочница просто запустит вредоносный код. Стандартные практики supply-chain-security остаются в силе.

Инструменты в вики

bubblewrap-dev-env - Linux, файловая система + процессы (Уровень 1)
hazmat - macOS, пользователь + Seatbelt + фаервол pf (Уровни 1 + 2)
superhq - оркестрация microVM на macOS с изоляцией учётных данных через auth-gateway (Уровни 1 + 1b)
crabtrap - применение политик на уровне HTTP с помощью LLM-судьи (Уровень 3)
syscall-binary-rewriting - контроль на уровне системных вызовов (Уровень 4)
wirez - маршрутизация сети на уровне процессов в Linux (смежно с Уровнем 2, инструмент не специфичен для ИИ, но полезен в стеке)
little-snitch-linux - мониторинг сети отдельных приложений через eBPF в Linux (наблюдаемость Уровня 2)

Связанные страницы

microvm-2026 - индустриальный обзор Бегановича о базе microVM, лежащей в основе большинства современных реализаций Уровня 1
microvm, matryoshka-isolation, rust-vmm - концепции базового слоя в наиболее строгих конфигурациях Уровня 1
human-in-the-loop - альтернатива песочницам: пауза для подтверждения человеком чувствительных операций
supply-chain-security - защита на ранних этапах, снижающая риски для агента
peril-of-laziness-lost - почему агенты в песочницах всё ещё требуют контроля архитектурных решений со стороны человека