Sandbox для агентов

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

Простыми словами

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

Главная идея проста: агент получает не весь сервер, а временное и ограниченное место для работы. В нем можно разрешить ровно то, что нужно задаче: например, читать один каталог, обращаться только к одному домену, жить не дольше 10 минут и не иметь доступа к переменным окружения продакшена.

• Изоляция — агент отделен от хоста и других задач.
• Ограничение прав — доступ выдается по принципу минимально необходимого.
• Эфемерность — среда создается под задачу и уничтожается после выполнения.
• Наблюдаемость — действия логируются и могут требовать подтверждения человека.

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

Как это работает

Обычно архитектура делится на два контура: control plane и execution plane. Первый принимает задачу, решает, какие инструменты можно выдать, и применяет политику безопасности. Второй исполняет действия в изолированной среде.

Типичный цикл

1. Пользователь или система ставит задачу агенту.
2. Оркестратор определяет набор разрешенных инструментов и данных.
3. Под задачу создается sandbox: контейнер, микровиртуальная машина или удаленная сессия браузера.
4. В sandbox передаются временные учетные данные, входные файлы и лимиты.
5. Агент выполняет шаги, а система пишет журнал: команды, сетевые вызовы, созданные файлы, результаты.
6. На опасных действиях можно поставить ручное подтверждение.
7. После завершения среда уничтожается, артефакты сохраняются отдельно.

Слой	Что ограничивает	Практический смысл
Изоляция процесса или контейнера	Файлы, процессы, ресурсы	Ошибка кода агента не валит хост и соседние задачи
Сетевая политика	Исходящие и входящие соединения	Можно разрешить только нужные API и домены
Временные секреты	Срок и объем доступа	Даже при утечке токен быстро теряет силу
Лимиты CPU, RAM, времени	Потребление ресурсов	Защита от бесконечных циклов и дорогих задач
Логи и approvals	Риск необратимых действий	Можно остановить удаление, оплату, публикацию

С технической точки зрения sandbox бывает разной глубины. Контейнеры удобны и быстры, но не равны полной виртуализации. Микровиртуальные машины дают более жесткую границу изоляции, но сложнее и дороже в эксплуатации. Для браузерных агентов часто используют отдельный удаленный браузер или изолированный рабочий стол.

Критически важно, что sandbox — это не только вычислительная среда, но и политика доступа: allowlist доменов, read-only тома, запрет записи в чувствительные каталоги, отключение системных вызовов, недоступность внутренних метаданных облака и так далее.

Зачем нужно

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

Второе — управление правами. Агенту редко нужен доступ ко всему. Для выгрузки отчета достаточно одного бакета, одного API и временного токена. Sandbox помогает превратить это в исполнимую политику, а не только в регламент на бумаге.

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

Четвертое — мультитенантность. Если один runtime обслуживает разных пользователей или команды, изоляция предотвращает утечку файлов и артефактов между сессиями.

Но есть и обратная сторона. Sandbox добавляет задержку на запуск, усложняет оркестрацию, требует наблюдаемости и увеличивает стоимость инфраструктуры. Для простого read-only поиска по документам можно обойтись без него.

Пример

Представим внутреннего аналитического агента, который должен взять CSV из хранилища, посчитать сводную таблицу в Python и открыть веб-интерфейс BI только для проверки итогов.

1. Оркестратор создает sandbox на 15 минут с 2 ГБ RAM и без доступа к внутренней сети компании.
2. В среду монтируется только каталог /input с нужным CSV и каталог /output для результата.
3. Агент получает временный токен только на чтение одного объекта в хранилище и allowlist из двух внешних доменов: хранилища и BI.
4. Агент запускает Python-скрипт, строит агрегаты и сохраняет файл отчета в /output.
5. Затем он открывает BI в изолированном браузере, сверяет несколько чисел и формирует текстовое резюме.
6. Попытка обратиться к другому домену, прочитать переменные окружения хоста или отправить файл в сторонний сервис блокируется политикой.
7. После завершения оркестратор забирает артефакты, сохраняет лог и уничтожает среду.

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

Заблуждения и ограничения

Заблуждение 1: sandbox делает агента безопасным. Нет. Он лишь уменьшает последствия ошибки. Если агенту разрешен доступ к платежному API, он все равно может выполнить неверное действие в рамках этих прав.

Заблуждение 2: достаточно контейнера. Не всегда. Контейнер — это способ упаковки и базовой изоляции, но итоговая безопасность зависит от сетевой политики, секретов, системных ограничений, образов, журналирования и процесса approvals.

Заблуждение 3: sandbox защищает от prompt injection сам по себе. Нет. Он ограничивает каналы воздействия, но не отменяет необходимости фильтровать инструменты, отделять инструкции системы от внешнего контента и проверять опасные действия.

Ограничение 1: накладные расходы. Запуск среды, прогрев образов, управление артефактами и логами увеличивают задержку и стоимость.

Ограничение 2: сложность состояния. Долгоживущим агентам неудобно работать в полностью эфемерной среде. Нужно отдельно проектировать хранилище состояния, кеши и передачу контекста между запусками.

Ограничение 3: не подходит для некоторых задач. Если агенту нужен прямой доступ к локальным USB-устройствам, privileged-режим, низкоуровневое администрирование хоста или очень жесткие требования к latency, sandbox может мешать больше, чем помогать.

Ограничение 4: риск через разрешенные каналы. Если открыт исходящий интернет, агент может попытаться вывести данные через разрешенный домен, форму или webhook. Поэтому важны не только блокировки, но и контроль содержимого, redaction и approvals.

Практический вывод такой: sandbox — базовый строительный блок для агентных систем с действиями, но не самостоятельная гарантия безопасности. Его надо сочетать с принципом минимальных прав, проверкой инструментов, управлением секретами и человеческим контролем для необратимых операций.

Частые вопросы

Чем sandbox для агентов отличается от обычного контейнера?

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

Нужен ли sandbox, если агент только читает документы?

Не всегда. Если агент ограничен retrieval без исполнения кода и без внешних действий, можно обойтись более простой моделью доступа. Но как только появляются Python, браузер, CLI или запись через API, sandbox становится почти обязательным.

Можно ли давать агенту доступ в интернет из sandbox?

Можно, но лучше по allowlist. Открытый исходящий доступ сильно повышает риск утечки данных и усложняет контроль. Для большинства рабочих сценариев достаточно списка конкретных доменов и протоколов.

Где хранить результаты, если среда эфемерная?

Артефакты нужно выгружать во внешнее хранилище: объектный storage, БД, систему логов или очередь задач. Сама sandbox должна считаться временной и не использоваться как постоянное хранилище состояния.

Связанные понятия

• Tool calling — механизм, через который модель вызывает функции, API или внешние инструменты.
• Execution environment — среда исполнения кода; sandbox является ее защищенным вариантом.
• Least privilege — принцип минимально необходимых прав для агента и его инструментов.
• Secret management — выдача и ротация временных токенов, ключей и учетных данных.
• Prompt injection — попытка внешнего контента изменить поведение агента и заставить его нарушить политику.
• Human-in-the-loop — подтверждение человеком рискованных или необратимых действий агента.
• MicroVM — облегченная виртуальная машина, часто используемая там, где нужна более жесткая изоляция, чем у контейнера.