🏠 Главная › Документация › Руководство

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

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

Обзор

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

  1. Авторизация пользователей — кто может общаться с агентом (белые списки, DM-сопряжение)

  2. Подтверждение опасных команд — human-in-the-loop для деструктивных операций

  3. Изоляция контейнеров — Docker/Singularity/Modal-песочницы с усиленными настройками

  4. Фильтрация учётных данных MCP — изоляция переменных окружения для подпроцессов MCP

  5. Сканирование контекстных файлов — обнаружение prompt-инъекций в файлах проекта

  6. Изоляция между сессиями — сессии не могут получить доступ к данным или состоянию друг друга; пути хранения задач cron защищены от path traversal-атак

  7. Санитизация ввода — параметры рабочего каталога в бэкендах терминала проверяются по белому списку для предотвращения shell-инъекций

Подтверждение опасных команд

Перед выполнением любой команды Hermes проверяет её по составленному списку опасных шаблонов. При совпадении пользователь должен явно подтвердить выполнение.

Режимы подтверждения

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

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

YOLO-режим

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

  1. Флаг CLI: Запустить сессию с hermes --yolo или hermes chat --yolo

  2. Слэш-команда: Введите /yolo во время сессии для переключения вкл/выкл

  3. Переменная окружения: Установите HERMES_YOLO_MODE=1

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

> /yolo
  ⚡ YOLO mode ON — все команды автоодобряются. Используйте с осторожностью.

> /yolo
  ⚠ YOLO mode OFF — опасные команды будут требовать подтверждения.

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

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

Жёсткий блок-лист (всегда включён)

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

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

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

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

Тайм-аут подтверждения

Когда появляется запрос на подтверждение опасной команды, у пользователя есть настраиваемое время для ответа. Если ответ не получен в течение тайм-аута, команда отклоняется по умолчанию (fail-closed).

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

approvals:
  timeout: 60  # секунд (по умолчанию: 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 DROP
DELETE FROM (без WHERE) SQL DELETE без WHERE
TRUNCATE TABLE SQL TRUNCATE
> /etc/ Перезапись системного конфига
systemctl stop/restart/disable/mask Остановка/перезапуск/отключение системных служб
kill -9 -1 Убить все процессы
pkill -9 Принудительное завершение процессов
Fork bomb-шаблоны Fork-бомбы
bash -c / sh -c / zsh -c / ksh -c Выполнение shell-команды через флаг -c (включая комбинированные флаги типа -lc)
python -e / perl -e / ruby -e / node -c Выполнение скрипта через флаг -e/-c
curl ... | sh / wget ... | sh Перенаправление удалённого содержимого в shell
bash <(curl ...) / sh <(wget ...) Выполнение удалённого скрипта через подстановку процесса
tee в /etc/, ~/.ssh/, ~/.hermes/.env Перезапись конфиденциального файла через tee
> / >> в /etc/, ~/.ssh/, ~/.hermes/.env Перезапись конфиденциального файла через перенаправление
xargs rm xargs с rm
find -exec rm / find -delete Find с деструктивными действиями
cp/mv/install в /etc/ Копирование/перемещение файла в системный конфиг
sed -i / sed --in-place на /etc/ Редактирование системного конфига на месте
pkill/killall hermes/gateway Предотвращение самоуничтожения
gateway run с &/disown/nohup/setsid Предотвращает запуск gateway вне менеджера служб
**Обход контейнера**: При работе в бэкендах `docker`, `singularity`, `modal`, `daytona` или `vercel_sandbox` проверки опасных команд **пропускаются**, поскольку сам контейнер является границей безопасности. Деструктивные команды внутри контейнера не могут навредить хосту.

Процесс подтверждения (CLI)

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

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

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

      Choice [o/s/a/D]:

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

Процесс подтверждения (Gateway/Мессенджеры)

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

Переменная окружения HERMES_EXEC_ASK=1 автоматически устанавливается при запуске gateway.

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

Команды, подтверждённые как «always», сохраняются в ~/.hermes/config.yaml:

# Постоянно разрешённые шаблоны опасных команд
command_allowlist:
  - rm
  - systemctl

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

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

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

При запуске messaging gateway 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. По умолчанию: запрет

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

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

