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

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

Обзор¶

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

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

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

Режимы утверждения¶

Система утверждения поддерживает три режима, настраиваемых через approvals.mode в ~/.hermes/config.yaml: [code] approvals:
mode: manual # manual | smart | off
timeout: 60 # секунд ожидания ответа пользователя (по умолчанию: 60)

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

YOLO-режим¶

YOLO-режим обходит все запросы утверждения опасных команд для текущей сессии. Его можно активировать тремя способами: 1. Флаг CLI : Запустите сессию с hermes --yolo или hermes chat --yolo 2. Слэш-команда : Введите /yolo во время сессии, чтобы включить/отключить режим 3. Переменная окружения : Установите HERMES_YOLO_MODE=1

Команда /yolo является переключателем — каждый вызов меняет режим на противоположный: [code] > /yolo
⚡ YOLO mode ON — все команды утверждаются автоматически. Используйте с осторожностью.

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

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

Жёсткий блок-список (всегда активный нижний порог)¶

Некоторые команды настолько катастрофичны — необратимое уничтожение файловой системы, fork-бомбы, прямая запись на блочные устройства — что Hermes отказывается их выполнять независимо от: * Включённого --yolo / /yolo * approvals.mode: off * Заданий cron, работающих в безголовом режиме approve * Явного нажатия пользователем «allow always»

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

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

Когда появляется запрос опасной команды, у пользователя есть настраиваемое время для ответа. Если ответ не получен в течение тайм-аута, команда отклоняется по умолчанию (закрытый отказ, fail-closed). Настройте тайм-аут в ~/.hermes/config.yaml: [code] approvals:
timeout: 60 # секунд (по умолчанию: 60)

[/code]

Что вызывает утверждение¶

Следующие шаблоны вызывают запросы на утверждение (определены в 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-бомбы| Fork-бомбы
bash -c / sh -c / zsh -c / ksh -c| Выполнение команд оболочки через флаг -c (включая комбинированные флаги типа -lc)
python -e / perl -e / ruby -e / node -c| Выполнение скриптов через флаг -e/-c
curl ... | sh / wget ... | sh| Перенаправление (pipe) удалённого содержимого в оболочку
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| Предотвращение запуска шлюза вне менеджера служб
info Обход контейнера : При работе в бэкендах docker, singularity, modal, daytona или vercel_sandbox проверки опасных команд пропускаются, поскольку сам контейнер является границей безопасности. Деструктивные команды внутри контейнера не могут навредить хосту.

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

В интерактивном CLI опасные команды показывают встроенный запрос утверждения: [code] ⚠️ DANGEROUS COMMAND: recursive delete
rm -rf /tmp/old-project

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

      Choice [o/s/a/D]:

[/code] Четыре варианта: * once — разрешить однократное выполнение * session — разрешить этот шаблон на оставшуюся часть сессии * always — добавить в постоянный белый список (сохраняется в config.yaml) * deny (по умолчанию) — заблокировать команду

Процесс утверждения (Шлюз/Мессенджеры)¶

На платформах обмена сообщениями агент отправляет детали опасной команды в чат и ждёт ответа пользователя: * Ответьте yes, y, approve, ok или go для утверждения * Ответьте no, n, deny или cancel для отклонения

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

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

Команды, утверждённые через «always», сохраняются в ~/.hermes/config.yaml: [code] # Постоянно разрешённые шаблоны опасных команд
command_allowlist:
- rm
- systemctl

[/code] Эти шаблоны загружаются при запуске и молча утверждаются во всех будущих сессиях. tip Используйте 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. По умолчанию: запретить

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

Установите ID разрешённых пользователей в виде значений, разделённых запятыми, в ~/.hermes/.env: [code] # Белые списки для конкретных платформ
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

[/code] warning Если не настроены белые списки и не установлен GATEWAY_ALLOW_ALL_USERS, все пользователи отклоняются. Шлюз записывает предупреждение при запуске: [code] 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).

[/code]

Система DM-привязки¶

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

Управляйте обработкой неавторизованных личных сообщений в ~/.hermes/config.yaml: [code] unauthorized_dm_behavior: pair

whatsapp:  
  unauthorized_dm_behavior: ignore

