Когда AI-агент получает возможность запускать shell-команды, код, браузер или внешние инструменты, model output превращается в потенциальное действие с реальными side effects. Sandbox нужен не как дополнительная защита, а как основной security boundary между reasoning-моделью и инфраструктурой.
Что должен изолировать sandbox
Файловую систему и доступ к host paths.
Сеть и список разрешённых destinations.
Процессы, syscalls и системные capabilities.
Секреты, токены и credentials.
CPU, RAM, disk и execution time.
Действия с внешними системами и необратимыми side effects.
Контейнер — начало, а не вся защита
Обычный контейнер снижает поверхность риска, но не заменяет policy layer. Нужны read-only filesystem где возможно, drop capabilities, non-root user, seccomp/AppArmor-профиль, отдельный tmp workspace и жёсткие лимиты ресурсов. Для более сильной изоляции используют microVM или sandbox runtime.
Файловая система
Монтируйте только рабочую директорию, необходимую задаче.
Не отдавайте агенту домашнюю директорию пользователя и SSH-конфиги.
Разделяйте read-only input и writable output.
Очищайте ephemeral workspace после завершения run.
Проверяйте размер и тип выходных файлов до сохранения.
Сеть
По умолчанию сетевой доступ лучше запрещать и открывать только allowlist. Агент не должен произвольно обращаться к metadata endpoints, внутренним админкам и приватным подсетям. Для HTTP-инструментов полезен egress proxy, который логирует destination, метод и размер ответа.
Секреты и credentials
Не помещайте полный secret store в prompt или environment.
Выдавайте short-lived scoped token под конкретное действие.
Используйте credential broker, который возвращает результат действия, а не сам секрет.
Разделяйте read и write permissions.
Отзывайте токен после завершения run.
Resource limits
Каждый run должен иметь timeout, CPU quota, memory limit, disk quota и ограничение количества дочерних процессов. Это защищает и от случайных бесконечных циклов, и от намеренно вредных инструкций внутри недоверенного input.
Approval для опасных действий
Требуйте подтверждение перед удалением данных, публикацией, оплатой и изменением production.
Показывайте пользователю точную команду или действие и ключевые параметры.
Привязывайте approval к конкретному run/step ID.
После изменения контекста или payload требуйте новое подтверждение.
Prompt injection и untrusted input
Файл, веб-страница или лог могут содержать инструкции для модели. Sandbox должен считать такие данные недоверенными и не позволять им расширять permissions. Решение о доступе к tool принимает policy layer, а не текст из обрабатываемого документа.
Audit trail и observability
Логируйте run ID, tool, аргументы после redaction и outcome.
Сохраняйте exit code, duration и resource usage.
Фиксируйте network destinations и approval events.
Не записывайте токены, cookies и содержимое секретных полей.
Для side-effect действий сохраняйте idempotency key или внешний operation ID.
Короткий production checklist
Non-root execution и минимальные capabilities.
Ephemeral workspace и ограниченные mounts.
Network deny-by-default с allowlist.
Scoped short-lived credentials.
CPU/RAM/disk/time limits.
Approval для high-risk actions.
Audit log без секретов.
Автоматическая очистка sandbox после run.