# Белые списки для конкретных платформ
TELEGRAM_ALLOWED_USERS=123456789,987654321
DISCORD_ALLOWED_USERS=111222333444555666
WHATSAPP_ALLOWED_USERS=15551234567
SLACK_ALLOWED_USERS=U01ABC123

# Кросс-платформенный белый список (проверяется для всех платформ)
GATEWAY_ALLOWED_USERS=123456789

# Разрешить всех на платформе (использовать с осторожностью)
DISCORD_ALLOW_ALL_USERS=true

# Глобальное разрешение всех (использовать с крайней осторожностью)
GATEWAY_ALLOW_ALL_USERS=true
Если **не настроены белые списки** и не установлен `GATEWAY_ALLOW_ALL_USERS`, **все пользователи отклоняются**. Gateway логирует предупреждение при запуске: 
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 включает систему сопряжения на основе кодов. Вместо того чтобы требовать ID пользователей заранее, неизвестные пользователи получают одноразовый код сопряжения, который владелец бота подтверждает через CLI.

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

  1. Неизвестный пользователь отправляет DM боту

  2. Бот отвечает 8-символьным кодом сопряжения

  3. Владелец бота запускает hermes pairing approve <platform> <code> в CLI

  4. Пользователь получает постоянный доступ к этой платформе

Управляйте поведением обработки неавторизованных DM в ~/.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())
TTL кода Истекает через 1 час
Ограничение частоты 1 запрос на пользователя каждые 10 минут
Лимит ожидающих Макс. 3 ожидающих кода на платформу
Блокировка 5 неудачных попыток → блокировка на 1 час
Безопасность файлов chmod 0600 на всех файлах данных сопряжения
Логирование Коды никогда не логируются в stdout

Команды CLI для сопряжения:

# Список ожидающих и одобренных пользователей
hermes pairing list

# Подтвердить код сопряжения
hermes pairing approve telegram ABC12DEF

# Отозвать доступ пользователя
hermes pairing revoke telegram 123456789

# Очистить все ожидающие коды
hermes pairing clear-pending

Хранение: Данные сопряжения хранятся в ~/.hermes/pairing/ в JSON-файлах по платформам:

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

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

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

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

_SECURITY_ARGS = [
    "--cap-drop", "ALL",                          # Сбросить ВСЕ Linux-способности
    "--cap-add", "DAC_OVERRIDE",                  # Root может писать в смонтированные каталоги
    "--cap-add", "CHOWN",                         # Менеджерам пакетов нужно владение файлами
    "--cap-add", "FOWNER",                        # Менеджерам пакетов нужно владение файлами
    "--security-opt", "no-new-privileges",         # Блокировать повышение привилегий
    "--pids-limit", "256",                         # Лимит количества процессов
    "--tmpfs", "/tmp:rw,nosuid,size=512m",         # /tmp с ограничением по размеру
    "--tmpfs", "/var/tmp:rw,noexec,nosuid,size=256m",  # Без exec в /var/tmp
    "--tmpfs", "/run:rw,noexec,nosuid,size=64m",   # Без exec в /run
]

Лимиты ресурсов

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

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []  # Только явный белый список; пустой массив не пропускает секреты в контейнер
  container_cpu: 1        # Ядра CPU
  container_memory: 5120  # МБ (по умолчанию 5 ГБ)
  container_disk: 51200   # МБ (по умолчанию 50 ГБ, требуется overlay2 на XFS)
  container_persistent: true  # Сохранять файловую систему между сессиями

Постоянство файловой системы

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

Сравнение безопасности бэкендов терминала

Бэкенд Изоляция Проверка опасных команд Лучше всего для
local Нет — выполняется на хосте ✅ Да Разработка, доверенные пользователи
ssh Удалённая машина ✅ Да Запуск на отдельном сервере
docker Контейнер ❌ Пропущено (контейнер — граница) Продакшн gateway
singularity Контейнер ❌ Пропущено HPC-среды
modal Облачная песочница ❌ Пропущено Масштабируемая облачная изоляция
daytona Облачная песочница ❌ Пропущено Постоянные облачные рабочие области
vercel_sandbox Облачная microVM ❌ Пропущено Облачное выполнение с сохранением состояния снимков

