Пароли и логины

Скажите «войди в GitHub» — и агент войдёт за вас. Когда он впервые упирается в страницу входа, для которой нет сохранённого логина, он тут же спрашивает вас через скрытый ввод. Дальше всё работает само. Пароли зашифрованы на этой машине и подставляются прямо в страницу; модель их никогда не видит.

Настраивать ничего не нужно.

Как это выглядит

CLI / TUI

🔐 Save login for github.com
   The agent reached a sign-in page with no saved login for this site.
   Type the email / username you sign in with (shown), then Enter.
   ...
   Now the password (hidden). It is encrypted on this machine, bound to
   https://github.com, and filled into the page without the model ever seeing it.

Десктоп — карточка «Save your github.com login?» с полем идентификатора и скрытым полем пароля. Save & sign in сохраняет логин и продолжает; Don’t save говорит агенту больше не спрашивать в этом ходе.

С этого момента агент видит список ваших сохранённых логинов, сам вводит идентификатор, а пароль заполняет через Hermes. Результат инструмента, который он получает, — {filled_fields: 1, origin: "https://github.com"}; пароль к тому же регистрируется в редакторе секретов, чтобы последующее чтение страницы не могло вернуть его обратно.

Коды двухфакторной аутентификации

Сайты, которые после пароля просят код, обрабатываются так же:

Ключ аутентификатора сохранён вместе с логином («ключ настройки» или ссылка otpauth://, которую сайт показывает при включении 2FA; записи 1Password и Bitwarden с TOTP-секретом тоже считаются): Hermes генерирует текущий код и вводит его. Никого ни о чём не спрашивают. Добавьте ключ в Settings → Passwords & Logins → Add или через hermes vault add; у записи появится значок 2FA auto.
Код приходит на телефон или почту: в вашем интерфейсе появляется небольшой запрос («Verification code for github.com»), вы вводите код, Hermes подставляет его в страницу. В разговор код тоже не попадает.
Passkey, аппаратные ключи, подтверждения в приложении («нажмите Approve в Duo»): вводить нечего. Агент просит вас завершить проверку на устройстве и ждёт, пока страница двинется дальше.

Уже пользуетесь 1Password или Bitwarden?

Включать ничего не надо. Если утилита командной строки op или bw установлена и в ней выполнен вход, Hermes подхватит её автоматически, и логины сайтов из менеджера станут доступны для заполнения наравне с локальными. Когда агенту впервые понадобится один из таких логинов, он попросит разблокировать менеджер мастер-паролем (скрытый ввод; один раз за сессию, 30 минут простоя). Мастер-пароль Hermes передаёт CLI менеджера по неинтерактивному каналу (op signin через stdin, bw unlock --passwordenv через окружение дочернего процесса) и держит в памяти только токен сессии. Агент не видит ни мастер-пароля, ни токена, ни единого логина. Запись менеджера, в которой перечислено несколько сайтов (скажем, amazon.co.uk, www.amazon.co.uk и eu.account.amazon.com), заполняется на каждом из этих origin в точности; ничего сверх URL, сохранённых в записи, не домысливается.

Не хотите использовать найденный менеджер? hermes vault sources --disable bitwarden или переключатель в Settings → Passwords & Logins.

Оплата и заполнение адресов

Карты и адреса работают так же, как логины: сохраняются один раз (Settings → Passwords & Logins → Add или hermes vault add), привязываются к сайту оформления заказа и заполняются агентом только на нём. Каждое заполнение карты сначала спрашивает вас — тем же запросом на подтверждение, что и опасная команда; отказ ничего не записывает. Безголовые сессии (cron, вебхуки, API-сервер) подтвердить не могут и получают отказ, так что инъекция промпта, добравшаяся до страницы оплаты, может попросить, но не может потратить. Заполнение адреса подтверждения не требует.

Управление сохранённым

Десктоп → Settings → Passwords & Logins: всё сохранённое, найденные менеджеры паролей с кнопками Unlock/Lock, Add, Remove.
CLI: hermes vault list, hermes vault add, hermes vault rm <handle>, hermes vault sources.

Записи лежат в зашифрованном виде в ~/.hermes/vault/ (ключ Fernet и файл хранилища, оба с правами 0600), отдельно для каждого профиля. Метки, origin сайтов и идентификаторы логинов — видимые метаданные; пароли и данные карт покидают хранилище только в сторону страницы.

Безголовые сессии

У задач cron, вебхуков, API-сервера и hermes chat -q некому ответить на запрос. Сохранённые локальные логины там продолжают работать; заблокированный менеджер паролей сообщает unavailable_in_this_session, а отсутствующий логин — prompt_unavailable. Сначала разблокируйте или сохраните логин из интерактивной сессии либо выдайте 1Password токен сервисного аккаунта (OP_SERVICE_ACCOUNT_TOKEN).

vault:
  onepassword:
    enabled: false          # отключить найденный менеджер (по умолчанию: включён, если установлен)
    account: ""             # сокращение для `op --account`; пусто = по умолчанию
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: false

Что гарантируется, а что нет

Гарантируется: пароль никогда не попадает в контекст модели через Hermes — ни в результаты инструментов, ни в логи, ни в базу сессий, ни в аргументы командной строки какого-либо процесса. Заполнение идёт по прямому CDP-сокету контролируемой браузерной сессии и отклоняется, если origin страницы не совпадает с сохранённым в точности, — проверка повторяется внутри страницы непосредственно перед записью.

Не гарантируется: защита от самой страницы. Как только пароль введён на сайт, этот сайт (и любой скрипт, который он запускает) им владеет — ровно так же, как когда вы вводите его сами. На облачном браузерном бэкенде браузер вендора видит страницу как любую другую. Привязка к origin защищает от заполнения не на том сайте, а не от взломанного правильного.