OpenClaw и безопасность: как сделать мощного агента, который не сломает вам систему

Почему OpenClaw по определению «опасен»

OpenClaw полезен ровно потому, что он умеет делать страшные вещи: запускать shell‑команды, менять файлы, ходить в сеть, управлять умным домом, трогать почту и GitHub. Документация прямо говорит: любой агент, который может запускать инструменты и трогать файловую систему/сети, по умолчанию опасен, и это надо учитывать в конфигурации.

Без настроек безопасности вы получаете:

• Модель, которая может выполнить rm -rf по ошибке.
• Skills из ClawHub, среди которых 12–20% оказываются вредоносными или сомнительными по результатам аудитов.​
• Инстанс, который торчит наружу, если неправильно настроен bind / UI‑доступ.​

Ниже — практический чеклист: sandbox, файлы, токены, OAuth, Home Assistant и skills.

Включаем sandbox: «мягкая комната» для инструментов

Одно из первых требований всех гайдлайнов: включить sandbox‑режим.

Что даёт sandbox

Sandbox в OpenClaw — это режим, при котором инструменты (shell, файловая система и т.д.) исполняются внутри Docker‑контейнеров, а не напрямую на хосте. Gateway остаётся на хосте, но команды запускаются в изолированной среде.

Это не идеальный security boundary, но существенно ограничивает:

• доступ к файловой системе,
• доступ к процессам,
• возможность повредить систему при «глупом» действии модели.

Рекомендации из security‑гайдов:

• В проде высокорисковые задачи никогда не должны исполняться на хосте, только в контейнере.
• Хорошая практика — запускать все сессии (включая основного владельца) в Docker‑sandbox’е, а не только внешних пользователей.​

Как включить sandbox в конфиге

Документация описывает ключ agents.defaults.sandbox и возможность включать sandbox по агентам:​

textagents:
  defaults:
    sandbox:
      enabled: true
      mode: "docker"
  list:
    - id: "external"
      sandbox:
        enabled: true
        mode: "docker"

В продовых гайдах советуют:

• sandbox включён по умолчанию для всех агентов;
• никаких «исключений ради удобства», кроме, возможно, локального CLI‑режима на dev‑машине.

Ограничиваем shell и файловую систему

Даже в sandbox’е инструменты нужно ограничивать. Хороший hardening‑гайд показывает, как конкретно задавать allowlist команд и путей.

Shell‑команды — только по белому списку

Пример из практического гайда:​

texttools:
  shell:
    enabled: true
    # ONLY these commands can execute
    allowlist:
      - "ls"
      - "cat"
      - "grep"
      - "head"
      - "tail"
      - "find"
      - "wc"
      - "sort"

Принцип:

• Вместо того, чтобы давать агенту весь shell, даём строго ограниченный набор команд.
• Никаких rm, chmod, chown, systemctl, docker, kubectl и т.п.

Документы по безопасному использованию skills отдельно подчёркивают: избегайте shell‑команд вообще, если это возможно; лучше использовать специализированные инструменты с валидацией входных данных.​

Filesystem: allowedPaths и deniedPaths

Тот же гайд даёт конфигурацию файловой системы:​

textfilesystem:
  enabled: true
  allowedPaths:
    - "/home/openclaw/workspace"
    - "/home/openclaw/clawd"
  deniedPaths:
    - "/home/openclaw/.ssh"
    - "/home/openclaw/.openclaw/credentials"
    - "/etc"

Общие принципы из нескольких источников:

• Агенту нужен доступ только к workspace и, возможно, одному–двум проектам.
• Нельзя давать доступ к ~/.ssh, менеджерам паролей, /etc, домашнему каталогу целиком «для удобства».
• Даже в sandbox’е лучше ограничивать видимую часть файловой системы.

Правильно настраиваем Gateway и доступы

Gateway только на loopback

Auth0‑гайд по безопасности OpenClaw прямо говорит: gateway.bind должен быть loopback, чтобы не торчать наружу. Аналитика BitSight показала, что немало инстансов Gateway доступны из интернета из‑за неверной конфигурации.

Пример настройки:

textgateway:
  bind: "loopback"      # 127.0.0.1
  controlUi:
    allowFrom:
      - "127.0.0.1"

• bind: "loopback" гарантирует, что сервис слушает только localhost.
• allowFrom ограничивает, откуда можно подключаться к Control UI.

Не отключать защищённую аутентификацию UI

В безопасности Gateway отдельно разбирают параметр gateway.controlUi.allowInsecureAuth. Его включение отключает проверку идентичности устройства и pairing, фактически воспринимая любую сеть как доверенную.​

Вывод: не включать allowInsecureAuth, если вы не полностью контролируете сеть; это сильно снижает защиту.​

Токены, OAuth, почта и GitHub

Прячем токены и ключи

Гайды по hardening подчёркивают: токены и API‑ключи — частая точка компрометации.

Рекомендации:

• Хранить ключи в переменных окружения, а не в открытом виде в конфиг‑файлах.
• Ограничить права на файлы в ~/.openclaw/credentials/ так, чтобы их мог читать только пользователь, под которым запущен OpenClaw.
• Не логировать значения токенов и чувствительные данные; логи должны быть информативными, но не содержать креденшалы.​

Минимизируем OAuth‑права

Security hardening‑гайд показывает классическую ошибку: OAuth‑скоупы «на максимум». Правильный подход — принцип наименьших привилегий:​

