Агент написал код. Хорошо. А теперь его нужно запустить — и тут возникает вопрос, который чаще всего игнорируют до первого инцидента: где именно этот код выполняется?
Если ответ «на моей машине» или «в том же контейнере, где работает агент» — это бомба с часовым механизмом. Произвольный код от LLM может удалить файлы, открыть обратный шелл, вытащить секреты из переменных окружения. И это не теоретическая угроза, а обычный вторник.
OpenSandbox решает именно эту задачу — изоляцию исполнения. Не фреймворк для агентов, не оркестратор, а слой под ними: контейнер, который агент запрашивает, получает и использует как чистый лист.
Что это
OpenSandbox — open-source платформа для создания изолированных окружений, в которых AI-агенты могут выполнять код, открывать браузер, запускать модели. Проект вырос из внутренних наработок Alibaba: компания годами гоняла через эту инфраструктуру собственные AI-задачи и в начале 2026 года выложила код в открытый доступ под Apache 2.0.
Ключевая идея — разделение агента и среды исполнения. Агент не решает, как безопасно запустить код. Он отправляет запрос в OpenSandbox, а тот создаёт изолированный контейнер и выполняет задачу внутри. Когда задача закончена — контейнер уничтожается. Никаких следов на хост-машине.
На GitHub проект собрал 12 тысяч звёзд и тысячу форков — для инфраструктурного инструмента это серьёзный показатель. Репозиторий живой: 1907 коммитов, 64 открытых issue, активные pull-запросы.
Важно: OpenSandbox — это не SaaS. Облачного managed-сервиса нет. Вы разворачиваете сервер на своей инфраструктуре и платите только за свои серверы.
Зачем нужно
Допустим, coding-агент вроде Claude Code написал скрипт для анализа данных. Этот скрипт нужно где-то запустить. Если выполнить его прямо на сервере, где работает агент, — код получит полный доступ к файловой системе, сети и переменным окружения. Один неудачный import или ошибочный subprocess — и хост скомпрометирован.
OpenSandbox даёт агенту одноразовый контейнер: агент вызывает API, получает чистое окружение с Python, выполняет скрипт, читает результат. Хост-машина не затронута. Тот же принцип работает для браузинга — агент получает изолированный Chrome внутри sandbox, а не реальный браузер на сервере.
Как устроено
Архитектура — три слоя. Sandbox Protocol определяет API для управления жизненным циклом контейнеров. Sandbox Runtime реализует этот протокол поверх Docker (локальная разработка) или Kubernetes (продакшн). SDK на пяти языках дают разработчикам единый интерфейс поверх обоих runtime.
Sandbox Protocol
Sandbox Protocol — спецификация API, которая описывает два набора операций: управление жизненным циклом (создать, остановить, удалить контейнер) и исполнение (запустить команду, прочитать файл, записать файл). Протокол не привязан к конкретному runtime — можно написать собственный бэкенд, реализующий те же API, и SDK будут работать с ним без изменений.
Sandbox Runtime
Встроенный runtime поддерживает два режима. Docker — для локальной разработки и тестирования: одна машина, один процесс, минимальный порог входа. Kubernetes — для продакшн-масштаба: распределённое планирование, горизонтальное масштабирование, изоляция на уровне подов.
Изоляция
Помимо стандартной контейнерной изоляции Docker, OpenSandbox поддерживает три механизма усиленной изоляции — secure container runtimes. gVisor — пользовательское ядро от Google, перехватывает системные вызовы из контейнера. Kata Containers — легковесная виртуальная машина для каждого контейнера. Firecracker microVM — минимальная ВМ от AWS с ускоренным запуском. Выбор runtime зависит от баланса между безопасностью и накладными расходами.
Credential Vault
Credential Vault — хранилище учётных данных, которое внедряет секреты в исходящие запросы sandbox-контейнера, не раскрывая реальные значения самому workload. Агент получает доступ к API через прокси-слой, который подставляет токены на лету. Сами секреты не попадают в переменные окружения контейнера и не записываются в логи.
Network Policy
Сетевой слой — два контура. Ingress Gateway — единый шлюз входа с несколькими стратегиями маршрутизации. Egress Controls — ограничения на исходящий трафик для каждого контейнера: можно разрешить только конкретные домены или заблокировать доступ к внутренним адресам. Это критично для агентов, которые работают с внешними API, но не должны иметь доступ к инфраструктуре компании.
SDK и CLI
Платформа предоставляет SDK для пяти языков и CLI-инструмент osb. Поддерживаемые SDK:
| Язык | Установка |
|---|---|
| Python | pip install opensandbox |
| TypeScript/JS | npm install @alibaba-group/opensandbox |
| Java/Kotlin | com.alibaba.opensandbox:sandbox |
| C#/.NET | dotnet add package Alibaba.OpenSandbox |
| Go | go get github.com/alibaba/OpenSandbox/sdks/sandbox/go |
CLI-инструмент osb устанавливается отдельно и даёт терминальный доступ к полному циклу: создать sandbox, запустить команду, переместить файлы, проверить диагностику, управлять политикой исходящего трафика.
# Установка CLI
pip install opensandbox-cli
# или через uv
uv tool install opensandbox-cli
# Быстрый старт
osb config init
osb config set connection.domain localhost:8080
osb config set connection.protocol http
osb config set connection.api_key <your-api-key>
# Создать sandbox с Python 3.12, таймаут 30 минут
osb sandbox create --image python:3.12 --timeout 30m -o json
# Запустить команду внутри sandbox
osb command run <sandbox-id> -o raw -- python -c "print(1 + 1)"
MCP-сервер
OpenSandbox поставляет готовый MCP-сервер — он открывает операции создания sandbox, исполнения команд и работы с файлами для MCP-совместимых клиентов: Claude Code, Cursor и других. Установка — одна команда, конфигурация — stdio-транспорт.
pip install opensandbox-mcp
opensandbox-mcp --domain localhost:8080 --protocol http
Минимальная конфигурация для MCP-клиента:
{
"mcpServers": {
"opensandbox": {
"command": "opensandbox-mcp",
"args": ["--domain", "localhost:8080", "--protocol", "http"]
}
}
}
Когда использовать
Пять сценариев, под которые OpenSandbox спроектирован изначально. Все они требуют изоляции, но по-разному.
- Coding Agents — агент генерирует код и сразу прогоняет его в sandbox. Готовые подключения есть для Claude Code, OpenAI Codex и Gemini CLI. Агент получает sandbox, выполняет код, читает stdout — хост не затронут.
- GUI Agents — агент управляет браузером или рабочим столом. Внутри sandbox доступны Chrome, Playwright и VNC-рабочий стол. Полный цикл UI-автоматизации в изоляции.
- AI Code Execution — безопасный интерпретатор кода в вашем продукте. Аналог Code Interpreter у ChatGPT, но на собственной инфраструктуре. Пользователь отправляет код — OpenSandbox выполняет его в контейнере и возвращает результат.
- Agent Evaluation — прогон тестов и бенчмарков для агентов в воспроизводимом окружении. Каждый запуск — чистый контейнер с фиксированной конфигурацией. Результаты сравнимы между запусками.
- RL Training — среда для обучения моделей с подкреплением. Sandbox даёт изолированное пространство, где агент может исследовать окружение без риска для хоста.
Пример
Развернём сервер локально и запустим код в sandbox. Требования: Docker и Python 3.10+.
Сервер: Docker
# Установка сервера
pip install opensandbox-server
# Инициализация конфига для Docker
opensandbox-server init-config ~/.sandbox.toml --example docker
# Запуск
opensandbox-server
Сервер: Kubernetes
Для продакшна — тот же пакет, другой пример конфига:
pip install opensandbox-server
opensandbox-server init-config ~/.sandbox.toml --example k8s
opensandbox-server
Python SDK: Code Interpreter
Установка SDK и интерпретатора:
pip install opensandbox opensandbox-code-interpreter
Подключение — две переменные окружения:
export SANDBOX_DOMAIN=... # адрес sandbox-сервера
export SANDBOX_API_KEY=... # ключ доступа
Создание sandbox и выполнение кода на Python:
import asyncio
from datetime import timedelta
from code_interpreter import CodeInterpreter, SupportedLanguage
from opensandbox import Sandbox
from opensandbox.models import WriteEntry
async def main() -> None:
# 1. Создать sandbox
sandbox = await Sandbox.create(
"opensandbox/code-interpreter:v1.1.0",
entrypoint=["/opt/code-interpreter/code-interpreter.sh"],
env={"PYTHON_VERSION": "3.11"},
timeout=timedelta(minutes=10),
)
async with sandbox:
# 2. Выполнить shell-команду
execution = await sandbox.commands.run("echo 'Hello OpenSandbox!'")
print(execution.logs.stdout[0].text)
# 3. Записать файл
await sandbox.files.write_files([
WriteEntry(path="/tmp/hello.txt", data="Hello World", mode=644)
])
# 4. Прочитать файл
content = await sandbox.files.read_file("/tmp/hello.txt")
print(f"Content: {content}")
# 5. Создать code interpreter
interpreter = await CodeInterpreter.create(sandbox)
# 6. Выполнить Python-код
result = await interpreter.codes.run(
"""
import sys
print(sys.version)
result = 2 + 2
result
""",
language=SupportedLanguage.PYTHON,
)
print(result.result[0].text) # 4
print(result.logs.stdout[0].text) # 3.11.14
# 7. Закрыть sandbox
await sandbox.kill()
if __name__ == "__main__":
asyncio.run(main())
TypeScript / JavaScript
npm install @alibaba-group/opensandbox
Интеграции с AI-инструментами
OpenSandbox поддерживает интеграцию из коробки с пятью инструментами:
- Claude Code (Anthropic)
- OpenAI Codex
- Gemini CLI (Google)
- LangGraph
- Google ADK
Тарифы
Платформа бесплатная и распространяется под Apache 2.0 — лицензия разрешает коммерческое использование, модификацию и распространение без отчислений. Облачного managed-сервиса нет: вы разворачиваете сервер на своих машинах и несёте только инфраструктурные расходы.
Стартовый сценарий — один сервер с Docker. Если нагрузка растёт, тот же пакет переконфигурируется на Kubernetes-кластер.
Сравнение с альтернативами
Рынок sandbox-платформ для AI делится на два лагеря: SaaS-сервисы (платишь за использование, ноль DevOps) и self-hosted OSS (свой сервер, полный контроль). OpenSandbox и Daytona — во втором, E2B и Modal — в первом.
| Параметр | OpenSandbox | E2B | Modal | Daytona |
|---|---|---|---|---|
| Тип | Self-hosted OSS | SaaS | SaaS | Self-hosted OSS |
| Лицензия | Apache 2.0 | Проприетарная | Проприетарная | Apache 2.0 |
| Стоимость | Бесплатно | Pay-per-use | Pay-per-use | Бесплатно |
| GUI / браузер | Да | Нет | Нет | Нет |
| RL Training | Да | Нет | Частично | Нет |
| Kubernetes | Да | Нет | Нет | Да |
Ключевое отличие OpenSandbox от всех трёх — GUI и браузер внутри sandbox. Ни E2B, ни Modal, ни Daytona не предоставляют полноценный Chrome с Playwright и VNC-рабочим столом. Для coding-агентов это может быть неважно, но для GUI-агентов это решающий фактор.
OpenSandbox оправдан, когда вы готовы держать свою инфраструктуру и вам нужен браузер внутри sandbox. E2B и Modal подходят, если DevOps-команды нет и хочется начать за пять минут. Daytona — компромисс для тех, кому нужен self-hosted Kubernetes без GUI.
Ограничения
Ограничения
Что учитывать
Перед внедрением нужно понимать границы платформы.
Только self-hosted — Managed-облака не существует.
Разворачивать на своих серверах — обязательно нужен Docker, для продакшна — Kubernetes.
Молодой проект — Код открыли в начале 2026 года.
Экосистема формируется, плагины и расширения появляются, но зрелости SaaS-платформ пока нет.
Персистентное хранилище — Долговременное хранение данных между запусками sandbox — в планах разработчиков.
Пока контейнер уничтожен — данные потеряны.
Документация
— Базовые сценарии описаны, но нестандартные кейсы требуют чтения исходного кода.
Порог DevOps — pip install недостаточно — это серверная инфраструктура.
Нужно понимать Docker и Kubernetes.
Антипаттерны
Антипаттерны
Чего не делать
Типичные ошибки при работе с OpenSandbox.
Docker runtime в продакшне — Docker-режим предназначен для локальной разработки.
Для продакшна в README указан Kubernetes runtime с поддержкой secure container runtimes: gVisor, Kata Containers, Firecracker.
Секреты в переменных окружения контейнера — Credential Vault внедряет секреты через прокси-слой, не раскрывая значения.
Секреты не попадают в переменные окружения и не записываются в логи.
Открытый исходящий трафик
— Egress Controls позволяют ограничить исходящий трафик для каждого контейнера: разрешить конкретные домены или заблокировать доступ к внутренним адресам.
Хост без Docker-изоляции — Sandbox Runtime работает поверх Docker или Kubernetes.
Без Docker локальный runtime не запускается — это указано в требованиях к серверу.
Чеклист
Чеклист
Проверка перед запуском
Что проверить перед внедрением OpenSandbox.
Docker — требуется для локального runtime.
Без Docker сервер не запускается.
Python 3.10+ — Требуется для opensandbox-server и SDK.
Установка: pip install opensandbox-server.
Конфиг сервера — Команда opensandbox-server init-config с примером docker или k8s.
Примеры есть в поставке.
API-ключ — Переменная SANDBOX_API_KEY.
Без неё SDK не подключится к серверу.
Egress Controls — Ограничения исходящего трафика для каждого контейнера.
Настраиваются через CLI: osb.
Secure container runtime — gVisor, Kata Containers или Firecracker.
Выбор зависит от баланса между безопасностью и накладными расходами.
Ссылки
Ссылки
- Репозиторий: alibaba/OpenSandbox
- Сайт: open-sandbox.ai
- Документация: architecture.md
- Документация: examples/README.md
- Репозиторий: @alibaba-group/opensandbox (npm)