Простой secret vault для CLI-агентов

Что я сделал и где проходит граница безопасности

К сентябрю 2026 года я собрал для себя примитивный secret vault для CLI-агентов. В своей статье на Medium о создании secret manager я описал сам проект и причину, по которой он появился. Это не попытка заменить зрелые хранилища, а практический ответ на неприятный вопрос: что именно агент получает вместе с доступом к токену?

Базовый принцип простой: секрет не должен попадать в промпт, инструкцию или репозиторий. Если агент видит API-ключ как обычный текст, prompt injection или неудачный вызов инструмента могут превратить локальную автоматизацию в канал утечки. Безопаснее хранить непрозрачную ссылку, а реальное значение подставлять только во время выполнения команды.

Для локального CLI разумной основой выглядит системное защищённое хранилище. В документации Keeper Secrets Manager CLI описано сохранение конфигурации через macOS Keychain, Windows Credential Manager и Linux Secret Service. Библиотека Python keyring даёт к этим системным механизмам единый интерфейс, поэтому самодельному vault не обязательно изобретать собственное хранение ключей.

Для продакшена логичнее отделить CLI от постоянных секретов полностью. Документация Google Secret Manager и AWS Secrets Manager описывает хранение и получение API-ключей, паролей и других чувствительных значений, а AWS также документирует ротацию. CLI в такой схеме становится посредником, а не сейфом.

Но vault решает только хранение. Следующий слой должен выдавать короткоживущие учётные данные на одну задачу или сессию, ограничивать файловый и сетевой доступ агента, а также записывать обращения на уровне инструментов. Иначе мы просто аккуратно спрятали слишком мощный ключ.

Почему одного vault недостаточно

Главный выигрыш здесь не в новом формате хранилища, а в разделении модели и секрета. Агенту можно оставить право запросить операцию, не показывая значение, которым эта операция подписывается или авторизуется.

Для локальных экспериментов примитивный vault уже лучше токена в файле рядом с проектом. Для автономных агентов этого мало: нужны минимальные права, песочница, отзыв доступа, ротация и журнал действий. Больше всего проигрывает привычная схема с постоянным универсальным ключом в переменной окружения каждого процесса.

Я бы первым делом проверял не шифрование хранилища, а путь секрета после извлечения. Особенно опасны аргументы командной строки, логи, дампы ошибок и контекст модели. Без контроля последней мили даже хороший backend превращается в дорогой способ передать секрет не туда.

Поэтому мой примитивный vault интересен скорее как точка сборки правильной архитектуры. Настоящая граница безопасности проходит не вокруг файла с ключами, а вокруг каждой операции, которую агент способен выполнить от имени пользователя.

Мы ранее разбирали, как Secret Storage в Obsidian влияет на безопасность плагинов и ИИ-автоматизации. Эти принципы полезны и при проектировании vault для секретов, к которым обращаются агенты.