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

Если ответ «на моей машине» или «в том же контейнере, где работает агент» — это бомба с часовым механизмом. Произвольный код от 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:

ЯзыкУстановка
Pythonpip install opensandbox
TypeScript/JSnpm install @alibaba-group/opensandbox
Java/Kotlincom.alibaba.opensandbox:sandbox
C#/.NETdotnet add package Alibaba.OpenSandbox
Gogo 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 — в первом.

ПараметрOpenSandboxE2BModalDaytona
ТипSelf-hosted OSSSaaSSaaSSelf-hosted OSS
ЛицензияApache 2.0ПроприетарнаяПроприетарнаяApache 2.0
СтоимостьБесплатноPay-per-usePay-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.

Выбор зависит от баланса между безопасностью и накладными расходами.

Ссылки

Ссылки