Hermes на личном или рабочем компьютере

Вы собираетесь запустить автономного ИИ-агента на своём компьютере — личном ноутбуке или рабочей станции под контролем работодателя. Какая конфигурация будет безопасной?

Короткий ответ: львиную долю работы уже выполняют настройки по умолчанию. Hermes поставляется безопасным изначально: эшелонированная защита охватывает подтверждение команд, безопасность записи файлов и работу с учётными данными. На этой странице разберём, что включено из коробки, какие параметры стоит подтянуть для общего или рабочего компьютера, и как отменить ошибку, если она всё же произошла. Каждый механизм подробно описан в справочнике Безопасность.

Что защищено по умолчанию

Сразу после установки, без всякой настройки, уже работают следующие механизмы:

Опасные команды требуют подтверждения. Перед выполнением любой команды Hermes сверяет её со списком опасных паттернов — рекурсивное удаление, запись в /etc/, операции с диском, pipe в shell и другие. Режим по умолчанию approvals.mode: smart оценивает риск с помощью вспомогательной LLM: команды с низким риском получают автоматическое разрешение только для себя, откровенно опасные автоматически отклоняются, а неоднозначные случаи выносятся на ручное подтверждение.

Запрос на подтверждение по умолчанию отказывает. Если вы не отреагировали на запрос в течение тайм-аута (по умолчанию 300 секунд), команда отклоняется. Отойти от компьютера — не значит молча разрешить что-то.

Жёсткий чёрный список работает всегда. Некоторые команды — rm -rf /, fork-бомбы, обнуление физического диска — отклоняются независимо от режима подтверждения, флага --yolo или явного «разрешить всегда». Чёрный список срабатывает раньше, чем команда вообще попадает на уровень подтверждения, и обойти его никаким флагом нельзя.

Запись в чувствительные пути заблокирована. Инструменты write_file и patch не могут трогать хранилища учётных данных ОС (~/.ssh/, ~/.aws/, ~/.kube/, /etc/sudoers, ~/.netrc), хранилища учётных данных самого Hermes (auth.json, .env, данные сопряжения) и файлы секретов проекта (.env, .env.local, .envrc) — где бы они ни находились на диске. Заблокированная запись сразу возвращает ошибку: запроса на подтверждение нет, и обойти это из интерфейса чата невозможно.

Секреты вычищаются из вывода. Параметр security.redact_secrets включён по умолчанию: всё, что похоже на API-ключи, токены и пароли в выводе инструментов, вырезается ещё до того, как попадёт в контекст разговора и в логи.

Ваши данные уходят только туда, куда вы укажете. Запросы к API идут только к тому провайдеру модели, который вы настроили. Hermes Agent не собирает телеметрию, статистику использования и аналитику. Переписка, память и навыки хранятся локально, в ~/.hermes/. Подробнее — в FAQ.

инфо

Это не всё — есть ещё защита от SSRF во всех инструментах, работающих с URL, отфильтрованное окружение для подпроцессов MCP, проверка файлов контекста на prompt-инъекции. Страница Безопасность описывает каждый слой защиты.

Усиление защиты для общего или рабочего компьютера

Если на компьютере хранятся данные работодателя, продакшн-учётки или чужие файлы, добавьте к умолчаниям следующее.

Переключите подтверждения в ручной режим

Режим smart автоматически разрешает команды с низким риском. Если хотите видеть каждую помеченную команду лично:

approvals:
  mode: manual

В ручном режиме перед выполнением помеченной команды запрос выводится всегда.

Добавьте собственные правила запрета

approvals.deny — список glob-паттернов, которые безусловно блокируют совпадающие команды терминала — даже при --yolo, /yolo или mode: off. Это редактируемый пользователем аналог встроенного жёсткого чёрного списка. Используйте его, чтобы объявить то, что на этом компьютере не должно выполняться никогда:

approvals:
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Паттерны — это регистронезависимые glob-выражения fnmatch, которые сверяются с полным текстом команды; сравнение проходит по тем же нормализованным и деобфусцированным вариантам, что использует детектор опасных паттернов, поэтому простые трюки с кавычками правило не обходят. Паттерны всегда берите в кавычки — незакавыченная звёздочка * в начале строки вызывает ошибку разбора YAML. Изменения применяются сразу, без перезапуска. Подробности: Пользовательские правила запрета.

Изолируйте запись файлов

Переменная HERMES_WRITE_SAFE_ROOT ограничивает write_file и patch перечисленными префиксами каталогов — всё, что за их пределами, блокируется жёстко. В Unix несколько корней разделяются символом ::

export HERMES_WRITE_SAFE_ROOT=/path/to/project:/home/you/.hermes

Чувствительные пути внутри безопасного корня всё равно остаются заблокированными — даже если указать $HOME, запись в ~/.ssh/id_rsa не разрешится.

осторожно

Не добавляйте эту переменную в ~/.hermes/.env не подумав. Если указать только каталог проекта, агент не сможет писать в ~/.hermes/cron/jobs.json, навыки профиля и прочее состояние Hermes за пределами этого пути. Добавьте домашний каталог Hermes вторым корнем, как показано выше.

Вынесите выполнение команд за пределы хоста

