Принято считать, что расширяемая архитектура — это всегда благо. Но когда дело касается ключей доступа, передача контроля сторонним плагинам обычно заканчивается утечками. Разработчики Hermes Agent выкатили API для подключения любых менеджеров секретов, жестко зашив в само ядро только 1Password и Bitwarden. Посмотрим, как они пытаются обезопасить этот процесс.
Архитектура построена на тотальном недоверии к коду плагина. Разработчику предлагают реализовать класс SecretSource, но категорически запрещают напрямую писать в os.environ. Плагин имеет право лишь выполнить запрос и вернуть словарь. Разрешение конфликтов, порядок загрузки и защита базовых токенов остаются под строгим контролем оркестратора. Более того, метод fetch не имеет права падать с исключением или просить интерактивный ввод от пользователя. Любая заминка — и агент просто отбросит результат по аппаратному таймауту.
Для работы с консольными утилитами сторонних хранилищ заставляют использовать внутреннюю обертку run_secret_cli. Она принудительно очищает дочернее окружение, чтобы CLI-клиент случайно не утащил ключи, которые Hermes уже успел загрузить. Правда, в этой строгой изоляции кроется архитектурный изъян. Сторонние плагины обнаруживаются системой позже самого первого вызова загрузчика окружения. В итоге ваш кастомный vault не сможет отдать секреты для инициализации основного процесса при старте, оставаясь доступным только для последующих дочерних сессий.
Поделиться:
Инвестиции в инженерные кадры: структура компенсаций Google и поглощение команды Bun компанией Anthropic
Microsoft Flint: промежуточный язык визуализации данных для ИИ-агентов