[/code] * pair — значение по умолчанию. Неавторизованные DM получают ответ с кодом привязки. * ignore — молча игнорирует неавторизованные DM. * Секции платформ переопределяют глобальное значение по умолчанию, так что вы можете оставить привязку в Telegram, сохраняя WhatsApp в тишине.

Функции безопасности (на основе рекомендаций 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 для привязки: [code] # Список ожидающих и утверждённых пользователей
hermes pairing list

# Утвердить код привязки  
hermes pairing approve telegram ABC12DEF

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

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

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

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

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

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

Каждый контейнер запускается с этими флагами (определены в tools/environments/docker.py): [code] _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", # /var/tmp без exec
"--tmpfs", "/run:rw,noexec,nosuid,size=64m", # /run без exec
]

[/code]

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

Ресурсы контейнера настраиваются в ~/.hermes/config.yaml: [code] 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 # Сохранять файловую систему между сессиями

[/code]

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

Постоянный режим (container_persistent: true): Подмонтирует /workspace и /root из ~/.hermes/sandboxes/docker/<task_id>/
Эфемерный режим (container_persistent: false): Использует tmpfs для рабочей области — всё теряется при очистке

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

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

Бэкенд	Изоляция	Проверка опасных команд	Лучше всего для
local	Нет — выполняется на хосте	✅ Да	Разработка, доверенные пользователи
ssh	Удалённая машина	✅ Да	Работа на отдельном сервере
docker	Контейнер	❌ Пропускается (контейнер — граница)	Продакшн-шлюз
singularity	Контейнер	❌ Пропускается	HPC-среды
modal	Облачная песочница	❌ Пропускается	Масштабируемая облачная изоляция
daytona	Облачная песочница	❌ Пропускается	Постоянные облачные рабочие пространства
vercel_sandbox	Облачная микроВМ	❌ Пропускается	Облачное выполнение с сохранением снимков состояния
## Передача переменных окружения (Passthrough)
Как `execute_code`, так и `terminal` удаляют чувствительные переменные окружения из дочерних процессов для предотвращения извлечения учётных данных кодом, сгенерированным LLM. Однако навыки (skills), объявляющие `required_environment_variables`, легитимно нуждаются в доступе к этим переменным.
### Как это работает
Два механизма позволяют конкретным переменным проходить через фильтры песочницы:
1. Передача в рамках навыка (автоматическая)
Когда навык загружается (через `skill_view` или команду `/skill`) и объявляет `required_environment_variables`, любые из этих переменных, которые фактически установлены в окружении, автоматически регистрируются для передачи. Отсутствующие переменные (всё ещё в состоянии setup-needed) не регистрируются.
[code]
# В frontmatter SKILL.md навыка
required_environment_variables:
- name: TENOR_API_KEY
prompt: Tenor API key
help: Получить ключ на https://developers.google.com/tenor

[/code] После загрузки этого навыка TENOR_API_KEY передаётся в execute_code, terminal (локальный) и удалённые бэкенды (Docker, Modal) — ручная настройка не требуется. Docker и Modal До версии v0.5.1 forward_env Docker'а был отдельной системой от передачи навыков. Теперь они объединены — переменные окружения, объявленные навыком, автоматически передаются в контейнеры Docker и песочницы Modal без необходимости вручную добавлять их в docker_forward_env. 2. Передача через конфигурацию (ручная) Для переменных окружения, не объявленных ни одним навыком, добавьте их в terminal.env_passthrough в config.yaml: [code] terminal:
env_passthrough:
- MY_CUSTOM_KEY
- ANOTHER_TOKEN

[/code]

Передача файлов с учётными данными (OAuth-токены и т.д.)¶

Некоторым навыкам требуются файлы (не только переменные окружения) в песочнице — например, Google Workspace хранит OAuth-токены как google_token.json в HERMES_HOME активного профиля. Навыки объявляют это в frontmatter: [code] required_credential_files:
- path: google_token.json
description: Google OAuth2 токен (создаётся скриптом настройки)
- path: google_client_secret.json
description: Учётные данные клиента Google OAuth2

[/code] При загрузке Hermes проверяет, существуют ли эти файлы в HERMES_HOME активного профиля, и регистрирует их для монтирования: * Docker : Монтирование только для чтения (-v host:container:ro) * Modal : Монтируются при создании песочницы + синхронизируются перед каждой командой (обрабатывает настройку OAuth в середине сессии) * Локальный : Действия не требуются (файлы уже доступны)

