Как защитить ключи Claude Code после взлома OpenCode: чек-лист

В ночь на 17 октября 2026 года кто-то залез в облачную консоль сервиса OpenCode и вытащил оттуда чужие ключи к нейросетям - к Claude, OpenAI и Google. Пострадавшие проснулись от писем о списаниях, которых они не делали. Деньги уходили с их карт, пока они спали.

Но дело тут не только в самом взломе. Большинство вайб-кодеров хранят свои ключи ровно так же беспечно, как пострадавшие, и просто пока им везёт. Я разобрал, что именно случилось, и собрал защиту ключей Claude Code и OpenAI в один чек-лист, который реально закрыть за вечер.

Разборы таких историй, готовые связки и нейросети без воды я каждую неделю выкладываю в своём Telegram-канале «The Maslov». Если хотите получать их первыми и задавать вопросы в комментариях, подпишитесь на канал, это бесплатно и ни к чему не обязывает.

Что именно взломали в OpenCode - и почему это касается не только его пользователей?

Взломали не сам редактор OpenCode на вашем компьютере, а отдельную облачную консоль под названием OpenCode Console, куда люди складывали свои ключи к нейросетям для удобства. Код-агент, который крутится у вас локально, напрямую тут ни при чём, но урок из этой утечки касается любого, кто доверяет свои ключи стороннему сервису.

Сама компания OpenCode описала это как взлом старой системы, которую они и так выводили из эксплуатации. По их заявлению, утечка затронула около 1,4% пользователей именно Console. Сооснователь OpenCode Dax Raad отдельно подчёркивал, что скомпрометирована была Console, а не сам OpenCode, и что эти ключи к ним на серверы вообще не попадают, пользователь хранил их у посредника сам.

Атаку назвали дистилляцией. Если без терминов, то злоумышленники гнали через украденные ключи огромный поток запросов к дорогим моделям за чужой счёт, предположительно чтобы собрать их ответы и натренировать модель подешевле. Длилось это около 48 часов непрерывных попыток.

Почему это касается вас, даже если вы никогда не открывали OpenCode?

Касается, потому что ваши ключи к Claude и OpenAI устроены точно так же, как у пострадавших, и защищены ровно настолько, насколько вы о них позаботились. Весь русскоязычный разбор этой новости свёлся к совету «получили письмо от OpenCode - отзовите ключ». Это помогает тем, кто сидел именно в Console, и совсем не помогает всем остальным.

А остальных большинство. Если вы вайб-кодите в Claude Code, в Cursor или в любом другом из открытых аналогов Claude Code, вы точно так же держите где-то свой платный ключ. И вопрос не в том, попали вы под эту конкретную раздачу или нет. Вопрос в том, что будет, когда под раздачу попадёте, а дыр для этого хватает - и сервис, которому вы отдали ключ, и собственный публичный репозиторий, и просто скриншот с ключом в чате.

Поэтому дальше будет превентивный чек-лист, который стоит пройти один раз и забыть про эту тревогу.

Что утекло и сколько реально могут снять с вашей карты?

Утекли именно API-ключи к платным нейросетям. Пароли от аккаунта и ваш код при этом не пострадали. API-ключ работает как логин с паролем, которым ваши программы сами обращаются к модели, и каждый такой запрос стоит денег и списывается с привязанной карты автоматически. Кто завладел ключом, тот тратит ваши деньги без всякого вашего участия.

Суммы у пострадавших разошлись сильно. По разборам в прессе одни отделались парой сотен долларов, другим насчитало до 1700 долларов за те же двое суток. У кого-то заблокировали проект в облаке из-за аномального трафика, и это отдельная головная боль поверх списаний.

Отдельно скажу про путаницу, которую развели пересказы. Независимо от этой истории, ещё раньше в самом агенте OpenCode нашли другую, никак не связанную дыру - RCE (remote code execution, удалённое выполнение кода на машине разработчика), и, по отчётам об этой уязвимости, закрыли её в релизе 1.18.22. Это не та же история, что утечка ключей из Console. Если увидите, что эти два инцидента смешивают в один, знайте - их путают.

Стоит ли доверять открытым AI-агентам реальные деньги?

Доверять можно, но открытость кода и безопасность денег - это разные вещи, и путать их опасно. В обсуждениях сразу всплыл старый спор. Одни считают, что раз код открыт и его смотрит много глаз, значит он безопасен. Другие резонно возражают, что аудировать открытый код можно самому, и это честный плюс.

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

Я не первый год вижу, как люди раздают доступы на автомате, и собирал про это отдельный чек-лист доверия доступам ИИ-агенту. Короткая мысль оттуда простая. Удобно - не значит безопасно, и за удобство посредника вы расплачиваетесь своими деньгами, а не он. А там, где речь о том, что ИИ-агенты на самом деле умеют и где кончается реальная польза, я отдельно разбирал ловушку громких бенчмарков - что они не видят в вашей работе.

