безопасность

Google Cloud и Gemini API keys: где ломается AI security

Почему старые Google API keys стали опаснее после Gemini: публичные ключи, счета за инференс, задержки budget alerts и окно отзыва до 23 минут.

По состоянию на 27 мая 2026 года история с Google Cloud Gemini API keys выглядит уже не как частный спор о неаккуратных разработчиках. Это пример того, как быстро меняется смысл старых облачных примитивов, когда поверх них включают дорогие ИИ-сервисы. Ключ, который годами воспринимался как публичный идентификатор проекта для Maps или Firebase, после включения Gemini API может стать доступом к файлам, кэшу и счёту за инференс.

Поводом стало интервью COO Google Cloud Фрэнсиса де Соузы в TechCrunch от 24 мая. Он говорил о security для ИИ как о задаче уровня совета директоров: shadow AI, multicloud governance, защита моделей, data pipelines, агентов и prompts. Это правильная рамка. Но рядом с ней уже есть практический слой: пользователи Google Cloud получали пятизначные счета после злоупотребления API keys, Truffle Security нашла 2 863 живых публичных ключа с Gemini-доступом, а Aikido показала, что удалённый Google API key в тестах мог продолжать работать почти 23 минуты.

Главный вывод для команд простой: безопасность ИИ начинается не с политики на презентации, а с инвентаризации проектов, ключей, лимитов и того, что реально произойдёт в первые 30 минут после утечки.

Что именно сказал Google Cloud

В интервью TechCrunch де Соуза описал AI security как платформенную проблему. Компании больше не защищают только сеть и приложения. В периметр входят модели, обучающие и рабочие данные, агенты, промпты, интеграции и старые хранилища, которые агент может внезапно найти внутри организации.

Он также сослался на ускорение атак: по его словам, среднее время между первичным проникновением и передачей атаки на следующий этап сократилось с восьми часов до 22 секунд. В такой среде ручная реакция не успевает. Отсюда тезис Google Cloud: защита должна быть встроена в платформу, а не прикручена после запуска ИИ-проекта.

Проблема в том, что платформа сама проходит переходный период. Пока Google Cloud говорит о governance и auditability, разработчики сталкиваются с более приземлённым вопросом: какие права на самом деле есть у ключей, которые уже лежат в клиентском коде, старых репозиториях и прототипах?

Почему Gemini API keys изменили риск

Truffle Security описала корневой конфликт в феврале 2026 года. В Google Cloud долго использовался один узнаваемый формат API key, начинающийся с AIza..., для разных задач. Для Maps и Firebase такие ключи часто размещали в клиентском коде, потому что они работали скорее как идентификатор проекта и биллинга. Это не то же самое, что service account JSON key.

С появлением Gemini ситуация стала другой. Если в проекте включена Generative Language API, старый ключ в том же проекте может получить доступ к чувствительным Gemini endpoints. Truffle показала сценарий, в котором такой ключ позволяет обращаться к /files/ и /cachedContents/, а также генерировать платные запросы. В их скане Common Crawl за ноябрь 2025 года нашлось 2 863 живых Google API keys, уязвимых к этому вектору.

Truffle Security показывает сдвиг: ключ, который раньше воспринимался как публичный идентификатор для Maps, после включения Gemini может стать чувствительным credential. Источник: Truffle Security.

Преувеличивать тут нельзя. Не любой Google API key в интернете автоматически даёт доступ к Gemini. Условие конкретнее: в проекте должен быть включён соответствующий API, а ключ должен быть unrestricted или явно разрешать Generative Language API. Именно это делает риск неприятным: он зависит не от одного файла с ключом, а от состояния всего Google Cloud project.

Google после раскрытия начал закрывать часть проблемы. На странице Google AI Developers для Gemini API keys сейчас указано, что unrestricted keys уязвимы к несанкционированному использованию, а с 19 июня 2026 года Gemini API прекращает поддержку unrestricted traffic keys. Там же сказано, что ключи можно ограничивать через AI Studio или Cloud Console. Документация была обновлена 26 мая 2026 года, поэтому эту дату стоит считать текущей точкой отсчёта.

Счета показали слабое место лимитов

Истории с billing стали публичными в марте и мае. Tom's Hardware пересказал случай разработчика, у которого обычный месячный расход на Gemini был около $180, а после компрометации ключа за 48 часов накопилось $82 314,44. The Register отдельно писал о пользователях Google Cloud, у которых счета доходили до пятизначных сумм после запросов к Gemini, Veo и другим дорогим моделям.

Здесь есть два разных механизма, которые легко спутать. Первый: Cloud Billing budgets и alerts в Google Cloud не являются жёстким стоп-краном. Официальная документация прямо предупреждает, что budget не ограничивает автоматически usage или spending. Он отправляет уведомления, а для автоматических действий нужно отдельно подключать Pub/Sub и свою логику, например отключение биллинга или сервиса. Документация также предупреждает о задержке между использованием ресурсов и отражением затрат в Cloud Billing.

