Учебное пособие 29: Глубокое погружение в безопасность
Tutorial 29: Security Deep Dive — easy-to-understand guide based on official docs
Учебное пособие 29: Глубокое погружение в безопасность
С возвращением, укротители агентов! Сегодня мы надеваем каски и проводим глубокое погружение в модель безопасности Hermes Agent. Если вы когда-нибудь задумывались, что происходит за кулисами, чтобы ваши сессии оставались в безопасности, — этот урок для вас.
Общая картина: Восемь уровней защиты
Hermes не полагается на единственный замок на двери. Вместо этого он использует подход эшелонированной защиты с восемью отдельными уровнями безопасности. Представьте это как замок: даже если кто-то преодолеет ров, его всё равно ждут стены, ворота и стража внутри.
Вот они:
- Авторизация пользователя — кто имеет право общаться с агентом
- Подтверждение опасных команд — проверка человеком разрушительных действий
- Безопасность записи файлов — денай-листы и песочницы для файловых операций
- Изоляция контейнеров — песочницы Docker/Singularity/Modal
- Фильтрация учётных данных MCP — защита секретов от дочерних процессов
- Сканирование контекстных файлов — обнаружение промпт-инъекций в файлах проекта
- Изоляция между сессиями — сессии не могут подглядывать за данными друг друга
- Очистка входных данных — блокировка шелл-инъекций через параметры рабочей директории
Каждый уровень важен, но сегодня мы сосредоточимся на том, с чем вы будете взаимодействовать чаще всего: подтверждение опасных команд.
Как работает подтверждение опасных команд
Прежде чем Hermes выполнит любую команду, он проверяет её по специально составленному списку опасных шаблонов. Если есть совпадение — решение остаётся за вами.
Вы управляете этим поведением через секцию approvals в ~/.hermes/config.yaml:
approvals:
mode: smart # smart | manual | off
timeout: 300 # секунды ожидания ответа пользователя
cron_mode: deny # deny | approve
single_query_mode: deny # deny | approve
mcp_reload_confirm: true # подтверждение перед перезагрузкой MCP-инструментов
destructive_slash_confirm: true # подтверждение перед /clear, /new и т.д.
Три режима подтверждения
Ключ mode даёт вам три варианта:
| Режим | Поведение |
|---|---|
| smart (по умолчанию) | Использует вспомогательную LLM для оценки риска. Низкорисковые команды (например, python -c "print('hello')") получают автоматическое одобрение. Действительно опасные — автоматический отказ. Сомнительные случаи передаются на ручное подтверждение. |
| manual | Всегда запрашивает ваше подтверждение для опасных команд. Без исключений. |
| off | Отключает все проверки подтверждения. Эквивалентно запуску с --yolo. |
⚠️ Предупреждение: Установка
approvals.mode: offотключает все запросы безопасности. Делайте это только в доверенных средах, таких как CI/CD-конвейеры или одноразовые контейнеры.
YOLO-режим: Большая красная кнопка
YOLO-режим обходит все запросы подтверждения опасных команд для текущей сессии. Активировать его можно тремя способами:
- Флаг CLI:
hermes --yoloилиhermes chat --yolo - Слэш-команда: Введите
/yoloво время сессии - Переменная окружения: Установите
HERMES_YOLO_MODE=1
Команда /yolo — это переключатель — каждое использование включает или выключает его:
> /yolo
⚡ YOLO-режим ВКЛ — все команды автоматически одобрены. Используйте с осторожностью.
> /yolo
⚠ YOLO-режим ВЫКЛ — опасные команды потребуют подтверждения.
Когда YOLO активен, Hermes делает так, чтобы вы не могли об этом забыть. Вы увидите красный баннер при старте сессии и фрагмент ⚠ YOLO в строке состояния, который обновляется в реальном времени при переключении.
⚠️ Опасность: YOLO-режим отключает все проверки безопасности опасных команд — кроме жёсткого блок-листа. Используйте его только тогда, когда полностью доверяете генерируемым командам (например, хорошо протестированным скриптам автоматизации в одноразовых средах).
Новое в этой версии: Умные ключи конфигурации
Два новых ключа конфигурации заслуживают особого внимания:
mcp_reload_confirm (по умолчанию: true) — Когда установлен в true, /reload-mcp запрашивает подтверждение перед пересборкой набора MCP-инструментов. Почему? Потому что пересборка аннулирует кэш промптов провайдера, что означает, что следующее сообщение заново отправит полные входные токены. Это расходы, которые вы, возможно, захотите одобрить заранее.
destructive_slash_confirm (по умолчанию: true) — Когда установлен в true, разрушительные команды сессии (/clear, /new, /reset, /undo) запрашивают подтверждение перед удалением состояния разговора. Вы получаете диалог с тремя вариантами: Одобрить один раз / Всегда одобрять / Отмена. В Telegram, Discord и Slack это реализовано через нативные кнопки да/нет. В остальных случаях — через текстовый ввод.
TUI также учитывает эту настройку для своих модальных окон /clear, /new и /reset. А если вы автоматизируете процессы, HERMES_TUI_NO_CONFIRM=1 полностью пропускает это модальное окно.
Сессии без головы: Cron и одиночные запросы
Что происходит, когда cron-задача или одноразовая сессия hermes chat -q сталкивается с опасной командой? Рядом нет человека, ожидающего ответа на запрос.
Здесь в игру вступают cron_mode и single_query_mode:
deny(по умолчанию) — Блокирует команду. Агент должен найти другой путь.approve— Автоматически одобряет всё в этом контексте.
Оба по умолчанию установлены в deny не просто так: лучше перестраховаться, когда за процессом никто не наблюдает.
Подводим итоги
Модель безопасности Hermes Agent направлена на то, чтобы дать вам контроль, не мешая при этом. Умный режим подтверждения автоматически обрабатывает рутинные вещи, а ручной режим даёт полный контроль, когда он нужен. А если вы находитесь в доверенной среде, YOLO-режим позволяет действовать быстро.
Просто помните: с большой силой приходит большая ответственность. Используйте YOLO с умом!
В следующий раз мы рассмотрим, как настроить систему подтверждения под ваш конкретный рабочий процесс. А пока — оставайтесь в безопасности!
📖 Официальная документация
Эта статья основана на официальной документации Hermes Agent :Официальные документы › user-guide/security