Claude Code с «Don't Ask Again» утащил пароли в 1122 публичных файла на GitHub

Вы сто раз нажимали «Don't Ask Again», чтобы агент перестал дёргать вас по каждой команде. Удобно. Но исследователи из Apiiro показали, что у этого удобства есть цена: в публичном GitHub нашлось 1122 файла с паролями, которые утекли именно через такие разрешения Claude Code.

Оговорка: в нашем распоряжении только заголовок и сигнал с Hacker News (114 очков, 85 комментариев), а не полный текст отчёта. Поэтому механизм ниже описан как наиболее вероятный, а детали стоит сверить с оригиналом.

Как пароль оказывается на GitHub

Представьте типичную сессию. Вы просите агента подключиться к базе и прогнать миграцию. Он формирует команду, в которой пароль стоит прямо в строке подключения, например в параметре или переменной окружения. Claude Code спрашивает разрешение. Вы выбираете «Don't Ask Again», чтобы не подтверждать это каждый раз.

Чтобы запомнить ваш выбор, инструмент записывает правило разрешения в файл настроек проекта. Если правило привязано к конкретной команде, в файл попадает и сама команда целиком, включая секрет. Дальше всё как всегда: git add, commit, push. Файл настроек лежит в репозитории рядом с кодом, и если репозиторий публичный, пароль доступен всем.

Важно, что никто не делал ничего очевидно глупого. Человек не вставлял пароль в README и не коммитил .env. Секрет утёк побочным эффектом удобной функции, которую никто не воспринимает как место хранения данных.

Почему это серьёзнее обычной утечки

Классические сканеры секретов ищут знакомые паттерны в коде и конфигах приложения. Файлы настроек агента для них часто слепая зона: это не исходники и не .env, поэтому правила и ожидания команды на них не распространяются.

Есть и второй слой проблемы. Агенты охотно подставляют креды в командную строку, потому что так проще решить задачу. Любой механизм, который запоминает команды, превращается в журнал секретов. Это касается не только Claude Code: те же риски есть у любого ассистента, который хранит список разрешённых действий рядом с проектом.

Число 1122 тоже стоит читать трезво. Это то, что нашлось в публичном поиске. Приватные репозитории, форки и уже удалённые, но закэшированные файлы сюда не входят, а значит реальный масштаб, скорее всего, больше.

Что делать прямо сейчас

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

Во-вторых, разведите общие и локальные настройки. Правила, которые команда хочет разделять, должны жить отдельно от личных разрешений, а локальный файл должен быть в .gitignore.

В-третьих, добавьте сканер секретов в pre-commit и CI и явно включите в проверку файлы настроек ИИ-инструментов. Это дешёвая страховка.

В-четвёртых, не давайте агенту секреты в командной строке. Передавайте их через переменные окружения из менеджера секретов или через временные токены с коротким сроком жизни. Тогда даже запомненная команда не содержит ничего ценного.

Вывод для продактов и основателей

Это хороший пример того, как удобство разрешений в агентных инструментах создаёт новую поверхность атаки. Если вы делаете собственного агента, подумайте, что именно вы сохраняете при запоминании выбора пользователя: шаблон команды или её буквальный текст, и не лежит ли это в файле, который по умолчанию попадёт в git. Маскирование секретов перед записью и безопасное расположение файла стоят пары дней работы, а утечка в тысячу репозиториев обходится куда дороже.