Маленький стартап из Мексики столкнулся с типичным для облачных сервисов, но крайне болезненным сценарием: украденный API-ключ Google Gemini был использован злоумышленниками для массовых запросов к моделям ИИ, что всего за двое суток сформировало счёт свыше 82 000 долларов США. Инцидент вскрыл не только проблему защиты ключей на стороне клиента, но и архитектурные особенности экосистемы Google Cloud, о которых многие разработчики попросту не знают.
Как кража API-ключа обернулась ростом расходов на 46 000%
По словам разработчика, описавшего ситуацию на Reddit, компрометация произошла в период с 11 по 12 февраля. За это время неизвестные атакующие интенсивно вызывали Gemini 3 Pro Image и Gemini 3 Pro Text, полностью исчерпав доступный лимит и сформировав платёж на 82 314 долларов.
Обычно команда из трёх человек тратила на API не более 180 долларов в месяц, поэтому дополнительные расходы выросли примерно на 46 000%. После обнаружения аномальной активности разработчик немедленно отозвал скомпрометированный ключ, отключил Gemini API, поменял все учётные данные и обратился в поддержку Google с запросом о списании или снижении начисленной суммы.
Ответ Google опирался на модель shared responsibility — «разделённой ответственности»: компания обеспечивает безопасность облачной платформы, но защита ключей, токенов и других секретов лежит на пользователе. При этом пострадавший разработчик отмечает, что даже частичное взыскание долга (например, треть суммы) может привести к банкротству их небольшого стартапа.
Исследование Truffle Security: старые ключи Google становятся входом к Gemini
Практически параллельно с этим случаем специалисты Truffle Security провели масштабное сканирование публичных ресурсов и обнаружили 2863 действующих API-ключа Google, которые изначально создавались как простые идентификаторы проектов для учёта трат, но теперь позволяют обращаться к Gemini API.
Ключевая проблема — в формате и повторном использовании API-ключей Google Cloud. Эти ключи, как правило, начинаются с префикса AIza и легко обнаруживаются при автоматическом анализе исходного кода, репозиториев и веб-страниц. Более того, в ряде официальных руководств Google (например, для Maps и Firebase) прямо указывается, что такие ключи не являются секретами и предназначены только для идентификации проекта.
В случае с Google Maps разработчикам до сих пор рекомендуют вставлять ключ прямо в HTML-код, то есть в зону, полностью доступную всем посетителям сайта и поисковым роботам. Проблема в том, что эти же ключи теперь могут автоматически использоваться и для доступа к Gemini, без дополнительного предупреждения владельцев.
Когда «несекретный» ключ превращается в учётные данные для ИИ
Как поясняет исследователь Джо Леон (Joe Leon) из Truffle Security, типичный сценарий выглядит так: разработчик три года назад создаёт API-ключ для Google Maps и по инструкции размещает его в открытом исходном коде сайта. Спустя время в том же проекте включается поддержка Gemini API, и этот старый ключ фактически получает новые привилегии — становится полноценными учётными данными для работы с LLM.
В результате любой, кто найдёт такой ключ в публичном репозитории или в HTML-странице, может:
• выполнять запросы к Gemini за счёт владельца аккаунта;
• получать доступ к загруженным файлам и кешу моделей, если это разрешено конфигурацией;
• генерировать значительные расходы, незаметные до момента выставления счёта.
Реакция Google и текущий статус проблемы
Truffle Security уведомила Google о проблеме, предоставив в качестве доказательства пример публичного сайта, где ключ, размещённый ещё в 2023 году, открывал доступ к Gemini API. Изначально, в ноябре 2025 года, отчёт был отклонён как «ожидаемое поведение системы».
После того как исследователи продемонстрировали аналогичные случаи в собственной инфраструктуре Google, инцидент был всё же классифицирован как баг повышенной серьёзности, а команда безопасности запросила полный список из 2863 обнаруженных ключей. По состоянию на начало февраля компания сообщала, что ведётся работа над исправлением, а также уже внедрены проактивные механизмы для обнаружения и блокировки утекших ключей при попытке обращения к Gemini API.
Практические рекомендации по защите API-ключей Google Cloud и Gemini
Эксперты Truffle Security рекомендуют всем пользователям Google Cloud провести аудит своих проектов и репозиториев с помощью опенсорс-инструмента TruffleHog, который сканирует исходный код, CI/CD-пайплайны и веб-ресурсы на предмет утечки секретов и API-ключей.
С точки зрения кибербезопасности инцидент с Google Gemini демонстрирует более широкий паттерн: публичные идентификаторы постепенно обрастают чувствительными привилегиями. По мере того как крупные платформы спешно интегрируют ИИ-сервисы в существующие продукты, старые ключи и токены неожиданно для владельцев начинают открывать доступ к новым, гораздо более дорогим и критичным функциям.
Чтобы снизить риски, организациям имеет смысл:
• рассматривать любые API-ключи как секреты по умолчанию и не размещать их в открытом коде;
• регулярно пересматривать назначение и область действия существующих ключей при подключении новых сервисов (включая LLM и ИИ-API);
• внедрять автоматическое сканирование репозиториев на утечки секретов на каждом этапе CI/CD;
• настраивать бюджеты, алерты и жёсткие квоты расхода в облачных платформах, чтобы аномальная активность выявлялась в течение часов, а не недель.
История с утечкой API-ключа Google Gemini показывает, что даже один «несекретный» на первый взгляд ключ способен превратиться в дорогостоящий инцидент. Разработчикам и компаниям, активно использующим облачные ИИ-сервисы, стоит воспринимать управление API-ключами как критический элемент информационной безопасности и инвестировать в процессы, инструменты и обучение, которые помогут предотвратить подобные сценарии в будущем.