Проброс переменных окружения {#environment-variable-passthrough}

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

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

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

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

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

# В frontmatter SKILL.md навыка
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 (local), и удалённые бэкенды (Docker, Modal) — без необходимости ручной настройки.

info Docker & Modal До версии v0.5.1 параметр Docker forward_env был отдельной системой, не связанной с пробросом навыков. Теперь они объединены — переменные окружения, объявленные навыком, автоматически передаются в контейнеры Docker и песочницы Modal без необходимости добавлять их в 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 активного профиля. Навыки объявляют это в frontmatter:

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 в имени; пропускает только переменные с безопасным префиксом ✅ Пробрасываемые переменные обходят обе проверки
terminal (local) Блокирует явные инфраструктурные переменные Hermes (ключи провайдеров, gateway-токены, API-ключи инструментов) ✅ Пробрасываемые переменные обходят блок-лист
terminal (Docker) Никаких переменных хоста по умолчанию ✅ Пробрасываемые переменные + docker_forward_env передаются через -e
terminal (Modal) Никаких файлов/переменных хоста по умолчанию ✅ Файлы учётных данных монтируются; проброс 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_..."  # Передаётся только это

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

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

Политика доступа к сайтам

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

# В ~/.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 (веб-поиск, извлечение веб-страниц, vision, браузер), проверяют URL перед их загрузкой для предотвращения Server-Side Request Forgery (SSRF) атак. Заблокированные адреса включают:

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

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

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

security:
  allow_private_urls: true   # по умолчанию: false

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

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

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

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

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

# В ~/.hermes/config.yaml
security:
  tirith_enabled: true       # Включить/отключить сканирование tirith (по умолчанию: true)
  tirith_path: "tirith"      # Путь к бинарнику tirith (по умолчанию: поиск в PATH)
  tirith_timeout: 5          # Тайм-аут подпроцесса в секундах
  tirith_fail_open: true     # Разрешить выполнение, когда tirith недоступен (по умолчанию: true)

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

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

Защита от инъекций в контекстных файлах

Контекстные файлы (AGENTS.md, .cursorrules, SOUL.md) сканируются на предмет prompt-инъекций перед включением в системный промпт. Сканер проверяет:

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

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

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

Чек-лист развёртывания gateway

  1. Установите явные белые списки — никогда не используйте GATEWAY_ALLOW_ALL_USERS=true в продакшне

  2. Используйте контейнерный бэкенд — установите terminal.backend: docker в config.yaml

  3. Ограничьте ресурсы — установите соответствующие лимиты CPU, памяти и диска

  4. Храните секреты безопасно — держите API-ключи в ~/.hermes/.env с соответствующими правами доступа к файлам

  5. Включите DM-сопряжение — используйте коды сопряжения вместо жёсткого кодирования ID пользователей, когда это возможно

  6. Просматривайте белый список команд — периодически проверяйте command_allowlist в config.yaml

  7. Установите MESSAGING_CWD — не позволяйте агенту работать из конфиденциальных каталогов

  8. Запускайте не от root — никогда не запускайте gateway от root

  9. Мониторьте логи — проверяйте ~/.hermes/logs/ на предмет попыток несанкционированного доступа

  10. Обновляйте регулярно — запускайте hermes update регулярно для получения исправлений безопасности

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

# Установите правильные права на файл .env
chmod 600 ~/.hermes/.env

# Храните отдельные ключи для разных сервисов
# Никогда не коммитьте файлы .env в систему контроля версий

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

Для максимальной безопасности запускайте gateway на отдельной машине или VM. Установите terminal.backend: ssh в config.yaml, затем укажите данные хоста через переменные окружения в ~/.hermes/.env:

# ~/.hermes/config.yaml
terminal:
  backend: ssh

# ~/.hermes/.env
TERMINAL_SSH_HOST=agent-worker.local
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_KEY=~/.ssh/hermes_agent_key

Данные SSH-подключения хранятся в .env (не в config.yaml), чтобы они не попадали в систему контроля версий и не передавались вместе с экспортом профилей. Это обеспечивает разделение между messaging-соединениями gateway и выполнением команд агента.