Найди ключи и пароли до того, как их найдут другие

Что это

Когда собираешь продукт с ИИ, в проекте копятся секреты: ключ от ИИ-сервиса, токен Telegram-бота, пароль от базы. А ещё — реальные телефоны и почты, которые ты вставил «для проверки». Всё это легко отправить на GitHub вместе с кодом. Публичный репозиторий могут прочитать посторонние, а ключи там ищут автоматически.

Промпт закрывает три ситуации:

1. Спрятать файл с ключами — добавить его в список файлов, которые Git не сохраняет, и убедиться, что он больше не отслеживается, не удаляя с диска.
2. Проверить проект перед публикацией — не только код, но и места, где о секретах забывают: примеры настроек, тестовые данные, сообщения об ошибках, файлы публикации, заметки.
3. Убрать утёкший ключ — если он уже попал в интернет. Ключ, который хоть раз был опубликован, считается утёкшим: его нужно заменить в самом сервисе, а потом вычистить старый отовсюду.

Агент не выводит значения ключей в ответ — только где они лежат и что с ними делать.

Как использовать

1. Выясни, как называется твой файл с ключами (часто .env или похожее). Не знаешь — спроси агента. Проект достался от фрилансера или из шаблона — сначала разберись в чужом проекте.
2. Отправь шаг 1, потом шаг 2. Читай список находок внимательно.
3. Если агент нашёл ключ, который уже уходил на GitHub, — сначала зайди в сервис, выпусти новый ключ и отключи старый. Это делаешь ты руками.
4. После этого отправь шаг 3.
5. Совет: в тестовых данных используй выдуманные имена и почты вроде name@example.com. А чтобы агент в Claude Code не трогал ключи и впредь, поставь 12 модов Claude Code для вайбкодера (490 ₽) — среди них есть защита ключей.

Промпт

Шаг 1. Спрятать файл с ключами.

Заведи в проекте файл .gitignore, если его ещё нет, и внеси туда файл с ключами — у меня это [имя файла, например .env; если не знаешь — найди сам и спроси меня].
Проверь, что Git больше его не отслеживает. Если файл уже попадал в отслеживаемые — убери его оттуда, но с диска не удаляй.
Покажи списком все файлы, которые уйдут на GitHub при следующей отправке.
Объясни изменения простыми словами.
…

Шаг 2. Проверка перед публикацией.

Проверь проект на утечки перед публикацией. Пока ничего не меняй.

Пройди по файлам, которые уйдут на GitHub, и по истории сохранений проекта.
Ищи: ключи доступа, пароли, токены сервисов и ботов, строки подключения к базе, а ещё настоящие телефоны, адреса почты, имена и адреса людей.

Загляни туда, где о них легко забыть:
— файлы настроек и примеры настроек;
— заготовки с тестовыми данными;
…

Шаг 3. Если ключ утёк. Отправляй только после того, как выпустил новый ключ и отключил старый.

Ключ сервиса [название сервиса] засветился и считается утёкшим. Новый ключ я уже выпустил, старый отключил.

Найди все места, где упоминается старый ключ:
— файлы проекта, включая настройки и примеры;
— историю сохранений проекта;
— заметки и документацию;
— файлы, которые управляют публикацией.

…

Что дальше

Ключи — только одна из дыр: доступ без входа и утечки в ответах сервера проверяет Найди дыры в проекте до того, как их найдут другие. Когда проверка чистая, выкладывай проект по шагам из Выложить проект в интернет без сюрпризов. Повторяй шаг 2 перед каждой крупной публикацией — особенно после того, как подключил новый сервис.