Если копаться в настройках ключей самому неохота, а разобраться надо, я каждую неделю разбираю такие связки и инструменты в своём Telegram-канале «The Maslov», на конкретных примерах. Загляните в канал, там же можно задать вопрос и получить готовое решение, а не общие слова.

Какие из пяти типичных ошибок вайб-кодера совершаете вы?

Скорее всего, хотя бы одну из пяти. Это самые частые дырки, через которые ключи и утекают, и узнать в них себя не стыдно. Стыдно другое, оставить всё как есть после того, как прочитал и понял, где слабое место. Так что пройдитесь по списку спокойно и отметьте всё, что узнали про себя.

1. Вы не чувствуете разницы между ключом и паролем от аккаунта. Пароль защищает вход, а API-ключ - это прямой доступ к деньгам, который работает сам, без подтверждений и без вас.
2. Вы просите агента «просто доделать функцию», и он коммитит в репозиторий файл с ключом внутри. Ключ уезжает в историю, а вы об этом даже не узнаёте.
3. Вы завели публичный репозиторий на GitHub и положили туда файл с настройками, не прикрыв его. Публичный репозиторий индексируется, и такие ключи вылавливают боты за минуты.
4. У вас один ключ на все проекты и все среды сразу. Утёк он из одного маленького скрипта, а под удар попали все проекты разом.
5. Вы ни разу не ставили лимит трат. Страница с лимитом есть и у Anthropic, и у OpenAI, но пока не прижмёт, про неё никто не вспоминает.

Если отметили у себя две-три позиции, это нормально. Дальше по чек-листу мы их закроем по очереди.

Где на самом деле безопасно хранить ключи Claude Code и OpenAI?

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

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

# .gitignore - эта строка прячет файл с ключами от git
.env

# .env - лежит локально, в репозиторий не попадает
ANTHROPIC_API_KEY=sk-...ваш-ключ...
OPENAI_API_KEY=sk-...ваш-ключ...

Когда вы запускаете Claude Code в терминале, ключ он берёт как раз из такой переменной, а не из текста вашего кода. На хостинге вроде Vercel или Heroku для этого есть свой раздел переменных, и это надёжнее, чем файл с ключами на сервере. А если вы собрались отдать ключ стороннему облачному сервису-посреднику «для удобства», как было с OpenCode Console, относитесь к этому как к дополнительному риску по умолчанию и держите там минимум ключей.

Как ограничить права ключа Claude Code за 5 минут

Ключ не должен уметь больше, чем нужно одному проекту, и не должен тратить больше, чем вы заложили. Если держать его в этих рамках, то даже утёкший ключ не разорит вас за ночь. В худшем случае с него спишут копейки, пока вы будете его отзывать. У Anthropic на все эти настройки уходит буквально несколько минут, и сейчас я пройду по ним по шагам.

1. Заведите отдельный ключ под каждый проект, а не один на всё. Скомпрометированный ключ вы отключите точечно, не трогая остальные.
2. Поставьте месячный лимит трат на странице Billing. Это ваш главный предохранитель, выше потолка списать не дадут, сколько бы запросов ни гнали.
3. Раз в какое-то время заглядывайте в Logs и Usage. Там видно, когда и сколько ключ потратил, и аномальный всплеск вы заметите сразу, а не по счёту в конце месяца.
4. Меняйте ключи время от времени, ориентир - примерно раз в 90 дней, и сразу же при любом подозрении. Ключ, который живёт годами без ротации, это ключ, про который вы давно забыли.

Как сделать то же самое с ключом OpenAI

У OpenAI логика ровно та же, что у Anthropic, меняются только названия кнопок и разделов. Отдельный ключ под каждый проект, урезанные права, лимит трат и регулярная ротация, те же четыре действия закрывают почти весь риск и здесь. Чтобы не держать два кабинета в голове, я свёл в таблицу, где в каждом из них искать одно и то же, а потом разберу шаги для OpenAI по порядку.

1. Создавайте ключ, привязанный к конкретному проекту, а не ключ с правами на всё сразу.
2. Ограничьте ключу доступ к самым дорогим моделям, если проекту они не нужны. Нет доступа к дорогой модели - нет и счёта на тысячу долларов по ней.
3. Задайте лимит запросов в минуту и дневной или месячный потолок трат. Там же, где и у Anthropic, это страница с лимитами.
4. Поставьте ключу дату истечения и привяжите к IP, где это возможно. Ротация раз в 90 дней снимает кучу рисков просто тем, что старый ключ перестаёт работать.

