Простий 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 для секретів, до яких звертаються агенти.