Hermes Agent Docker позволяет запускать команды терминального инструмента в отдельном контейнере, если выбрать Docker backend и проверить его доступ к файлам и сети. Сам Hermes Agent при такой настройке может оставаться на хосте: запуск всего агента в Docker представляет другой вариант развёртывания. Контур готов к работе только после испытания разрешённых и запрещённых действий на пробных данных.
Два режима Docker
Официальный quickstart показывает `hermes config set terminal.backend docker` для изоляции терминала. В этом режиме процесс агента может оставаться на хосте; официальный Docker guide отдельно описывает запуск самого Hermes Agent в контейнере.
Начните с вопроса, какой процесс нужно изолировать. Если риск связан с командами, которые агент запускает для чтения тестовых файлов и сборки результата, предмет статьи — Docker backend терминала. Если задача состоит в переносе самого gateway, конфигурации и пользовательских данных в контейнер, изучайте официальную инструкцию по контейнерному запуску Hermes Agent. Режимы решают разные задачи и требуют отдельных решений о секретах, томах и сетевом доступе.
| Вопрос | Docker backend терминала | Агент внутри Docker |
|---|---|---|
| Где работает Hermes Agent | На хосте по выбранной схеме | В контейнере агента |
| Где выполняются команды инструмента | В отдельном контейнере терминала | Определяет backend внутри развёрнутого агента |
| Что проверять первым | Монтирования, сеть, проброс переменных | Тома данных, порты, права процесса и backend |
| Чей конфиг нужен | Настройки terminal в профиле агента | Конфиг агента и параметры контейнерного запуска |
Для ограниченного испытания подготовьте отдельный каталог с обезличенными входными файлами и пустой каталог результата. Запишите точный путь каждого каталога, владельца данных и разрешённые операции: чтение, создание результата, исправление. Рабочие репозитории, ключи, пользовательские профили и Docker socket исключите из набора входов. В теме локального агента на собственном сервере разобран более широкий вопрос размещения всего контура; здесь важен путь одной команды внутри инструментального контейнера.
Границы файлов
После выбора backend перечислите фактические монтирования, которые появятся у контейнера. Параметр `terminal.docker_mount_cwd_to_workspace` управляет монтированием каталога запуска в `/workspace`; в официальной конфигурации Hermes Agent по умолчанию он выключен. Дополнительные тома задают отдельным списком. Внутренний рабочий каталог и сохраняемое состояние также зависят от профиля и режима постоянства контейнера. Поэтому итоговую границу доступа устанавливают по созданному контейнеру с учётом всей конфигурации.
- Для входных материалов определите отдельный путь и режим только для чтения. Docker поддерживает суффикс `:ro` для bind mount; наличие режима подтвердите в метаданных контейнера.
- Для выхода выделите отдельный путь записи. Сверьте владельца созданного файла с пользователем на хосте, которому предстоит принять результат.
- Проверьте, какие папки backend добавляет автоматически: рабочее пространство, домашний каталог контейнера и каталог постоянного состояния.
- Исключите монтирование корня проекта, домашней папки пользователя, каталогов секретов и сокета Docker без отдельного обоснования и проверки.
Официальная документация Docker предупреждает: bind mount обычно даёт контейнеру запись в файлы хоста, а режим `ro` ограничивает её. Явно смонтированный каталог остаётся доступным контейнеру в пределах назначенных прав. На приёмке запросите у агента чтение разрешённого тестового файла, затем чтение контрольного пути вне разрешённого набора. Отдельно испытайте запись в каталог результата и попытку записи во входной каталог. Для каждой операции сохраните видимый ответ инструмента и состояние файлов до и после.
Сеть и секреты
Сетевой доступ у терминального контейнера — самостоятельное решение. В опубликованных настройках Hermes Agent параметр `terminal.docker_network` включён по умолчанию; значение `false` связывается с режимом Docker `--network=none`. Документация Docker указывает, что в этом режиме внутри контейнера остаётся интерфейс loopback. Такая настройка пригодна для пробы локальных файлов, но клиентские сетевые операции потребуют отдельного маршрута. После изменения настройки проверяйте фактическую сеть контейнера и результат тестового запроса.
- Составьте матрицу разрешённых направлений: локальные файлы, внутренние сервисы и внешние адреса. Для каждой строки укажите необходимость доступа и владельца решения.
- Начните с теста без сетевой связи, если инструменту достаточно локального корпуса. Проверьте отсутствие успешного соединения с контрольным внешним адресом.
- Если сеть нужна, задайте разрешённый путь по корпоративному регламенту и испытайте нужный сервис отдельно от произвольного внешнего адреса.
- Оставьте список пробрасываемых переменных пустым для первичной проверки. Каждую добавляемую переменную согласуйте по назначению и способу хранения.
- Сверьте видимые контейнеру переменные по перечню имён, без вывода значений ключей в журнал статьи или тестовый отчёт.
Официальная справка Hermes Agent описывает `docker_forward_env` как явный список переменных для передачи в терминальные сессии. Она также предупреждает о переменных, объявленных навыками как необходимые: их передача требует отдельной проверки перед включением навыка. Секрет, доступный команде внутри контейнера, может попасть в её вывод или исходящий запрос. Сервер приложения проверяет полномочия до выдачи инструменту рабочей операции; настройка контейнера служит отдельной границей. Общие правила допусков изложены в материале о правах и секретах ИИ-агентов.
Нужна карта доступов для вашего терминального сценария?
Испытания границ
Проверку проводите в отдельной среде с безвредными файлами и адресами, которыми управляет ваша команда. Сначала сохраните снимок конфигурации без значений секретов: выбранный backend, образ, монтирования, сетевую политику, режим постоянства и набор включённых инструментов. Затем запустите простой запрос к терминальному инструменту, который читает разрешённый файл и создаёт файл в выделенном выходном каталоге. Команда проверки должна знать ожидаемый результат заранее.
| Проба | Ожидаемое наблюдение | Что фиксировать |
|---|---|---|
| Чтение входа | Разрешённый тестовый файл открыт | Путь, пользователь, ответ инструмента |
| Чтение вне набора | Содержимое контрольного файла недоступно | Отказ либо отсутствие пути |
| Запись входа | Исходный файл сохранил содержание | Хеш либо сравнение копии |
| Запись выхода | Новый файл виден принимающему сотруднику | Владелец, место, содержание |
| Сетевой запрос | Поведение соответствует матрице доступа | Адрес, сетевой режим, ответ |
Проверьте также повторный запрос в той же сессии: официальная документация описывает постоянный терминальный контейнер в течение процесса Hermes Agent, поэтому созданные файлы и изменения окружения могут сохраняться между вызовами. При новой сессии поведение зависит от настройки постоянства. Если результат второй пробы отличается, разберите источник состояния до допуска в рабочий контур. Для проверки набора тестов пригоден подход к сценариям и откату агента.
Сбой образа, ошибка монтирования или отказ сети заносятся в журнал как отдельные причины. Вариант «временно выполнить ту же команду на хосте» меняет границу доступа и требует нового решения ответственного сотрудника. Диагностический отчёт и журнал содержат только обезличенные наблюдения и имена параметров. Значения ключей и содержимое личных файлов исключают из отчёта и журнала.
Приёмка режима
Для приёмки назначьте владельца конфигурации, владельца данных и сотрудника, который утверждает результат. Они сверяют заявленную матрицу доступа с фактическими монтированиями и сетью, а протокол испытаний — с файлами после каждой пробы. Разрешённая команда должна завершаться ожидаемой записью, запрещённая — оставлять защищённый путь без изменений. Спорный ответ агента сверяет человек по журналу терминала и первичным файлам; модель может составить сводку, но решение принимает ответственный сотрудник.
- Подтвердите выполнение теста в выбранном Docker backend по типу окружения и журналу вызова. Зафиксируйте отображаемый тип backend и идентификатор испытательной среды.
- Сопоставьте фактические монтирования с реестром входов и выходов. Любой лишний путь отправьте на разбор до повторной приёмки.
- Сверьте сетевой режим с матрицей адресов и результаты контрольных соединений. Отдельно просмотрите имена проброшенных переменных.
- Проведите запрос с разрешённой ролью и с ролью без допуска к рабочей операции. Сверьте отказ сервера и отсутствие побочного действия.
- Подпишите протокол с открытыми исключениями, владельцами исправлений и решением о допуске сценария. Храните ссылку на версию настройки и испытанные файлы.
Эта приёмка относится к терминальному инструменту. Для запуска всего Hermes Agent внутри Docker отдельно проверяют том данных агента, доступность портов, права процесса и хранение конфигурации по официальному Docker guide. Если задача касается рабочего внедрения с регламентом доступа, обсудите внедрение ИИ в процесс компании: предметом оценки станут каталог данных, интеграции, роли и приёмочные испытания, без универсального обещания безопасности.
Режим принят, когда команда воспроизводит разрешённые действия, видит отказ на контрольных путях и адресах, знает владельца каждого исключения и может сверить журнал с фактическим состоянием файлов.