Гарантую, що ваш ШІ агент бачив ваші API ключі та паролі
Бо вони лежать у .env
А ваш AI coding agent має доступ до репозиторію.
Розробників роками переконували:
«Never commit your .env.»
А тепер всі дружно дали AI-агентам доступ до всієї робочої директорії — разом із:
— OPENAI_API_KEY
— AWS_SECRET_ACCESS_KEY
— database credentials
— GitHub tokens
— production secrets
Технічно .env не потрапив у Git.
Але секрет усе одно лежить plaintext-файлом поруч із кодом.
Саме тому я зробив SecureVault — open-source secret manager для локальних developer workflows.
Замість:
project/.env → API_KEY=super-secret-value
секрет зберігається в native credential storage вашої ОС:
macOS → Keychain
Windows → Credential Vault
Linux → Secret Service
А потрібному процесу SecureVault передає його тільки під час запуску:
securevault run node server.js --profile dev securevault run docker compose up --profile production securevault run terraform apply --profile aws
Ніяких plaintext secrets у репозиторії.
Ніякого .env, який випадково прочитає AI agent.
Дисклеймер
Утиліта призначена для локальної розробки, не для продакшену.
24 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівСхоже що це вже винайшли до вас
github.com/helmfile/vals
Звучить цікаво, дякую
Кладите секреты в гит и делайте деплоймент с ними
Локальные креды для разработки и тестов
Пост закрыт
Вчора тільки прочитав про схожу утіліту aws vault github.com/99designs/aws-vault вона тимчасові короткострокові токени генерує. Але це рішення тільки для aws.
Також відносно нещодавно з’явилось комплексне рішення від Docker. Сандбокс (sbx) для агентів.
Там також є рішення для зберігання секретів ззовні контейнеру з агентом. Токени інжектяться у http проксі. І це не єдине рішення такого роду. Зараз з цим якраз розбираюсь.
я знаю продукты у которые прямо рутовые ссш ключи от кластера с прода и кубернетеса подключены прямо в Клаудю, и все репорты и проблемы они прогоняют через клаудю, он сам лазит по кластеру и анализирует метрики, поды, ноды и тд. только стоит запрет на ребут и манипулирование деплойментсами. Куда там ваши ключи, если с ноды можно тупо слить все сикреты от все сервисов, и настанет день, когда ИИ будет знать весь ваш продакшен кластер , все ключи и захавает его
а в пермішинах виставити deny Read(.env*) хіба недостатньо?.. але я сам в це не вірю, так)
Хороша ідея, але ніщо не заважає агенту зробити Bash(cat .env)
Можна заборонити і це , але він знайде спосіб прочитати файл якщо треба.
www.passwordstore.org
Але навіть з цим: що заважає агенту виконати printenv?
Ця можливість є у будь-якого user space додатку, а моя утиліта призначена не допустити читання агентом plaintext .env що лежить в корені репо під час локальної розробки. Взяти той самий docker compose — щось краще plaintext .env я поки не зустрічав. Принаймні в себе на проєкті — біля 60 мікросервісів. І всюди сталий патерн — для локального прогону потрібно створити якийсь untracked файлик за зразок .env чи appsettings.json де зазвичай лежать сенситивні дані. Сам файлик до речі часто попадає в гіт через неуважність розробників. Я вже не кажу про те що корпоративний Copilot його спокійно читає. Це звісно, не проблема, бо він корпоративний. Але це не зовсім правильно.
Ви можете логічно заперечити, чому б не використати якийсь Azure KeyVault чи AWS Secrets Manager.
Звісно, це набагато краща альтернатива, але вона потребує переписування коду самого додатку і не зовсім зручна для локальної розробки.
Я до того, що мабуть треба йти шляхом devcontainers + auth proxy, коли в контейнері взагалі немає ніяких секретів, та будь який код (агент, 3рд парті пакет) не може ніяк його дізнатись, навіть зробивши інтроспецію процесів. А ключи вже додаються в HTTP headers на рівні проксі-сервера.
Дисклеймер: Утиліта призначена для локальної розробки з ШІ, не для продакшену
Ні, бо користуюся «шішками» або локальними, або коли онлайн то лише через браузер, питаю шо треба знати для вирішення задачі і коли пропонує перелік — переглядаю з уточнюючими запитаннями «а навіщо саме це тобі знадобилося».
Якщо не секрет, то якими?
боюся спитати — а в до-ллм-ну епоху ти ніколи не пробував підключитись до «потрібного процесу», щоб його продебажити? не пам’ятаєш раптом, чи видно там всередині всі оті параметри і креди, які ти іззовні передав? ;)
а зараз в ролі дебаггера якраз ллм-ка часто і виступає.
але це так, ліричний відступ.
головне — ти пропонуєш передавати мої секрети якомусь npm package, в секюрності якого я зовсім не впевнений (і не маю бажання вичитувати вихідний код на пошук прихованих бекдорів). ще й дати йому доступ до ОС credentials store.
при тому що якщо б я вирішив чомусь заморочитись, я б краще Infisical в докері підняв, у них хоч SOC 2 є, що передбачає якийсь аудит.
тому вангую що «не взлетить».
Схіралі на «ти», шановний?
а яка нафік різниця. я в інеті з усіма на ти
ні, ну іноді я намагаюсь «викати», бо окремі особистості агряться.
але переважно забиваю. ;)
Джаваскріптери тільки на Ви, що за питання
З підключенням, перший день в інтернеті?
Ви на роботі з незнайомими колегами на ти чи на ви?
Підозрюю, що аби отримати у відповідь
та
в одному реченні. Не кожного дня можна побачити таку витончену комбінацію ))
lol барон з франківського вокзалу обурився :D
Это когда аргументов нет, то такое пишут...
Найголовніше не уподібнюватись інородцям, навіть з українськими прізвищами, які намагаються зневажати і плюндрувати нашу традиційну українську культуру.
Проблема свинособацтва, так само як і наприклад, проблема свинства через розкидання сміття, вмовляннями і переконуваннями не вирішуються. Лише через невідворотність справедливого, наприклад адміністративного, покарання.
+100500