В начале 2026 года на Reddit появилась история, быстро разлетевшаяся по IT-сообществу. Разработчик рассказал, что злоумышленники получили доступ к его Google Gemini API key и за 48 часов накрутили около $82 000 расходов на AI API.

Сначала многие восприняли это как очередной случай: «не храни секреты в публичном репозитории».

Но затем выяснилось, что ситуация намного сложнее и неприятнее.

Что произошло

По словам автора, был скомпрометирован API-ключ Google Cloud / Gemini. После этого злоумышленники начали массово использовать Gemini API для генерации запросов и быстро сожгли огромную сумму.

История:

• Reddit: Original Reddit Thread
• Разбор: TechRadar Article
• Дополнительный обзор: TechSpot Coverage

Сам факт утечки API-ключа — не новость. Такое происходило и раньше.

Но разработчиков особенно напугали три вещи:

• отсутствие жёстких лимитов расходов;
• скорость роста счёта;
• изменение роли старых Google API keys.

Самый спорный момент: «публичные» ключи внезапно стали опасными

Именно это вызвало основную волну критики.

Исторически многие Google/Firebase API keys считались почти публичными. Например:

• ключи для карт;
• Firebase config;
• client-side integrations.

Их часто встраивали прямо во frontend. Google сам годами показывал такие примеры в документации.

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

Многие разработчики считают, что semantics ключей изменились без достаточного предупреждения.

Обсуждения:

• Reddit Discussion on Repurposed Keys
• Cybersecurity Discussion

Это важный нюанс.

Разработчики привыкли воспринимать такие ключи как:

• идентификатор проекта;
• ограниченный client token;
• технический конфиг.

А внезапно оказалось, что они могут стать источником финансового риска на десятки тысяч долларов.

Почему нельзя просто поставить лимит?

Это следующий шок для многих пользователей Google Cloud.

Оказывается, Google Budgets — это не hard cap.

Google прямо пишет в документации:

“The budget doesn't automatically set a hard cap on spending.”

Документация:

• Google Cloud Budgets Documentation

То есть budget:

• отправляет уведомления;
• может триггерить automation;
• но сам по себе не останавливает расходы.

И здесь возникает проблема.

AI API способны тратить деньги с огромной скоростью:

• тысячи запросов в минуту;
• автоматические retry loops;
• агенты;
• batch jobs;
• генерация больших ответов.

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

Некоторые пользователи жаловались, что billing alerts приходили с большой задержкой.

Почему Google так сделал?

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

Для enterprise-клиентов внезапное отключение инфраструктуры — очень опасная ситуация:

• остановка приложений;
• потеря данных;
• падение API;
• проблемы у клиентов.

Поэтому AWS, Google Cloud и Azure традиционно предпочитают:

• продолжать работу;
• а потом выставить счёт.

Это было относительно терпимо в эпоху:

• виртуальных машин;
• баз данных;
• обычных API.

Но AI сильно изменил ситуацию.

LLM-модель может сжечь огромный бюджет буквально за часы.

«Постройте защиту сами»

Google предлагает использовать:

• quotas;
• alerts;
• Cloud Functions;
• автоматическое отключение сервисов;
• кастомную автоматику.

Документация:

• Google Budget API Overview

И здесь появляется ещё одна неприятная проблема.

Чтобы автоматически отключать сервисы, нужен более привилегированный доступ:

• billing admin;
• service usage admin;
• quota management.

То есть для защиты от runaway billing приходится хранить ещё более опасные ключи.

Из-за этого многие компании сейчас переходят на другую архитектуру:

client   
  ↓
own backend / gateway   
  ↓
Gemini / OpenAI / Claude

Это позволяет:

• скрыть vendor API keys;
• ставить свои лимиты;
• блокировать аномалии;
• отслеживать abuse;
• выдавать временные токены.

Но такая схема:

• дороже;
• сложнее;
• требует своей инфраструктуры;
• увеличивает latency.

Реакция сообщества

Массового бойкота Google пока нет.

Но доверие заметно пострадало.

Сейчас активно обсуждаются:

• опасность AI API keys;
• отсутствие hard caps;
• необходимость proxy/gateway;
• переход на self-hosted/open-weight модели;
• локальный inference.

Появляются:

• monitoring-сервисы;
• anomaly detection tools;
• security writeups;
• инструменты автоматического отключения API.

Для многих разработчиков главный вывод оказался довольно жёстким:

LLM API key — это уже не просто технический секрет.

Это финансовый риск.

И чем автономнее становятся AI-агенты, тем опаснее становится утечка таких ключей.

Важный вывод

При этом важно не уходить в крайности.

Проблема не означает:

• что Google Cloud «сломался»;
• что AI API нельзя использовать;
• что облака бесполезны.

Но история показала, что индустрия пока не до конца адаптировалась к новой реальности AI.

Старые подходы к:

• API keys;
• billing;
• quotas;
• frontend integrations;
• cloud security

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

И сейчас разработчики, компании и сами облачные провайдеры только начинают перестраивать свои подходы под эти риски.