Вы также можете указать файлы учётных данных вручную в config.yaml: [code] terminal:
credential_files:
- google_token.json
- my_custom_oauth_token.json

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

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

Песочница	Фильтр по умолчанию	Переопределение передачи (Passthrough)
execute_code	Блокирует переменные, содержащие `KEY`, `TOKEN`, `SECRET`, `PASSWORD`, `CREDENTIAL`, `PASSWD`, `AUTH` в имени; пропускает только переменные с безопасным префиксом	✅ Передаваемые переменные обходят обе проверки
terminal (локальный)	Блокирует явные инфраструктурные переменные Hermes (ключи провайдеров, токены шлюза, ключи API инструментов)	✅ Передаваемые переменные обходят блок-список
terminal (Docker)	Нет переменных хоста по умолчанию	✅ Передаваемые переменные + `docker_forward_env` передаются через `-e`
terminal (Modal)	Нет переменных/файлов хоста по умолчанию	✅ Файлы учётных данных монтируются; передача переменных через синхронизацию
MCP	Блокирует всё, кроме безопасных системных переменных + явно настроенных `env`	❌ Не подвержено влиянию passthrough (используйте конфигурацию `env` MCP)
### Соображения безопасности
* Передача (passthrough) затрагивает только те переменные, которые вы или ваши навыки явно объявляете — стандартная позиция безопасности остаётся неизменной для произвольного кода, сгенерированного LLM
* Файлы учётных данных монтируются только для чтения в контейнеры Docker
* Skills Guard проверяет содержимое навыков на подозрительные шаблоны доступа к окружению перед установкой
* Отсутствующие/неустановленные переменные никогда не регистрируются (нельзя раскрыть то, чего не существует)
* Инфраструктурные секреты Hermes (ключи API провайдеров, токены шлюза) никогда не должны добавляться в `env_passthrough` — у них есть выделенные механизмы

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

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

Безопасные переменные окружения¶

Только эти переменные передаются от хоста в подпроцессы MCP stdio: [code] PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR

[/code] Плюс любые переменные XDG_*. Все остальные переменные окружения (ключи API, токены, секреты) удаляются. Переменные, явно определённые в конфигурации env MCP-сервера, передаются: [code] mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..." # Передаётся только это

[/code]

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

Сообщения об ошибках от MCP-инструментов санитизируются перед возвратом в LLM. Следующие шаблоны заменяются на [REDACTED]: * GitHub PATs (ghp_...) * Ключи в стиле OpenAI (sk-...) * Bearer-токены * Параметры token=, key=, API_KEY=, password=, secret=

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

Вы можете ограничить, к каким веб-сайтам агент может обращаться через свои веб-инструменты и инструменты браузера. Это полезно для предотвращения доступа агента к внутренним сервисам, панелям администратора и другим чувствительным URL. [code] # В ~/.hermes/config.yaml
security:
website_blocklist:
enabled: true
domains:
- "*.internal.company.com"
- "admin.example.com"
shared_files:
- "/etc/hermes/blocked-sites.txt"

[/code] Когда запрашивается заблокированный URL, инструмент возвращает ошибку с объяснением, что домен заблокирован политикой. Блок-список применяется во всех инструментах: web_search, web_extract, browser_navigate и любых инструментах, работающих с URL. См. Блок-список веб-сайтов в руководстве по конфигурации для полной информации.

Защита от SSRF¶