Самая надёжная изоляция — вообще не выполнять команды на своей машине. Инструмент терминала поддерживает несколько бэкендов:

Бэкенд	Изоляция
`local`	Нет — выполняется на хосте (проверки опасных команд применяются)
`docker`	Контейнер — сам контейнер служит границей безопасности
`ssh`	Удалённая машина — выполнение остаётся на отдельном сервере

terminal:
  backend: docker
  docker_image: "nousresearch/hermes-sandbox:desktop"
  docker_forward_env: []  # Только явный список разрешений; пустой список не пускает секреты в контейнер

Каждый Docker-контейнер запускается с усиленными настройками: все Linux capabilities сброшены (с минимальным набором возвращённых), включён no-new-privileges, ограничено число процессов, размеры tmpfs-монтирований лимитированы. При контейнерном бэкенде деструктивные команды внутри контейнера не могут навредить хосту — поэтому проверки опасных команд там пропускаются.

Для ssh укажите terminal.backend: ssh в config.yaml и данные хоста через TERMINAL_SSH_HOST, TERMINAL_SSH_USER и TERMINAL_SSH_KEY в ~/.hermes/.env. Подробнее — в разделе Сетевая изоляция.

Если включены мессенджеры: списки разрешений и сопряжение

Запускаете шлюз на этом компьютере? По умолчанию доступ уже закрыт: если списки разрешений не настроены и GATEWAY_ALLOW_ALL_USERS не задан, доступ запрещён всем пользователям. Держите список явным:

# ~/.hermes/.env
TELEGRAM_ALLOWED_USERS=123456789
GATEWAY_ALLOWED_USERS=123456789

Либо используйте сопряжение через личные сообщения вместо жёстко прописанных ID: неизвестным пользователям выдаётся одноразовый код сопряжения, а вы подтверждаете их из CLI командой hermes pairing approve <platform> <code>. Никогда не задавайте GATEWAY_ALLOW_ALL_USERS=true на компьютере, который вам дорог.

Слой отмены: контрольные точки и `/rollback`

Подтверждения предотвращают ущерб, а контрольные точки его отменяют. Если функция включена, Hermes автоматически делает снимок проекта перед деструктивными операциями — write_file, patch и деструктивными командами терминала вроде rm, mv, sed -i и git reset — в теневое git-хранилище под ~/.hermes/checkpoints/store/. Настоящий .git вашего проекта при этом не трогается.

Контрольные точки отключены по умолчанию, их нужно включить. Для одной сессии:

hermes chat --checkpoints

Или глобально:

checkpoints:
  enabled: true

Затем внутри сессии:

Команда	Описание
`/rollback`	Показать все контрольные точки со статистикой изменений
`/rollback diff <N>`	Предпросмотр изменений с контрольной точки N
`/rollback <N>`	Откатиться к контрольной точке N (также отменяет последний ход чата)
`/rollback <N> <file>`	Восстановить один файл из контрольной точки N

совет

Перед восстановлением просматривайте изменения через /rollback diff <N>, а для максимальной надёжности сочетайте контрольные точки с git worktree: каждая сессия Hermes — в своём отдельном worktree, а контрольные точки — как дополнительный слой защиты.

Что защищает эта модель угроз — и чего не защищает

Оценивайте трезво, от чего именно защищают эти механизмы. Как сказано в справочнике Безопасность:

Правила запрета — это защита от честного, но ошибающегося агента, та же модель угроз, что и у детектора опасных паттернов. Это не песочница против намеренно враждебного процесса — для этого нужен изолированный бэкенд (Docker, Modal) или среда с ограничением исходящего трафика.

То же самое касается защиты записи файлов: она распространяется только на write_file и patch, тогда как инструмент terminal работает от того же пользователя ОС. Список запрета снижает риск случайного ущерба и даёт модели чёткий сигнал остановиться — он не изолирует враждебного или скомпрометированного агента. Если нужна именно изоляция, а не ограждение, ответ — изолированный бэкенд терминала: эта граница спроектирована именно для этого.

Осторожная стартовая конфигурация

Всё перечисленное выше — в сборе. Подстройте под себя в ~/.hermes/config.yaml:

approvals:
  mode: manual                  # Видеть каждую помеченную команду лично
  timeout: 300                  # Неотвеченные запросы отклоняются (fail-closed)
  deny:                         # Список «никогда не выполнять» — работает даже при /yolo
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

security:
  redact_secrets: true          # Уже включено по умолчанию; указано здесь для ясности

checkpoints:
  enabled: true                 # Снимок перед деструктивными операциями

terminal:
  backend: docker               # Или ssh — держите выполнение вне хоста
  docker_forward_env: []        # Секреты хоста не попадают в контейнер

А в ~/.hermes/.env, если нужна песочница записи:

HERMES_WRITE_SAFE_ROOT=/path/to/project:/home/you/.hermes

Смотрите также

Безопасность — полный справочник эшелонированной защиты: все паттерны подтверждения, флаги усиления контейнеров, авторизация шлюза, фильтрация учётных данных MCP
Контрольные точки и откат — настройка, обслуживание хранилища и сценарии восстановления
Инструменты и наборы инструментов — все бэкенды терминала и их настройка
Конфигурация — полный справочник по config.yaml