OpenClaw Sandbox: изолируйте агентов до доступа к коду

17 июн. 2026 г.3 мин чтения

Share with

Содержание

Почему OpenClaw sandbox должна быть безопасным стандартом

Агенты в стиле OpenClaw полезны, потому что запускают команды, редактируют файлы, устанавливают пакеты и продолжают работу в фоне. Поэтому им нужна sandbox до доступа к настоящему репозиторию, общей .env или пути деплоя.

Office Claws не является нативным рантаймом OpenClaw. Но безопасная модель та же: локальная панель управления, рискованная работа в одноразовых runner-ах и Codex-backed агенты внутри ограниченного workspace. Если вы ещё выбираете слой исполнения, начните с OpenClaw vs Codex. Здесь мы разбираем sandbox вокруг агента.

Граница доверия OpenClaw sandbox от локального хранилища до одноразового runner

Что должно быть внутри sandbox

Хорошая OpenClaw sandbox меньше, чем ноутбук разработчика, и строже, чем обычный VPS.

Слой	Правило sandbox	Зачем это нужно
Код	Свежая ветка или worktree на задачу	Один агент не ломает работу другого
Секреты	Ограниченный токен, не операторское хранилище	Меньше ущерб после prompt injection
Сеть	Разрешить package registry и GitHub; остальное проверять	Меньше риск утечки и неожиданных callback
Файлы	Записываемый repo, временный cache, без мусора в home	Надёжная очистка
Runtime	Лимиты CPU, памяти, времени и расходов	Останавливает runaway-команды и API-циклы
Выход	PR, patch, logs и результат тестов	Упрощает review

Это практическая версия OpenClaw security best practices: агент полезен, но среда может быть затронута недоверенным кодом.

Практическая архитектура

Безопасная схема состоит из локальной машины, credential broker, одноразового runner и review gate.

Office Claws desktop
  ├─ хранит долгоживущие credentials локально
  ├─ утверждает задачу, ветку, бюджет и правила runner
  └─ возвращает logs и status оператору
        │
        ▼
credential broker
  └─ выдаёт короткоживущий repo token для одной задачи
        │
        ▼
VPS sandbox
  ├─ свежий checkout или worktree
  ├─ Codex-backed исполнение
  ├─ без production secrets на диске
  └─ уничтожить или сбросить после завершения
        │
        ▼
PR / patch review

Для remote-исполнения смотрите OpenClaw on VPS и OpenClaw desktop manager. Office Claws for OpenClaw users здесь выступает локальным операционным слоем: координирует runner-ы, собирает видимость и не превращает случайный терминал в control plane.

Какие сбои должна ограничивать sandbox

Сбои и контроли OpenClaw sandbox

Prompt injection из репозитория. Issues, README, package scripts и fixtures не являются доверенным вводом.
Скомпрометированные зависимости. Runner может ставить пакеты, но должен быть одноразовым.
Неконтролируемые расходы. Бюджеты на model calls, runtime, queue и retries предотвращают дорогие циклы.
Грязные workspaces. Одна задача означает одну ветку, один worktree и одну поверхность review.

Поэтому OpenClaw monitoring должен идти рядом с sandbox: logs и recovery — это меры безопасности.

Минимальный чеклист

Создавайте свежий worktree или VM на каждую значимую задачу.
Используйте GitHub tokens с scope на repo и коротким сроком.
Держите provider keys локально или через broker.
Не пускайте production credentials в runner-ы.
Запускайте тесты в sandbox и публикуйте результат с patch.
Показывайте logs без SSH-раскопок.
Удаляйте или сбрасывайте runner после задачи.

Цель не в том, чтобы лишить агентов силы. Цель — сделать ошибки дешёвыми, видимыми и обратимыми.

Где помогает Office Claws

Office Claws упрощает эту схему: desktop management, VPS runners, queue visibility, log review и безопасное локальное хранение ключей. Сегодня это Codex-first продукт; честный тезис не в том, что Office Claws нативно запускает OpenClaw, а в том, что OpenClaw-командам нужен устойчивый операционный слой.

Читайте Office Claws for OpenClaw users, OpenClaw vs Codex и затем OpenClaw secrets management.