Та же дисциплина нужна не только для ключей. Когда вы выдаёте ИИ-агенту доступ к деньгам или рекламному кабинету, проверять его права стоит так же въедливо - про это у меня есть отдельный разбор, что проверить, прежде чем дать агенту доступ к бюджету.

Что делать в первые 10 минут, если ключ уже утёк?

Действовать быстро и строго по порядку, потому что счётчик тикает и каждая минута промедления оборачивается чьими-то запросами за ваш счёт. Чем раньше вы отзовёте ключ, тем меньше успеют потратить, поэтому порядок шагов тут важнее спокойствия. Вот шесть действий, которые стоит пройти сразу, не откладывая на «вечером разберусь».

1. Немедленно отзовите ключ в консоли провайдера. У Anthropic это platform.claude.com, раздел с ключами, три точки у нужного ключа и удаление. У OpenAI - дашборд ключей и кнопка отзыва.
2. Сгенерируйте новый ключ сразу с ограниченными правами и лимитом трат. Не повторяйте старую ошибку, пока руки на месте.
3. Обновите новый ключ везде, где работал старый, и убедитесь, что старый больше нигде не прописан. Проверьте и настройки агента, и автоматические сборки, про них забывают чаще всего.
4. Загляните в Usage и Logs за подозрительный период у каждого провайдера. Так вы поймёте, успели что-то потратить или нет.
5. Проверьте биллинг на незнакомые списания. Если ключ был заведён через сторонний сервис, зайдите и в его дашборд, и в его статус в соцсетях - вдруг у него свой инцидент.
6. Напишите в поддержку провайдера, если списания явно мошеннические. По истории с OpenCode часть кредитов пострадавшим возместили, но закладываться на это как на план А не стоит - предотвратить дешевле, чем возвращать.

Ключ попал в Git-репозиторий - почему удаления файла не хватает

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

Правильный порядок такой. Сначала отзываете сам ключ у провайдера, как в предыдущем разделе, а уже потом чистите историю репозитория специальным инструментом.

# вариант с git-filter-repo: убрать файл из всей истории
git filter-repo --path .env --invert-paths

# или классический BFG Repo-Cleaner
bfg --delete-files .env

Отзыв ключа и чистка истории - это два разных действия, и одно не заменяет другое. Сначала отзываете, чтобы утёкший ключ перестал работать прямо сейчас, потом чистите историю, чтобы он не остался в репозитории памятником вашей ошибке.

Как проверить, не тратит ли кто-то ваши деньги прямо сейчас?

Зайти в раздел Usage у каждого провайдера и посмотреть на график трат за последние дни. Если там ровная знакомая линия - всё в порядке. Если в какой-то день торчит всплеск, которого вы не делали, это первый и самый ранний сигнал, что ключом пользуется кто-то ещё.

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

Сделайте это частью рутины, а не разовой реакцией на чужую новость. Поставьте себе напоминание проверять Usage, скажем, по понедельникам, и утечку вы поймаете на первом же всплеске, а не по счёту на 1700 долларов.

Чек-лист одной страницей: сохраните, пока не забыли

Если лень читать всё сверху, вот вся защита ключей Claude Code и OpenAI одним списком. Пройдите его один раз, и закроете три главные дырки, из-за которых люди и теряют деньги на чужих запросах. Распечатайте или сохраните в заметки, чтобы свериться, когда в следующий раз будете заводить новый ключ.

1. Ключи лежат в переменных окружения, а не в коде, не в промпте и не в публичном репозитории.
2. Файл с ключами добавлен в список игнорируемых, чтобы не уехать в git.
3. Под каждый проект заведён отдельный ключ, а не один на всё.
4. На каждом ключе стоит лимит трат и, где можно, ограничены права и дорогие модели.
5. Ротация ключей примерно раз в 90 дней и сразу при подозрении.
6. Раз в пару дней вы заглядываете в Usage и Logs на предмет чужих трат.
7. Если ключ попал в git - сначала отзыв у провайдера, потом чистка истории репозитория.
8. Сторонним облачным сервисам-посредникам отдаёте минимум ключей и не считаете их хранилище безопасным по умолчанию.

Утечка OpenCode для большинства из нас не беда, а бесплатная прививка. Потратьте вечер сейчас, пока не прижало, и спать будете спокойнее.

Если хотите и дальше получать такие разборы и готовые решения, я веду свой Telegram-канал «The Maslov»: связки, нейросети и лидогенерация на конкретных примерах. Подпишитесь на канал и забирайте следующий разбор первыми.

Евгений Маслов - автор блога themaslov.ru о маркетинге, нейросетях и заработке в интернете. В платном трафике с 2013 года; в своём Telegram-канале «The Maslov» каждую неделю выкладываю рабочие связки и разборы инструментов на конкретных примерах.