text# Плохо:
gmail:
  scope: "full"    # чтение, запись, удаление, отправка

# Лучше:
gmail:
  scope: "readonly"

# Плохо:
github:
  scope: "repo"    # доступ ко всем репам, включая приватные

# Лучше:
github:
  scope: "public_repo"   # только публичные

Дополнительно рекомендуется раз в месяц ревьюить выданные OAuth‑доступы в интерфейсах Google, GitHub и других провайдеров.

Лимиты по токенам и бюджету

Отдельный security‑гайд описывает инциденты, когда из‑за зацикливания агента люди теряли сотни долларов за день. Рекомендуемые меры:​

• На стороне LLM‑провайдера (OpenAI, Anthropic) в дашборде выставить дневные/месячные лимиты.​
• В конфиге OpenClaw ограничить размер контекста и длину генерации для отдельных агентов.
• Настроить регулярные отчёты по расходу токенов и алерты при превышении порогов.​

Skills и ClawHub: как не словить malware

Аудиты показывают, что от 12 до 20% skills в ClawHub можно считать вредоносными или рискованными: они содержат странные сети запросов, обфускацию или избыточные права.

5‑шаговый чеклист безопасности skill’ов

ClawTrust и другие эксперты предлагают такой чеклист:

1. Смотреть на автора. Есть ли у него другие open‑source проекты, активность, история? Или это анонимный one‑off с единственным skill’ом.
2. Читать код. Skills — open source, их нужно просматривать перед установкой. Особенно сетевые запросы и работу с файловой системой.​
3. Проверять права. Календарный skill не должен просить файл‑систему. Поисковый skill не должен иметь write‑права. Избыточные permissions — красный флаг.​
4. Искать обфускацию и подозрительные URL. Base64‑строки, непонятные домены, странные curl/wget‑вызовы — поводы отказаться.
5. Смотреть на maintenance. Заброшенные skills без обновлений и без ответа на issues — зона риска.

После инцидента ClawHavoc (341 вредоносный skill) сразу рекомендовали проводить хотя бы быстрый аудит: проверка launch‑агентов, crontab и свежих модификаций файлов.​

Не ставить «рандомные» skills

Документы по безопасности прямо формулируют: «Не устанавливайте случайные skills» и «Treat every skill as executable code». Даже наличие VirusTotal‑скана для ClawHub не даёт полной гарантии.

Home Assistant и умный дом: ограничиваем сущности

Home Assistant — один из самых чувствительных кейсов: агент получает возможность включать/выключать устройства, менять режимы отопления, открывать замки и т.д..

Рекомендации комьюнити и интеграционных гайдов:

• Не давать OpenClaw прямой long‑lived token Home Assistant с полным доступом.​
• Использовать прослойку (n8n или кастомный API), чтобы экспонировать только выбранные entities.
• Делить задачи: один агент управляет светом, другой — только климатом; не давать агенту список всех сущностей дома.

Практический комментарий из Home Assistant‑комьюнити: такой прокси значительно безопаснее, чем прямой токен, потому что позволяет выдать только небольшой подмножество сущностей и действий.

Сетевой периметр и изоляция

Многие security‑эксперты сходятся: идеальный OpenClaw живёт в изолированном окружении.

Где запускать

Рекомендуются варианты:

• Отдельный пользователь в системе + sandbox.
• Docker‑контейнер с ограниченным доступом.
• VM/devbox, которую можно легко снести и пересоздать.

Некоторые авторы довольно жёстко формулируют: «Для OpenClaw (или чего‑то похожего) сильно рекомендуется запуск в sandbox’е с ограниченным файловым и сетевым доступом. Вы хотите, чтобы в худшем случае был повреждён только этот sandbox».

Network isolation как последний рубеж

В матрице защит одна из пяти обязательных мер — именно изоляция сети:​

• Не давать агенту доступ к внутренним корпоративным сетям.
• Не маппить контейнер с OpenClaw напрямую в интернет.
• По возможности использовать egress‑фильтрацию — ограничивать, куда агент может ходить по HTTP(S).

Практический 5‑пунктный чеклист безопасности

Сводя все гайды вместе, получается довольно компактный чеклист, который рекомендуют как «минимум для продакшена»:

1. Включить sandbox и ограничить файлы/команды.
   • Docker‑sandbox для инструментов.
   • allowedPaths/deniedPaths, allowlist shell‑команд.
2. Ограничить Gateway и UI.
   • bind: loopback, закрыть наружу.
   • Не включать allowInsecureAuth.
   • Restrict allowFrom.
3. Защитить токены, OAuth и лимиты.
   • Хранить ключи в env, ограничить права на файлы.
   • Минимизировать OAuth‑скоупы для Gmail/GitHub и т.п.
   • Поставить лимиты на расход токенов у провайдера и мониторинг.
4. Фильтровать skills и инструменты.
   • Не ставить рандомные skills из ClawHub.
   • Читать SKILL.md и код, смотреть на permissions и сеть.
   • Выключить ненужные tools, особенно shell.
5. Изолировать сеть и окружение.
   • Запускать OpenClaw в контейнере/VM/отдельном пользователе.
   • Не использовать на корпоративных устройствах без ведома IT.​
   • Ограничить доступ к Home Assistant и другим чувствительным системам.

С таким уровнем hardening’а OpenClaw остаётся мощным и иногда «опасным» по возможностям, но вероятность серьёзных и необратимых проблем заметно снижается — именно к этому призывают все серьёзные статьи и оффдоки по безопасности.