Все инструменты, работающие с URL (веб-поиск, извлечение веб-данных, vision, браузер), проверяют URL перед загрузкой для предотвращения атак подделки запросов на стороне сервера (SSRF). Заблокированные адреса включают: * Частные сети (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 * Loopback : 127.0.0.0/8, ::1 * Link-local : 169.254.0.0/16 (включает метаданные облака по адресу 169.254.169.254) * CGNAT / общее адресное пространство (RFC 6598): 100.64.0.0/10 (Tailscale, WireGuard VPN) * Имена хостов метаданных облака : metadata.google.internal, metadata.goog * Зарезервированные, многоадресные и неопределённые адреса

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

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

В некоторых конфигурациях легитимно требуется доступ к частным/внутренним URL — домашние сети, разрешающие home.arpa в пространство RFC 1918, локальные endpoint'ы Ollama/llama.cpp, внутренние вики, отладка метаданных облака и т.п. Для таких случаев есть глобальный отказ: [code] security:
allow_private_urls: true # по умолчанию: false

[/code] Когда включено, веб-инструменты, браузер, загрузки vision URL и загрузки медиа шлюза больше не отклоняют RFC 1918 / loopback / link-local / CGNAT / облачные метаданные. Это намеренная граница доверия — включайте только на машинах, где допустим риск того, что агент будет выполнять произвольные URL с внедрённым промптом против локальной сети. Публичные шлюзы должны оставлять эту опцию выключенной. Защита от подстрок хоста (которая блокирует трюки с омоглифическими доменами Unicode, даже когда базовый IP является публичным) остаётся активной независимо от этой настройки.

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

Hermes интегрирует tirith для сканирования команд на уровне содержимого перед выполнением. Tirith обнаруживает угрозы, которые одно только сопоставление шаблонов пропускает: * Спуфинг URL с омоглифами (атаки с интернационализированными доменами) * Шаблоны перенаправления в интерпретатор (curl | bash, wget | sh) * Атаки внедрения в терминал

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

[/code] Когда tirith_fail_open имеет значение true (по умолчанию), команды выполняются, если tirith не установлен или истёк тайм-аут. Установите false в средах с высокими требованиями безопасности, чтобы блокировать команды, когда tirith недоступен. Вердикт Tirith интегрируется с процессом утверждения: безопасные команды проходят, в то время как как подозрительные, так и заблокированные команды вызывают утверждение пользователем с полными результатами tirith (серьёзность, заголовок, описание, более безопасные альтернативы). Пользователь может утвердить или отклонить — выбор по умолчанию — отклонить, чтобы обеспечить безопасность в сценариях без присмотра.

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

Контекстные файлы (AGENTS.md, .cursorrules, SOUL.md) сканируются на предмет внедрения промптов перед включением в системный промпт. Сканер проверяет: * Инструкции игнорировать/отменять предыдущие инструкции * Скрытые HTML-комментарии с подозрительными ключевыми словами * Попытки прочитать секреты (.env, credentials, .netrc) * Извлечение учётных данных через curl * Невидимые символы Unicode (нулевой ширины пробелы, двунаправленные переопределения)

Заблокированные файлы показывают предупреждение: [code] [BLOCKED: AGENTS.md contained potential prompt injection (prompt_injection). Content not loaded.]

[/code]

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

Обзор¶

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

Режимы утверждения¶

YOLO-режим¶

Жёсткий блок-список (всегда активный нижний порог)¶

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

Что вызывает утверждение¶

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

Процесс утверждения (Шлюз/Мессенджеры)¶

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

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

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

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

Система DM-привязки¶

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

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

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

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

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

Передача файлов с учётными данными (OAuth-токены и т.д.)¶

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

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

Безопасные переменные окружения¶

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

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

Защита от SSRF¶

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

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

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

Рекомендации по продакшн-развёртыванию¶

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

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

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

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

Обзор​¶

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

Режимы утверждения​¶

YOLO-режим​¶

Жёсткий блок-список (всегда активный нижний порог)​¶

Тайм-аут утверждения​¶

Что вызывает утверждение​¶

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

Процесс утверждения (Шлюз/Мессенджеры)​¶

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

Авторизация пользователей (Шлюз)​¶

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

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

Система DM-привязки​¶

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

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

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

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

Сравнение безопасности терминальных бэкендов​¶

Передача файлов с учётными данными (OAuth-токены и т.д.)​¶

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

Обработка учётных данных MCP​¶

Безопасные переменные окружения​¶

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

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

Защита от SSRF​¶

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

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

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

Рекомендации по продакшн-развёртыванию​¶

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

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

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

Обзор¶

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

Режимы утверждения¶

YOLO-режим¶

Жёсткий блок-список (всегда активный нижний порог)¶

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

Что вызывает утверждение¶

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

Процесс утверждения (Шлюз/Мессенджеры)¶

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

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

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

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

Система DM-привязки¶

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

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

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

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

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

Передача файлов с учётными данными (OAuth-токены и т.д.)¶

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

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

Безопасные переменные окружения¶

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

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

Защита от SSRF¶

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

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

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

Рекомендации по продакшн-развёртыванию¶

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

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

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