🏠 Главная › User Guide › security

sidebar_position: 8 title: "Security" description: "Security model, dangerous command approval, user authorization, container isolation, and production deployment best practices" lang: ru

Безопасность

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

Обзор

Модель безопасности имеет семь уровней:

  1. Авторизация пользователя — кто может разговаривать с агентом (белые списки, соединение DM)
  2. Одобрение опасного командования — участие человека в разрушительных операциях
  3. Изоляция контейнера — Docker/Singularity/модальная песочница с усиленными настройками.
  4. Фильтрация учетных данных MCP — изоляция переменных среды для подпроцессов MCP.
  5. Сканирование контекстных файлов — оперативное обнаружение внедрения в файлы проекта.
  6. Межсессионная изоляция — сеансы не могут получить доступ к данным или состоянию друг друга; Пути хранения заданий cron защищены от атак с обходом пути
  7. Очистка ввода — параметры рабочего каталога в бэкэнде терминального инструмента проверяются на соответствие списку разрешенных, чтобы предотвратить внедрение оболочки.

Утверждение опасной команды

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

Режимы одобрения

Система одобрения поддерживает три режима, настроенных через approvals.mode в ~/.hermes/config.yaml:

approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # seconds to wait for user response (default: 60)
Режим Поведение
ручной (по умолчанию) Всегда запрашивать у пользователя подтверждение опасных команд
умный Используйте вспомогательный LLM для оценки риска. Команды с низким уровнем риска (например, python -c "print('hello')") одобряются автоматически. Действительно опасные команды автоматически отклоняются. Сомнительные случаи переходят к подсказке вручную.
выкл. Отключите все проверки одобрения — это эквивалентно запуску с --yolo. Все команды выполняются без подсказок.

:::предупреждение Настройка approvals.mode: off отключает все запросы безопасности. Используйте только в доверенных средах (CI/CD, контейнеры и т. д.).

Режим ЙОЛО

Режим YOLO обходит все запросы на одобрение опасных команд для текущего сеанса. Его можно активировать тремя способами:

  1. Флаг CLI: запустите сеанс с помощью hermes --yolo или hermes chat --yolo.
  2. Команда косой черты: введите /yolo во время сеанса, чтобы включить или выключить ее.
  3. Переменная среды: установите HERMES_YOLO_MODE=1.

Команда /yolo представляет собой переключатель — при каждом использовании режим включается или выключается:

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

> /yolo
  ⚠ YOLO mode OFF — dangerous commands will require approval.

Режим YOLO доступен как в сеансах CLI, так и в сеансах шлюза. Внутри он устанавливает переменную среды HERMES_YOLO_MODE, которая проверяется перед каждым выполнением команды.

:::опасность Режим YOLO отключает все проверки безопасности опасных команд для сеанса — кроме жесткого черного списка (см. ниже). Используйте только в том случае, если вы полностью доверяете генерируемым командам (например, хорошо проверенным сценариям автоматизации в одноразовых средах).

Жесткий черный список (всегда на этаже)

Некоторые команды настолько катастрофичны — необратимые очистки файловой системы, форк-бомбы, прямая запись на блок-устройства — что Hermes отказывается запускать их независимо от:

Черный список находится этажом ниже --yolo. Он срабатывает до того, как уровень утверждения увидит команду, и флаг переопределения отсутствует. Охваченные на данный момент шаблоны (не исчерпывающие; синхронизируются с tools/approval.py::UNRECOVERABLE_BLOCKLIST):

Узор Почему это жестко
rm -rf / и очевидные варианты Очищает корень файловой системы
rm -rf --no-preserve-root / Явный вариант «да, я имею в виду root»
:(){ :\|:& };: (бомба-вилка) Привязывает хост до перезагрузки
mkfs.* на смонтированном корневом устройстве Форматирует живую систему
dd if=/dev/zero of=/dev/sd* Обнуляет физический диск
Передача ненадежных URL-адресов на sh на верхнем уровне rootfs Вектор атаки с удаленным выполнением кода слишком широк, чтобы его можно было одобрить

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

Тайм-аут одобрения

