Безопасность AI-агента — это набор механизмов, которые контролируют, что агент может делать на вашем сервере, какие данные он видит и кому разрешено с ним взаимодействовать. Hermes Agent реализует восьмислойную модель защиты «defense-in-depth»: от проверки команд перед выполнением до изоляции контейнеров и фильтрации переменных окружения. В этой статье — подробный разбор каждого уровня безопасности, конкретные настройки и рекомендации для продакшена.
Почему безопасность AI-агента — это не просто «checkbox»
AI-агенты отличаются от обычных скриптов тем, что принимают решения автономно. Обычный бот выполняет заранее написанный код. AI-агент генерирует команды на лету, читает файлы, обращается к API, управляет сервером. Если агент скомпрометирован или допускает ошибку — последствия масштабнее, чем у простого скрипта.
По данным Gartner, более 60% крупных компаний уже используют автономных AI-агентов в продакшене (рост с 15% в 2023 году). При этом 80% организаций сообщали о подозрительном поведении AI-агентов, но только 42% инвестируют в безопасность пропорционально риску.
OWASP выпустил Top 10 для агентских приложений (декабрь 2025, версия 2026.1) — первый отраслевой стандарт, описывающий специфические риски автономных агентов: от перехвата целей (Agent Goal Hijack) до отравления памяти (Memory Poisoning).
Hermes Agent проектировался с учётом этих рисков. Рассмотрим, как устроена его защита.
Какие уровни защиты есть в Hermes Agent?
Модель безопасности Hermes включает восемь слоёв, каждый из которых работает независимо:
write_file / patchРазберём каждый уровень подробно.
Как Hermes одобряет опасные команды?
Перед выполнением любой команды Hermes проверяет её по списку опасных паттернов. Если совпадение найдено — требуется явное подтверждение пользователя.
Режимы одобрения
В файле ~/.hermes/config.yaml настраивается режим:
approvals:
mode: smart # smart | manual | off
timeout: 60 # секунды ожидания ответа
cron_mode: deny # deny | approve для cron-задач
| Режим | Поведение |
|---|---|
| **smart** (по умолчанию) | Вспомогательная LLM оценивает риск. Безопасные команды проходят автоматически, опасные — блокируются, сомнительные — запрашивают подтверждение |
| **manual** | Всегда запрашивать подтверждение |
| **off** | Отключить все проверки (эквивалент `—yolo`) |
Жёсткий блоклист (Hardline Blocklist)
Некоторые команды настолько разрушительны, что Hermes отказывается их выполнять при любых настройках — даже с --yolo, даже в cron с approve, даже при явном «разрешить всегда»:
| Паттерн | Почему заблокирован | |
|---|---|---|
| `rm -rf /` и варианты | Удаление корня файловой системы | |
| `:(){ : | :& };:` (fork bomb) | Зависание хоста до перезагрузки |
| `mkfs.*` на корневом устройстве | Форматирование рабочей системы | |
| `dd if=/dev/zero of=/dev/sd*` | Затирание физического диска | |
| Пайп удалённого URL в `sh` | Удалённое выполнение произвольного кода |
Этот блоклист — «пол» безопасности, который невозможно обойти. Если легитимный сценарий требует одну из этих команд — выполните её вне агента.
YOLO-режим
YOLO-режим отключает проверки опасных команд для текущей сессии. Активируется тремя способами:
hermes --yolo/yolo в чате (переключатель)HERMES_YOLO_MODE=1YOLO не обходит жёсткий блоклист. Визуальные индикаторы: красный баннер при старте сессии и плашка ⚠ YOLO в статус-баре.
Пользовательские правила запрета
Для ситуаций «YOLO с исключениями» можно добавить свои правила в config.yaml:
approvals:
deny:
- "git push --force*"
- "*curl*|*sh*"
- "dd if=* of=/dev/*"
Паттерны работают как fnmatch-глоб匹配, проверяются до --yolo и approvals.mode: off.
Какие команды запрашивают подтверждение
Полный список паттернов, которые триггерят approval prompt:
rm -r / rm --recursive — рекурсивное удалениеchmod 777 / chmod --recursive с небезопасными правамиmkfs, dd if= — форматирование/затирание дисковDROP TABLE/DATABASE, DELETE FROM без WHERE — SQL-деструкцияsystemctl stop/restart/disable — остановка сервисовbash -c, sh -c, python -e — выполнение скриптев через флаг -c/-ecurl ... | sh, bash — пайп удалённого кода в шелл/etc/, ~/.ssh/, ~/.hermes/.env — перезапись системных конфиговpkill / killall для hermes/gateway — предотвращение самоубийства процессаВажно: в контейнерных бэкендах (Docker, Singularity, Modal) проверки опасных команд пропускаются — сам контейнер является границей безопасности.
Как Hermes защищает файлы от перезаписи?
Инструменты write_file и patch проверяют целевой путь по denylist до записи на диск. Блокировка происходит мгновенно, без диалога подтверждения.
Всегда заблокированные пути
| Категория | Примеры |
|---|---|
| Хранилища учётных данных ОС | `~/.ssh/`, `~/.aws/`, `~/.kube/`, `/etc/sudoers` |
| Учётные данные Hermes | `auth.json`, `.env`, `mcp-tokens/`, `pairing/` |
| Секретные файлы проектов | `.env`, `.env.local`, `.env.production` — в любой директории |
Даже если HERMES_WRITE_SAFE_ROOT указывает на $HOME, запись в ~/.ssh/id_rsa всё равно заблокирована.
Песочница записи (HERMES_WRITE_SAFE_ROOT)
При установке этой переменной write_file и patch могут работать только внутри указанных директорий:
export HERMES_WRITE_SAFE_ROOT=/path/to/project:/home/you/.hermes
В официальном Docker-образе HERMES_WRITE_SAFE_ROOT установлен в /opt/data по умолчанию.
Ограничение: write-гарды применяются только к write_file и patch. Инструмент terminal выполняется от того же пользователя ОС и может перезаписать заблокированные пути через shell-команды. Это защита от случайных ошибок, а не песочница против враждебного агента.
Как работает изоляция контейнеров?
Контейнерный бэкенд — самый надёжный способ ограничить возможности агента. Hermes поддерживает несколько вариантов:
Docker-бэкенд
Агент выполняет каждую команду внутри персистентного Docker-контейнера:
# ~/.hermes/config.yaml
terminal:
backend: docker
docker_image: hermes-sandbox:latest
Что даёт изоляция:
Modal и Singularity
Дополнительные бэкенды для облачной изоляции. Modal запускает sandbox в облаке, Singularity — HPC-ориентированная альтернатива Docker.
SSH-бэкенд для максимальной изоляции
Для продакшена рекомендуется запускать gateway и агент на разных машинах:
# ~/.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), поэтому не попадают в экспорт профилей и систему контроля версий.
Как Hermes изолирует учётные данные MCP?
MCP (Model Context Protocol) — это протокол для подключения внешних инструментов к агенту. MCP-серверы запускаются как подпроцессы, и важно, чтобы они не получили доступ ко всем переменным окружения хоста.
Фильтрация переменных окружения
MCP-подпроцессы получают только безопасные переменные:
PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR
Плюс любые XDG_* переменные. Все остальные (API-ключи, токены, пароли) — удаляются.
Переменные, которые нужны конкретному MCP-серверу, передаются явно через конфиг:
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_..." # Только эта переменная пройдёт
Редактирование учётных данных в ошибках
Сообщения об ошибках от MCP-инструментов санитизируются перед возвратом в LLM. Паттерны ghp_..., sk-..., Bearer-токены, параметры token=, key=, API_KEY=, password=, secret= заменяются на [REDACTED].
Как Hermes защищает от prompt injection в файлах проекта?
Контекстные файлы (AGENTS.md, .cursorrules, SOUL.md) сканируются на наличие prompt injection перед включением в системный промпт. Сканер ищет:
.env, credentials, .netrc)curlЗаблокированный файл показывает предупреждение:
[BLOCKED: AGENTS.md contained potential prompt injection (prompt_injection). Content not loaded.]
Как защитить веб-доступ агента?
SSRF-защита
Все URL-инструменты (web search, web extract, browser, vision) валидируют URL перед запросом для предотвращения SSRF-атак. Заблокированы:
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16127.0.0.0/8, ::1169.254.0.0/16 (включая cloud metadata 169.254.169.254)100.64.0.0/10metadata.google.internal, metadata.googЦепочки редиректов перепроверяются на каждом шаге. DNS-ошибки обрабатываются как блокировка (fail-closed).
Для легитимного доступа к приватным URL (например, локальный Ollama) есть опция:
security:
allow_private_urls: true # по умолчанию: false
Блоклист сайтов
Можно ограничить, какие сайты агент может посещать:
security:
website_blocklist:
enabled: true
domains:
- "*.internal.company.com"
- "admin.example.com"
Блоклист работает для web_search, web_extract, browser_navigate и всех URL-инструментов.
Что такое Tirith и как он защищает команды?
Hermes интегрирует tirith — инструмент для контентного сканирования команд перед выполнением. Tirith обнаруживает угрозы, которые простой pattern matching пропускает:
curl | bash, wget | sh)Tirith автоматически устанавливается из GitHub releases с проверкой SHA-256. Настройка:
security:
tirith_enabled: true # включить/выключить (по умолчанию: true)
tirith_timeout: 5 # таймаут в секундах
tirith_fail_open: true # разрешить выполнение при недоступности tirith
В высокозащищённых окружениях рекомендуется tirith_fail_open: false — команды блокируются, если tirith недоступен.
Как Hermes защищает от атак на цепочку поставок?
Сканирование уязвимых пакетов
Hermes включает встроенный сканер advisory, который проверяет Python-пакеты в активном venv на совпадение с каталогом известных скомпрометированных версий (включая supply-chain worms, такие как отравление mistralai 2.4.6 в мае 2026).
hermes doctor — полный список advisory с инструкциями по исправлениюhermes doctor --ack — подтвердить прочтение и скрыть advisoryLazy install с защитой
Опциональные зависимости устанавливаются «лениво» при первом использовании, а не все сразу. Каждая установка проходит через строгий контроль:
| Гарантия | Что это значит |
|---|---|
| Только в venv | Установка идёт в активное виртуальное окружение, не в системный Python |
| PyPI по имени | Запрещены `--index-url`, `git+https://`, `file:` пути |
| Allowlist | Только пакеты из внутреннего каталога `LAZY_DEPS` |
| Opt-out | `security.allow_lazy_installs: false` отключает установку в рантайме |
Как настроить авторизацию пользователей в gateway?
Когда Hermes работает как мессенджер-бот (Telegram, Discord, Slack), он контролирует, кто может с ним взаимодействовать.
Проверка авторизации (по порядку)
DISCORD_ALLOW_ALL_USERS=true)TELEGRAM_ALLOWED_USERS=12345,67890)GATEWAY_ALLOWED_USERS=12345,67890)GATEWAY_ALLOW_ALL_USERS=true)Рекомендация для продакшена
Никогда не используйте GATEWAY_ALLOW_ALL_USERS=true в продакшене. Используйте explicit allowlists или DM pairing codes.
Как защитить API-ключи и секреты?
# Правильные права на .env файл
chmod 600 ~/.hermes/.env
# Разные ключи для разных сервисов
# Никогда не коммитить .env в git
Хранилище .env с настройками:
HERMESWIKI_URL, HERMESWIKI_USER, HERMESWIKI_PASSWORD — для публикацииTELEGRAM_BOT_TOKEN — для TelegramOPENROUTER_API_KEY — для LLM-провайдеровВсе эти переменные автоматически фильтруются при передаче в MCP-процессы и контейнеры.
Чеклист безопасности для продакшена
GATEWAY_ALLOW_ALL_USERS=trueterminal.backend: docker в config.yamlchmod 600 на .env, не коммитить в gitcommand_allowlist в config.yamlterminal.cwd, не давать агенту работать из чувствительных директорий~/.hermes/logs/ на попытки несанкционированного доступаhermes update для получения патчей безопасностиFAQ
Можно ли полностью отключить все проверки безопасности в Hermes?
Да, через approvals.mode: off или флаг --yolo. Но жёсткий блоклист (удаление корня, fork bombs, форматирование дисков) всё равно остаётся активным — его невозможно обойти никакой настройкой. Это осознанное решение: некоторые команды слишком разрушительны, чтобы разрешать их автоматически.
Что произойдёт, если агент попытается записать в защищённый файл?
write_file и patch мгновенно вернут ошибку без диалога подтверждения. Агент получит сообщение вида Write denied: '…' is a protected system/credential file. и должен найти другой путь. Однако terminal может обойти эту проверку через shell-команды — это защита от случайных ошибок, а не абсолютная песочница.
Как Hermes защищает данные между разными профилями/агентами?
Каждый профиль работает в изолированном пространстве ~/.hermes/profiles/. Hermes применяет cross-profile soft guard — попытки записи в другой профиль по умолчанию блокируются с предупреждением. Это предотвращает случайную модификацию данных другого агента.
Безопасно ли давать Hermes доступ к production-серверу?
Для максимальной безопасности используйте SSH-бэкенд с отдельной машиной для агента, контейнерную изоляцию, explicit allowlists и approvals.mode: manual. Не давайте агенту write-доступ к production-базам данных без human-in-the-loop. AI-агенты должны рассматриваться как непроверенные третьи стороны с контролем уровня «внешний подрядчик».
Как Hermes защищает от supply-chain атак?
Встроенный сканер advisory проверяет Python-пакеты на известные скомпрометированные версии. Lazy install ограничивает установку только пакетами из внутреннего каталога — произвольные пакеты установить через агента нельзя. Tirith сканирует команды на наличие вредоносных паттернов перед выполнением.