Ограничение API-ключей Gemini вступило в силу: что нужно проверить командам маршрутизации

С 19 июня 2026 года Gemini API перестал принимать стандартные API-ключи без ограничений. Если ваш routing-слой или gateway проксирует запросы к Gemini через ключ без явных ограничений API, эти вызовы теперь возвращают ошибки. Принудительное ограничение вступило в силу в срок — операторы, пропустившие дедлайн, сегодня сталкиваются с нерабочими production-конвейерами.

Что изменилось

За несколько недель до дедлайна Google разослал всем пользователям Gemini API уведомление «Требуется действие», опубликовал объявление об ограничении на официальном форуме Gemini API и установил жёсткий срок: с 19 июня 2026 года Gemini API прекращает принимать запросы, выполненные с неограниченными стандартными ключами.

«Неограниченным» называется любой ключ, созданный в Google Cloud Console или AI Studio без явных ограничений на уровне API. До 19 июня такие ключи без проблем работали для запросов к Gemini. Теперь они не работают.

Продолжают работать ключи, к которым применено хотя бы одно из следующих ограничений:

• Ограничения API установлены на Gemini API (или конкретное подмножество API).
• Ограничения приложений с разрешёнными referrer-адресами, диапазонами IP или fingerprint-идентификаторами Android/iOS-приложений.

Исправление простое: откройте Google Cloud Console → Учётные данные, найдите все ключи, используемые для запросов к Gemini, и убедитесь, что список ограничений API не пустой. Gemini API и/или Generative Language API должны фигурировать в этом списке.

Почему это важно для маршрутизации к Gemini

Для команд, маршрутизирующих запросы к Google Gemini через любой gateway — будь то self-hosted-прокси, облачная inference-платформа или кастомный routing-слой — API-ключ является общим credential, хранящимся в конфигурации gateway, а не в коде приложения. Это означает следующее:

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

2. Ограничения ключей не наследуются. Если ваш gateway ротирует ключи или использует пул ключей, каждый ключ нужно ограничивать отдельно. Ограничение одного ключа в пуле не защищает остальные.

3. Fallback при маршрутизации может временно скрыть проблему. Если ваша политика routing при ошибках 4xx переключается на другой provider, отказ ключа Gemini может поглощаться незаметно — пока вы не обнаружите, что доля Gemini в маршрутизируемом трафике упала до нуля.

4. Ограничение действует на уровне credential, а не квоты. Это не rate limit. Пополнение кредитов не поможет. Сам ключ должен содержать метаданные ограничения, чтобы пройти через auth-слой Google.

Что нужно проверить

Операторам, маршрутизирующим трафик к Gemini, следует выполнить следующий чеклист:

Шаг 1 — Перечислите все используемые учётные данные Gemini. Запросите в хранилище credentials вашего gateway все ключи, соответствующие маске AIza*. Это стандартные API-ключи Google.

Шаг 2 — Проверьте статус ограничений. Для каждого ключа откройте Google Cloud Console → Учётные данные → страницу сведений о ключе. В разделе «Ограничения API» значение не должно быть «Нет» или «Не ограничивать ключ».

Шаг 3 — Примените ограничения. Если ключ неограничен, добавьте в список API-ограничений Generative Language API (API, лежащий в основе Gemini API). Ограничение вступает в силу немедленно, перезапуск не требуется.

Шаг 4 — Протестируйте. После применения ограничения выполните через этот ключ лёгкий запрос (model: gemini-3.5-flash, минимальное количество токенов) и убедитесь, что получаете ответ 200.

Шаг 5 — Ротируйте. Это принудительное ограничение — также повод провести аудит возраста и области действия ключей. Рассмотрите ротацию всех ключей старше 90 дней и сужение ограничений до конкретной поверхности Gemini API, которую фактически вызывает ваш routing-слой (Generative Language vs Vertex AI vs AI Studio).

Более широкий сигнал об управлении учётными данными

Это принудительное ограничение соответствует общей тенденции у всех крупных provider: ограничения на API credentials становятся всё жёстче, а не мягче. Google начал этот цикл, когда запуск Gemini API превратил ключи Firebase/GCP, прежде безопасные для публичного использования, в инструменты для вызова платных моделей с потреблением квот. Исследовательское сообщество зафиксировало тысячи раскрытых ключей, которые технически были публично безопасными согласно собственным рекомендациям Google по Firebase, но в одночасье стали действующими credentials для Gemini.

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

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

За чем следить

Google пока не объявил о дополнительных мерах в отношении ключей с ограничениями приложений, но без ограничений API, а также ключей, используемых исключительно через endpoint Vertex AI (который использует сервисные аккаунты, а не стандартные API-ключи). Они не затронуты.

Gemini Enterprise Agent Platform, использующая OAuth 2.0 и учётные данные сервисных аккаунтов, не затронута. Это принудительное ограничение применяется исключительно к пути аутентификации через стандартные API-ключи AIza*, используемому AI Studio и прямым Gemini API.

Связанные материалы

• Gemini Enterprise Agent Platform: Memory Bank и Sessions стали общедоступными
• Google Antigravity и Managed Agents меняют Gemini API
• Устаревание Vertex AI Extensions: миграция на Agent Platform
• Документация TheRouter