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