Перейти к содержимому
7 мин чтения

Песочница Hermes Agent: изоляция терминала, сеть и права для агента с доступом к shell

hermes agentпесочницабезопасностьdockerself-hostedнастройка

Главная опасность агента с доступом к терминалу — не сам shell, а то, что по умолчанию этот shell работает прямо на вашем компьютере от имени вашего пользователя. Hermes Agent решает это песочницей: выполнение команд агента можно вынести в отдельный Docker-контейнер с урезанными правами, ограниченной сетью и рабочей папкой, которая не трогает ваши файлы. Дальше — четыре проверенных шага, как включить такую изоляцию, и честный список того, что она не закрывает. Все ключи и команды сверены с исходным кодом релиза Hermes Agent v0.21.7 и официальной документацией.

Главное коротко

  • Песочница изолирует только терминал агента. Сам процесс Hermes, инструменты работы с файлами, браузер и другие части живут вне контейнера — об этом ниже.
  • В docker-режиме подтверждения опасных команд отключаются. Hermes перестаёт переспрашивать, потому что границей безопасности теперь служит сам контейнер. Значит, настройка контейнера — это и есть вся защита.
  • Сеть, папки и переменные окружения — три ворот, которые вы открываете сами. По умолчанию они закрыты; дыры появляются только от явных ключей.

На чём это проверено

Статья написана по релизу Hermes Agent v0.21.7 (опубликован 12 октября 2026 года). Команды и ключи конфигурации сверены с исходным кодом этого релиза (файлы tools/environments/docker.py, tools/terminal_tool_config.py, tools/approval.py) и страницами официальной документации «Configuration» и «Security». Там, где документация и код расходятся — например, лимит числа процессов в документации указан как 256, а в коде v0.21.7 стоит 2048, — в статье приведено значение из кода.

Что изолируется, а что нет

Это самый важный раздел, потому что именно здесь случаются ложные ожидания. Песочница в Hermes Agent — это песочница терминала, а не всего приложения.

ПоверхностьВ песочнице?Пояснение
Команды терминала (shell агента)ДаВыполняются внутри контейнера
Процесс Hermes и gatewayНетВсегда работает на хосте
Инструменты работы с файламиНетОграничиваются отдельным механизмом (запретные пути, safe-root), не этим контейнером
Браузер и компьютерная работаНетНе уезжают в docker-песочницу терминала
Команды через ! в CLIНетВыполняются на хосте

Шаг 1. Убедиться, что Docker работает

Hermes использует Docker как среду для песочницы. Проверьте, что он установлен и запущен:

docker version

Если вместо Docker вы пользуетесь Podman, Hermes поддержит и его — достаточно указать бинарник переменной окружения HERMES_DOCKER_BINARY=podman. Если контейнерный движок недоступен, Hermes предложит вернуть backend на локальный, но тогда песочницы не будет.

Шаг 2. Переключить backend терминала на docker

По умолчанию команды агента выполняются локально (backend: local). Переключение — одна команда:

hermes config set terminal.backend docker

Вернуть как было — hermes config unset terminal.backend. Проверить, что записалось:

hermes config get terminal.backend
# docker

Включить backend — это ещё не изоляция. Дальше нужно закрыть сеть и папки, иначе контейнер будет лишь чуть лучше локального запуска. Если хотите, чтобы границы настроил и проверил тот, кто делает это регулярно, — проверим изоляцию и права агента до того, как он получит доступ к shell.

Шаг 3. Затянуть границы: сеть, папки, переменные

Дальше — самое важное. Контейнер по умолчанию получает сеть, а рабочая папка по умолчанию переживает сессии. Для первого запуска разумнее начать с самого закрытого варианта и открывать только то, что реально нужно. Откройте конфигурацию (hermes config edit) и добавьте блок:

terminal:
  backend: docker
  cwd: /workspace
  docker_image: "nousresearch/hermes-sandbox:desktop"
  docker_network: false              # --network=none — контейнер без сети
  container_persistent: false        # рабочая папка на tmpfs, исчезает после сессии
  docker_persist_across_processes: false  # не переиспользовать контейнер между запусками
  docker_mount_cwd_to_workspace: false     # не подключать текущую папку хоста
  docker_forward_env: []             # не пробрасывать переменные окружения хоста
  docker_volumes: []                 # не пробрасывать папки хоста

Три ключа с false можно выставить и отдельными командами — hermes config set сам приводит строку к нужному типу:

hermes config set terminal.docker_network false
hermes config set terminal.container_persistent false
hermes config set terminal.docker_persist_across_processes false

Что даёт такой набор:

  • Без сети. Агент не сможет выкачать и запустить что-то извне — но не сможет и установить пакеты. Для задач, где контейнеру нужен интернет, верните docker_network: true.
  • Временная папка. Всё, что агент создаст в /workspace, пропадёт после сессии. Хостовые файлы контейнер не видит.
  • Без чужих переменных. По умолчанию переменные окружения хоста в контейнер не попадают — API-ключи и токены остаются снаружи.

