Крадут API-ключи: что нашла разведка Google

Разведка Google опубликовала отчёт о том, как изменились атаки с использованием моделей: противники ушли от ручных запросов к агентным сценариям. Показательный случай второго квартала 2026 года — от захвата облачного ресурса до запущенной кампании по массовому сбору учётных данных прошло меньше шести часов. Для владельца API-ключа важна другая строка того же отчёта: ключи выгружают, а захваченные окружения используют, чтобы крутить на них свои задачи. Украденный ключ теперь не просто утечка, а чужая нагрузка на вашем счёте.

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

Что зафиксировано в отчёте

Главный вывод сформулирован в самом заголовке публикации: переход от промптинга к автономности. Если раньше модель была для атакующего удобным справочником, то теперь она встроена в рабочий процесс как исполнитель.

Три наблюдения, которые стоит выделить.

Скорость. Шесть часов от компрометации облачного ресурса до работающей кампании по сбору учётных данных. Раньше такой цикл занимал дни.

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

Мотив. Захваченные окружения используются для поддержания несанкционированных нагрузок. То есть ресурс жертвы становится вычислительной базой атакующего.

Google сообщает, что часть активности сработала на защитных механизмах, аккаунты отключены, а классификаторы и сама модель обновлены, чтобы отказываться помогать в подобных сценариях.

Почему ключ стал самостоятельной целью

Раньше утечка ключа означала утечку доступа к данным, которые через него проходят. Теперь у ключа появилась вторая ценность: это оплаченный кем-то другим доступ к вычислениям.

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

Вторая неприятность в том, что такую утечку сложнее заметить по косвенным признакам. Никто не удаляет ваши данные и не портит продукт: снаружи всё работает, а расход тихо утраивается.

Три признака, по которым это видно

Расход не совпадает с нагрузкой. Число пользователей то же, счёт вырос. Это первый и главный сигнал.

Запросы в нерабочее время. Если ваш сценарий живёт по будням с девяти до шести, ночная активность в выходные — повод открыть журнал.

Обращения к чужим моделям. В журнале появляются идентификаторы, которых нет в вашем коде. Атакующему нужны не те модели, что вам.

Чтобы эти признаки были видны, журнал запросов должен вестись с первого дня, а не заводиться после инцидента. Как его организовать, разобрано в статье логирование запросов к моделям.

Что реально ограничивает ущерб

Меры расположены по убыванию пользы, а не по сложности.

1. Потолок расхода. Единственная мера, которая работает без вашего участия. Выставляется до первого запроса.
2. Отдельный ключ на каждую нагрузку. Прод, тесты, эксперименты, каждый подрядчик. Так виден расход по каждой и отзыв одной не роняет остальные.
3. Ключ только на сервере. Всё, что уехало во фронтенд, доступно любому посетителю через инструменты разработчика.
4. Ротация. Плановый перевыпуск раз в несколько месяцев и обязательный — после ухода людей из проекта.
5. Журнал с идентификатором запроса. Без него разбор инцидента превращается в гадание.

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

Порядок действий при утечке

Он не обсуждается и не меняется от масштаба.

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

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

Откуда ключи утекают чаще всего

Экзотические сценарии из отчётов разведки — не самая частая причина. Обычные утечки выглядят скучно.

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

Пересылка в переписке. Ключ, отправленный в мессенджер или почту, считается скомпрометированным. Он останется в архиве, в резервной копии и на устройстве получателя.

Сборка фронтенда. Ключ попал в переменные, которые собираются в клиентский бандл. Открывается инструментами разработчика в браузере за секунду.

Логи и трассировки. Заголовок запроса целиком попал в журнал ошибок, журнал уехал во внешний сервис мониторинга.

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

Общая черта всех пяти: это не взлом, а процесс. Поэтому и защита процессная — отдельные ключи, потолки и плановая ротация, а не героические меры после инцидента.

Как проверить свой ключ за десять минут

Короткая ревизия, которую полезно провести прямо сегодня.

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

Отдельно про агентов на вашей стороне

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

Из этого следуют те же меры: минимальные права вместо удобных, песочница, ограничение доступа к сети и отдельный ключ с потолком расхода. Что именно стоит разрешать, разобрано в статье права агента: что разрешать, а случаи, когда изоляция не удержала, разбирали в материале побеги агентов из песочницы.

Что это значит для нашего каталога

Никаких особых мер со стороны читателя это не требует, но пара вещей полезна.

Ставка в каталоге фиксирована в рублях и одинакова на вход и на выход, поэтому чужая нагрузка видна в расходе линейно и считается без валютных пересчётов. Ставки на 12 сентября 2026 года:

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

Чего мы не утверждаем

Мы не пересказываем технические детали кампаний и не публикуем индикаторы компрометации: это работа профильных команд, а не блога про API.

Мы не утверждаем, что перечисленные меры дают гарантию. Они ограничивают ущерб и сокращают время обнаружения, а не устраняют риск.

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

Что нужно, чтобы навести порядок у себя

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях.

Если сейчас у вас один ключ на все задачи, разумный первый шаг — завести отдельные под прод, тесты и эксперименты, выставить каждому потолок и отозвать старый.

Что держать в голове

Ключ стал самостоятельной целью: его крадут не ради ваших данных, а ради ваших вычислений.

Такая утечка не ломает продукт и поэтому не видна снаружи. Видна она только в расходе и в журнале.

Порядок при подозрении один: отзыв, замена, журнал, расследование. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ: keydealer.ru/login.