При появлении опасной командной строки у пользователя есть настраиваемое время для ответа. Если в течение таймаута не получен ответ, команда по умолчанию отклонена (закрытие при сбое).

Настройте таймаут в ~/.hermes/config.yaml:

approvals:
  timeout: 60  # seconds (default: 60)

Что вызывает одобрение

Следующие шаблоны вызывают запросы на утверждение (определенные в tools/approval.py):

Узор Описание
rm -r / rm --recursive Рекурсивное удаление
rm ... / Удалить в корневом пути
chmod 777/666 / o+w / a+w Разрешения на запись для всех/других
chmod --recursive с небезопасной завивкой Рекурсивный мир/записываемый другими (длинный флаг)
chown -R root / chown --recursive root Рекурсивное управление root
mkfs Формат файловой системы
dd if= Копия диска
> /dev/sd Записать на блокировку устройства
DROP TABLE/DATABASE SQL ПАДЕНИЕ
DELETE FROM (без ГДЕ) SQL DELETE без WHERE
TRUNCATE TABLE SQL УСЕЧЕНИЕ
> /etc/ Перезаписать конфигурацию системы
systemctl stop/restart/disable/mask Остановить/перезапустить/отключить системные службы
kill -9 -1 Убить все процессы
pkill -9 Принудительное уничтожение процессов
Выкройки вилочных бомб Вилочные бомбы
bash -c / sh -c / zsh -c / ksh -c Выполнение команд оболочки с помощью флага -c (включая комбинированные флаги, такие как -lc)
python -e / perl -e / ruby -e / node -c Выполнение скрипта через флаг -e/-c
curl ... \| sh / wget ... \| sh Перенаправить удаленный контент в оболочку
bash <(curl ...) / sh <(wget ...) Выполнить удаленный скрипт через подстановку процесса
от tee до /etc/, ~/.ssh/, ~/.hermes/.env Перезаписать конфиденциальный файл через тройник
> / >> до /etc/, ~/.ssh/, ~/.hermes/.env Перезаписать конфиденциальный файл с помощью перенаправления
xargs rm xargs с rm
find -exec rm / find -delete Находка с разрушительными действиями
cp/mv/install до /etc/ Скопировать/переместить файл в конфигурацию системы
sed -i / sed --in-place на /etc/ Редактирование конфигурации системы на месте
pkill/killall гермес/шлюз Предотвращение самоликвидации
gateway run с &/disown/nohup/setsid Предотвращает запуск шлюза за пределами диспетчера служб

:::информация Обход контейнера: при работе в серверных модулях docker, singularity, modal, daytona или vercel_sandbox проверки опасных команд пропускаются, поскольку контейнер сам по себе является границей безопасности. Деструктивные команды внутри контейнера не могут нанести вред хосту.

Поток утверждения (CLI)