Шаг 4. Проверить, что применилось на самом деле

Конфигурация — это обещание, а не факт. После первого запуска агента убедитесь, что контейнер поднялся именно с теми ограничениями, которые вы задали:

hermes config get terminal.backend          # docker
docker ps                                   # контейнер с образом hermes-sandbox
docker inspect <имя> --format '{{.HostConfig.NetworkMode}}'  # none
docker inspect <имя> --format '{{json .HostConfig.CapDrop}}'  # ["ALL"]

Строка none означает, что сеть отключена; CapDrop: ["ALL"] — что контейнер поднят без полного набора привилегий. Полная диагностика — hermes doctor.

Почему в docker-режиме пропадают подтверждения

В локальном режиме Hermes переспрашивает опасные команды — удаление, изменения системы, работу с docker — через систему подтверждений. Когда backend переключён на docker (как и на singularity, modal, daytona или vercel_sandbox), эти проверки пропускаются: предполагается, что границей безопасности стал сам контейнер, а команда внутри него не может навредить хосту.

Из этого следует ровно один вывод: вся защита теперь в настройке контейнера. Если вы включили docker, но при этом открыли сеть, пробросили папки и передали ключи — подтверждения всё равно молчат, и агент делает всё это без спроса. Поэтому порядок такой: сначала затянуть границы (шаг 3), потом давать агенту доступ к терминалу, а не наоборот.

Три ключа, которые открывают дыру

Ровно три способа осознанно ослабить песочницу, и их стоит знать поимённо:

  • docker_forward_env — список переменных окружения, которые попадут из хоста в контейнер. Удобно для токена вроде GITHUB_TOKEN, но тогда код внутри контейнера может его прочитать и вывести наружу. Пустой список — закрыто.
  • docker_volumes — проброс папок хоста в контейнер по синтаксису хост:контейнер[:ro]. Любая такая запись — дыра, которую вы открыли сами и сознательно.
  • docker_mount_cwd_to_workspace — подключить папку, из которой запущен Hermes, в /workspace контейнера. Удобно, чтобы агент видел проект, — но тогда он видит и правит ваши файлы.

Правило простое: не добавляйте в эти три ключа ничего, чего вы не готовы отдать агенту целиком.

Что песочница не закрывает

Честный список ограничений, чтобы не было ложного спокойствия:

  • Сам процесс Hermes и gateway всегда работают на хосте. Песочница — только про терминал агента.
  • Инструменты работы с файлами ограничиваются другим механизмом — запретным списком путей и (в официальном образе) корнем /opt/data, а не этим контейнером.
  • Браузер и computer use не уезжают в docker-песочницу терминала.
  • Лимиты ресурсов (CPU, память, число процессов) применяются, только когда Docker реально делегирует cgroup-контроллеры; на rootless-установках и в LXC их могут молча пропустить.

Когда не стоит делать это самому

Сама настройка занимает минут десять. Сложность не в командах, а в том, что ошибиться можно молча: контейнер поднимется, а сеть останется открытой, или в контейнер утечёт токен, и вы узнаете об этом только из счёта или инцидента. Если агент получает доступ к боевым данным, а не к тестовому контуру, периметр разумнее спроектировать заранее, чем чинить последствия.

Частые вопросы

Песочница Hermes Agent платная?

Нет. Hermes Agent — проект с открытым исходным кодом, и docker-песочница терминала — штатная функция без отдельной оплаты. Платить нужно только за модель, которой пользуется агент, и за сервер, если вы держите его у себя.

Что выбрать — Docker или Singularity?

Для большинства — Docker (или Podman). Singularity/Apptainer имеет смысл на HPC-кластерах, где Docker запрещён политикой. Изоляция по смыслу одна и та же: это контейнерный backend терминала.

Можно ли оставить подтверждения опасных команд в docker-режиме?

Нет — для контейнерных backend'ов проверки опасных команд пропускаются по замыслу. Но запретные списки approvals.deny работают иначе: они применяются до любых проверок и действуют в том числе внутри контейнера. Это и есть способ запретить конкретные команды даже в docker-режиме.

Песочница защищает от prompt-инъекций?

Частично. Контейнер ограничивает, куда может дотянуться исполняемый код, но не решает, на что агент согласится под давлением текста. Это отдельная задача со своими инструментами.

Как быстро вернуть всё как было?

hermes config unset terminal.backend

— и снова локальный режим с подтверждениями опасных команд.

Если песочницу нужно не просто включить, а встроить в рабочий контур — с сервером, обновлениями и резервными копиями — возьмём Hermes Agent на управляемый хостинг с изолированной средой исполнения.