Второй: Google в марте анонсировала Project Spend Caps для Gemini API в Google AI Studio. В том же анонсе компания указала, что у spend caps есть задержка около 10 минут, а пользователи отвечают за превышения, возникшие в этот период. Там же описаны automatic upgrades usage tiers: при росте использования и зрелости платёжной истории система может переводить аккаунт на следующий уровень с более высокими лимитами.

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

Удаление ключа не всегда мгновенно

Самый свежий кусок картины дала Aikido Security. 21 мая 2026 года исследователь Joe Leon опубликовал тесты удаления Google API keys. Методика простая: создать ключ, удалить его, затем отправлять 3-5 аутентифицированных запросов в секунду, пока валидные ответы не прекратятся. По десяти испытаниям за два дня максимальное окно составило почти 23 минуты, минимальное около 8 минут, медиана около 16 минут.

Каждый удалённый ключ не живёт ровно 23 минуты. Aikido подчёркивает непредсказуемость: в одну минуту после удаления в одном испытании проходило 79% запросов, в другом только 5%. Для incident response это плохая новость. Команда не знает, когда именно ключ перестал работать, и не может ускорить распространение отзыва.

Aikido измерила окно отзыва Google API keys: в испытаниях валидные запросы продолжались от 7 минут 49 секунд до 22 минут 38 секунд после удаления. Источник: Aikido Security.

Изначально, по словам Aikido, Google закрыл отчёт как won't fix, считая задержку свойством системы. Но в обновлении от 22 мая Aikido пишет, что Google повторно открыл отчёт и рассматривает его как P0 bug. Это важное уточнение: ситуация движется, но для команд, у которых ключ утёк сегодня, практическая рекомендация остаётся прежней. Удаление надо считать операцией на 30 минут, а не мгновенным выключателем.

Где ломается AI security

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

Старый публичный ключ мог жить в клиентском коде годами, потому что раньше это считалось нормальной практикой для Maps или Firebase.
Включение Gemini API в том же проекте меняет последствия утечки: ключ может стать доступом к дорогому и чувствительному контуру.
Budget alerts предупреждают о расходах, но не всегда останавливают usage в реальном времени.
Spend caps и usage tiers помогают управлять расходами, но тоже имеют задержки и автоматические переходы.
Удаление ключа в UI не обязательно означает, что каждый сервер уже перестал принимать запросы.

Именно поэтому эта тема важнее, чем очередной спор о том, кто виноват в утечке. Для Toolarium это соседняя история к материалу про утечки данных в vibe-coded приложениях: слабое место часто возникает не в модели, а в стыке прототипа, ключей, клиентского кода и облачных настроек.

Что проверить в своих Google Cloud проектах

Если команда использует Google Cloud, Gemini API, Maps, Firebase или старые ключи в клиентском коде, стоит пройти короткую проверку.

Составьте список проектов, где включена Generative Language API или используется Gemini API через AI Studio.
В каждом проекте проверьте все API keys: unrestricted keys, ключи с доступом к Generative Language API и ключи, которые когда-либо попадали в клиентский код.
Разведите публичные и чувствительные сценарии по разным ключам и, лучше, по разным проектам. Gemini, Maps и Firebase не должны случайно делить один старый ключ.
Ограничьте ключи по API и application restrictions. Для серверных сценариев используйте IP restrictions, где это возможно, и не храните ключи в браузере.
Проверьте quotas и rate limits отдельно от budget alerts. Бюджет нужен для видимости, но не заменяет технический лимит.
Подключите бюджетные уведомления к Pub/Sub только если у вас есть протестированное действие: отключить сервис, ключ или биллинг проекта. Само уведомление не спасает.
При утечке удаляйте и ротируйте ключ, но ещё 30 минут следите за Traffic by Credential и enabled APIs. Aikido советует считать это активным окном риска.

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

Сходный принцип действует и в интеграциях с другими ИИ-сервисами. В гайде Toolarium о том, как подключить GPT к Google Sheets, важна не только автоматизация, но и хранение ключей вне расшаренных скриптов и таблиц. А в материале про стратегию Google в ИИ-гонке видно, почему Gemini уже не отдельный чат-бот, а слой платформы. Чем глубже он встроен, тем дороже становится ошибка доступа.

Главное

Google Cloud прав в одном: AI security нельзя оставлять на потом. Но кейс с Gemini API keys показывает, что это требование относится и к самим платформам. Если старые ключи, billing limits и revocation semantics меняют смысл быстрее, чем команды успевают обновить playbook, безопасность ИИ становится не абстрактным board-level риском, а ежедневной инженерной задачей.

Пока Google закрывает часть разрывов, практичный подход для разработчиков такой: считать все ключи чувствительными, не смешивать публичные и дорогие API в одном проекте, не полагаться на budget alerts как на hard cap и проверять, что аварийное удаление ключа действительно сопровождается мониторингом. Иначе следующий инцидент начнётся не с взлома модели, а с давно забытой строки key=AIza... в старом фронтенде.