В интерактивном интерфейсе командной строки опасные команды отображают встроенный запрос на одобрение:

  ⚠️  DANGEROUS COMMAND: recursive delete
      rm -rf /tmp/old-project

      [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

      Choice [o/s/a/D]:

Четыре варианта:

Поток утверждения (шлюз/обмен сообщениями)

На платформах обмена сообщениями агент отправляет в чат детали опасной команды и ждет ответа пользователя:

– Ответьте да, да, одобрить, ок или идти, чтобы одобрить. – Чтобы отклонить, ответьте нет, n, отклонить или отменить.

Переменная среды HERMES_EXEC_ASK=1 автоматически устанавливается при запуске шлюза.

Постоянный белый список

Команды, одобренные с помощью «всегда», сохраняются в ~/.hermes/config.yaml:

# Permanently allowed dangerous command patterns
command_allowlist:
  - rm
  - systemctl

Эти шаблоны загружаются при запуске и автоматически одобряются во всех последующих сеансах.

:::совет Используйте hermes config edit, чтобы просмотреть шаблоны или удалить их из постоянного белого списка.

Авторизация пользователя (шлюз)

При запуске шлюза обмена сообщениями Hermes контролирует, кто может взаимодействовать с ботом, через многоуровневую систему авторизации.

Порядок проверки авторизации

Метод _is_user_authorized() проверяет в следующем порядке:

  1. Флаг разрешения всего для каждой платформы (например, DISCORD_ALLOW_ALL_USERS=true)
  2. Список одобренных сопряжений DM (пользователи, одобренные с помощью кодов сопряжения)
  3. Списки разрешений для конкретной платформы (например, TELEGRAM_ALLOWED_USERS=12345,67890)
  4. Глобальный белый список (GATEWAY_ALLOWED_USERS=12345,67890)
  5. Глобальное разрешение (GATEWAY_ALLOW_ALL_USERS=true)
  6. По умолчанию: запретить

Белые списки платформы

Установите разрешенные идентификаторы пользователей в виде значений, разделенных запятыми, в ~/.hermes/.env:

# Platform-specific allowlists
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
WHATSAPP_ALLOWED_USERS=15551234567
SLACK_ALLOWED_USERS=U01ABC123

# Cross-platform allowlist (checked for all platforms)
GATEWAY_ALLOWED_USERS=123456789

# Per-platform allow-all (use with caution)
DISCORD_ALLOW_ALL_USERS=true

# Global allow-all (use with extreme caution)
GATEWAY_ALLOW_ALL_USERS=true

:::предупреждение Если списки разрешенных не настроены и GATEWAY_ALLOW_ALL_USERS не задан, всем пользователям запрещено. Шлюз регистрирует предупреждение при запуске:

No user allowlists configured. All unauthorized users will be denied.
Set GATEWAY_ALLOW_ALL_USERS=true in ~/.hermes/.env to allow open access,
or configure platform allowlists (e.g., TELEGRAM_ALLOWED_USERS=your_id).

Система сопряжения DM

Для более гибкой авторизации Hermes включает систему сопряжения на основе кода. Вместо того, чтобы заранее требовать идентификаторы пользователей, неизвестные пользователи получают одноразовый код сопряжения, который владелец бота утверждает через CLI.

Как это работает:

  1. Неизвестный пользователь отправляет боту в Директ
  2. Бот отвечает 8-значным кодом сопряжения.
  3. Владелец бота запускает hermes pairing approve <platform> <code> в CLI.
  4. Пользователь навсегда одобрен для этой платформы.

Контролируйте обработку несанкционированных прямых сообщений в ~/.hermes/config.yaml:

unauthorized_dm_behavior: pair

whatsapp:
  unauthorized_dm_behavior: ignore

Функции безопасности (на основе рекомендаций OWASP + NIST SP 800-63-4):

Особенность Подробности
Формат кода 8-значный из 32-значного однозначного алфавита (без 0/O/1/I)
Случайность Криптографический (secrets.choice())
Код ТТЛ Срок действия 1 час
Ограничение скорости 1 запрос на пользователя за 10 минут
Ожидаемый лимит Максимум 3 ожидающих кода на платформу
Локаут 5 неудачных попыток одобрения → блокировка на 1 час
Безопасность файлов chmod 0600 во всех файлах данных сопряжения
Ведение журнала Коды никогда не выводятся на стандартный вывод

Сопряжение команд CLI:

# List pending and approved users
hermes pairing list

# Approve a pairing code
hermes pairing approve telegram ABC12DEF

# Revoke a user's access
hermes pairing revoke telegram 123456789

# Clear all pending codes
hermes pairing clear-pending

Хранение: Данные о сопряжении хранятся в ~/.hermes/pairing/ в файлах JSON для каждой платформы: - {platform}-pending.json — ожидающие запросы на сопряжение - {platform}-approved.json — одобренные пользователи - _rate_limits.json — ограничение скорости и отслеживание блокировки

Изоляция контейнера

При использовании серверной части терминала docker компания Hermes применяет строгие меры безопасности к каждому контейнеру.

Флаги безопасности Docker

Каждый контейнер запускается со следующими флагами (определенными в tools/environments/docker.py):

_SECURITY_ARGS = [
    "--cap-drop", "ALL",                          # Drop ALL Linux capabilities
    "--cap-add", "DAC_OVERRIDE",                  # Root can write to bind-mounted dirs
    "--cap-add", "CHOWN",                         # Package managers need file ownership
    "--cap-add", "FOWNER",                        # Package managers need file ownership
    "--security-opt", "no-new-privileges",         # Block privilege escalation
    "--pids-limit", "256",                         # Limit process count
    "--tmpfs", "/tmp:rw,nosuid,size=512m",         # Size-limited /tmp
    "--tmpfs", "/var/tmp:rw,noexec,nosuid,size=256m",  # No-exec /var/tmp
    "--tmpfs", "/run:rw,noexec,nosuid,size=64m",   # No-exec /run
]

Ограничения ресурсов

Ресурсы контейнера настраиваются в ~/.hermes/config.yaml:

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []  # Explicit allowlist only; empty keeps secrets out of the container
  container_cpu: 1        # CPU cores
  container_memory: 5120  # MB (default 5GB)
  container_disk: 51200   # MB (default 50GB, requires overlay2 on XFS)
  container_persistent: true  # Persist filesystem across sessions

Сохранение файловой системы

:::совет Для развертывания рабочего шлюза используйте серверную часть docker, modal, daytona или vercel_sandbox, чтобы изолировать команды агента от вашей хост-системы. Это полностью устраняет необходимость в одобрении опасного командования. :::предупреждение Если вы добавите имена в terminal.docker_forward_env, эти переменные намеренно вводятся в контейнер для команд терминала. Это полезно для учетных данных для конкретной задачи, таких как GITHUB_TOKEN, но это также означает, что код, выполняющийся в контейнере, может прочитать и извлечь их.

Сравнение безопасности серверной части терминала

Бэкэнд Изоляция Опасная проверка CMD Лучшее для
местный Нет — работает на хосте ✅ Да Развитие, доверенные пользователи
тсс Удаленная машина ✅ Да Запуск на отдельном сервере
докер Контейнер ❌ Пропущено (контейнер является границей) Производственный шлюз
необычность Контейнер ❌ Пропущено среды HPC
модальный Облачная песочница ❌ Пропущено Масштабируемая изоляция облака
дайтона Облачная песочница ❌ Пропущено Постоянные облачные рабочие пространства
vercel_sandbox Облачная микроВМ ❌ Пропущено Облачное выполнение с сохранением моментальных снимков

Передача переменной среды {#environment-variable-passthrough}

И execute_code, и terminal удаляют конфиденциальные переменные среды из дочерних процессов, чтобы предотвратить кражу учетных данных с помощью кода, сгенерированного LLM. Однако навыки, которые объявляют required_environment_variables, законно нуждаются в доступе к этим переменным.

Как это работает

Два механизма позволяют определенным переменным проходить через фильтры песочницы:

1. Передача на уровне навыка (автоматически)

Когда навык загружается (через skill_view или команду /skill) и объявляет required_environment_variables, любая из тех переменных, которые фактически установлены в среде, автоматически регистрируется как сквозная. Отсутствующие переменные (все еще находящиеся в состоянии, необходимом для установки) не регистрируются.

# In a skill's SKILL.md frontmatter
required_environment_variables:
  - name: TENOR_API_KEY
    prompt: Tenor API key
    help: Get a key from https://developers.google.com/tenor

После загрузки этого навыка TENOR_API_KEY передается на execute_code, terminal (локальный) и удаленные серверные части (Docker, Modal) — ручная настройка не требуется.

ℹ️ Info

Докер и модал До версии 0.5.1 `forward_env` Docker была отдельной системой от прохождения навыков. Теперь они объединены — переменные окружения, объявленные навыками, автоматически пересылаются в контейнеры Docker и модальные песочницы без необходимости добавлять их в `docker_forward_env` вручную.

2. Передача на основе конфигурации (вручную)

Для переменных окружения, не объявленных каким-либо навыком, добавьте их в terminal.env_passthrough в config.yaml:

terminal:
  env_passthrough:
    - MY_CUSTOM_KEY
    - ANOTHER_TOKEN

Передача файла учетных данных (токены OAuth и т. д.) {#credential-file-passthrough}

Некоторым навыкам необходимы файлы (а не только переменные окружения) в песочнице — например, Google Workspace хранит токены OAuth как google_token.json под HERMES_HOME активного профиля. Навыки объявляют это во вступительной части:

required_credential_files:
  - path: google_token.json
    description: Google OAuth2 token (created by setup script)
  - path: google_client_secret.json
    description: Google OAuth2 client credentials

При загрузке Hermes проверяет, существуют ли эти файлы в HERMES_HOME активного профиля, и регистрирует их для монтирования:

Вы также можете вручную перечислить файлы учетных данных в config.yaml:

terminal:
  credential_files:
    - google_token.json
    - my_custom_oauth_token.json

Пути указаны относительно ~/.hermes/. Файлы монтируются в /root/.hermes/ внутри контейнера.

Что фильтрует каждая песочница

Песочница Фильтр по умолчанию Переопределение проходного режима
execute_code Блокирует переменные, содержащие KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL, PASSWD, AUTH в имени; разрешает только переменные с безопасным префиксом через ✅ Вары Passthrough обходят обе проверки
терминал (локальный) Блокирует явные переменные инфраструктуры Hermes (ключи провайдера, токены шлюза, ключи API инструментов) ✅ Вары Passthrough обходят черный список
терминал (Докер) По умолчанию нет переменных окружения хоста ✅ Проходные переменные + docker_forward_env, пересылаемые через -e
терминал (модальный режим) По умолчанию нет хост-окружения/файлов ✅ Файлы учетных данных смонтированы; передача env через синхронизацию
MCP Блокирует все, кроме безопасных системных переменных + явно настроенных env ❌ Не зависит от транзитной передачи (вместо этого используйте конфигурацию MCP env)

Вопросы безопасности

Обработка учетных данных MCP

Подпроцессы сервера MCP (Model Context Protocol) получают фильтрованную среду для предотвращения случайной утечки учетных данных.

Переменные безопасной среды

Только эти переменные передаются от хоста к подпроцессам MCP stdio:

PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR

Плюс любые переменные XDG_*. Все остальные переменные среды (ключи API, токены, секреты) удалены.

Переменные, явно определенные в конфигурации env сервера MCP, передаются через:

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..."  # Only this is passed

Редактирование учетных данных

Сообщения об ошибках от инструментов MCP обрабатываются перед возвратом в LLM. Следующие шаблоны заменяются на [REDACTED]:

Политика доступа к веб-сайту

Вы можете ограничить доступ агента к веб-сайтам с помощью веб-инструментов и инструментов браузера. Это полезно для предотвращения доступа агента к внутренним службам, панелям администратора или другим конфиденциальным URL-адресам.

# In ~/.hermes/config.yaml
security:
  website_blocklist:
    enabled: true
    domains:
      - "*.internal.company.com"
      - "admin.example.com"
    shared_files:
      - "/etc/hermes/blocked-sites.txt"

При запросе заблокированного URL-адреса инструмент возвращает ошибку, объясняющую, что домен заблокирован политикой. Черный список применяется для web_search, web_extract, browser_navigate и всех инструментов с поддержкой URL.

Подробную информацию см. в разделе Черный список веб-сайтов в руководстве по настройке.

SSRF-защита

Все инструменты с поддержкой URL-адресов (веб-поиск, веб-извлечение, видение, браузер) проверяют URL-адреса перед их получением, чтобы предотвратить атаки подделки запросов на стороне сервера (SSRF). К заблокированным адресам относятся:

Защита SSRF всегда активна при использовании с выходом в Интернет, а сбои DNS рассматриваются как заблокированные (закрытые при сбое). Цепочки перенаправления повторно проверяются на каждом прыжке, чтобы предотвратить обходы на основе перенаправления.

Намеренное разрешение частных URL-адресов

Некоторым установкам законно необходим доступ к частному/внутреннему URL-адресу — домашние сети, которые разрешают home.arpa в пространство RFC 1918, конечные точки Ollama/llama.cpp только для локальной сети, внутренние вики-сайты, отладка облачных метаданных и тому подобное. В таких случаях предусмотрен глобальный отказ:

security:
  allow_private_urls: true   # default: false

При включении веб-инструменты, браузер, выборка URL-адресов Vision и загрузка мультимедиа через шлюз больше не отклоняют RFC 1918/loopback/link-local/CGNAT/адреса облачных метаданных. Это преднамеренная граница доверия — включайте ее только на компьютерах, где агент, запускающий произвольные URL-адреса, введенные из подсказки, в локальной сети, представляет собой приемлемый риск. Общедоступные шлюзы должны его отключить.

Защита подстроки хоста (которая блокирует похожие трюки домена Unicode, даже если базовый IP-адрес является общедоступным) остается включенным независимо от этого параметра.

Тирит Предварительное сканирование безопасности

Hermes интегрирует tirith для сканирования команд на уровне содержимого перед их выполнением. Тирит обнаруживает угрозы, которые пропускает только сопоставление с образцом:

Тирит автоматически устанавливается из выпусков GitHub при первом использовании с проверкой контрольной суммы SHA-256 (и проверкой происхождения cosign, если cosign доступен).

# In ~/.hermes/config.yaml
security:
  tirith_enabled: true       # Enable/disable tirith scanning (default: true)
  tirith_path: "tirith"      # Path to tirith binary (default: PATH lookup)
  tirith_timeout: 5          # Subprocess timeout in seconds
  tirith_fail_open: true     # Allow execution when tirith is unavailable (default: true)

Если tirith_fail_open имеет значение true (по умолчанию), команды продолжаются, если tirith не установлен или истекло время ожидания. Установите false в средах с высоким уровнем безопасности, чтобы блокировать команды, когда Тирит недоступен.

Вердикт Тирита интегрируется с потоком одобрения: безопасные команды проходят, в то время как как подозрительные, так и заблокированные команды вызывают одобрение пользователя с полным выводом тирита (серьезность, заголовок, описание, более безопасные альтернативы). Пользователи могут одобрить или отклонить — по умолчанию выбран вариант «Отклонить», чтобы обеспечить безопасность автоматических сценариев.

Защита от внедрения контекстного файла

Файлы контекста (AGENTS.md, .cursorrules, SOUL.md) сканируются на предмет внедрения подсказки перед включением в системную подсказку. Сканер проверяет:

Заблокированные файлы показывают предупреждение:

[BLOCKED: AGENTS.md contained potential prompt injection (prompt_injection). Content not loaded.]

Лучшие практики для производственного развертывания

Контрольный список развертывания шлюза

  1. Установите явные списки разрешенных — никогда не используйте GATEWAY_ALLOW_ALL_USERS=true в рабочей среде.
  2. Использовать серверную часть контейнера — установите terminal.backend: docker в config.yaml.
  3. Ограничить ограничения ресурсов — установите соответствующие ограничения на ЦП, память и диск.
  4. Надежное хранение секретов — храните ключи API в ~/.hermes/.env с соответствующими правами доступа к файлам.
  5. Включить сопряжение DM — по возможности используйте коды сопряжения вместо жесткого кодирования идентификаторов пользователей.
  6. Просмотр списка разрешенных команд — периодически проверяйте command_allowlist в config.yaml.
  7. Установить MESSAGING_CWD — не разрешать агенту работать из конфиденциальных каталогов.
  8. Запускать от имени пользователя без полномочий root — никогда не запускайте шлюз от имени пользователя root.
  9. Отслеживать журналы — проверьте ~/.hermes/logs/ на наличие попыток несанкционированного доступа.
  10. Поддерживайте обновления — регулярно запускайте hermes update для получения обновлений безопасности.

Защита ключей API

# Set proper permissions on the .env file
chmod 600 ~/.hermes/.env

# Keep separate keys for different services
# Never commit .env files to version control

Сетевая изоляция

Для максимальной безопасности запустите шлюз на отдельной машине или виртуальной машине:

terminal:
  backend: ssh
  ssh_host: "agent-worker.local"
  ssh_user: "hermes"
  ssh_key: "~/.ssh/hermes_agent_key"

Благодаря этому соединения шлюза для обмена сообщениями отделены от выполнения команд агента.