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

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

Это происходит примерно через семь недель после того, как Anthropic сделала дату истечения обязательной при создании ключей. Механика у них разная: Anthropic требует заполнить поле expiry при создании, OpenAI устанавливает потолок. Но направление одинаковое — оба крупнейших провайдера теперь делают ротацию ключей требованием политики, а не рекомендацией.

Как работает принуждение: лимит организации ограничивает лимит проекта

Настройка находится в Platform settings. Как только администратор организации задаёт максимальный срок действия, каждый новый project API key должен истекать в пределах этого потолка. Проектные лимиты могут быть строже организационного, но не мягче. Если организация установила 90 дней, ни один проект не может выдать ключ на 180 дней.

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

Операционный смысл: если вы установили организационный максимум сегодня, все ключи, созданные командой завтра, будут соответствовать требованиям. Но долгоживущие ключи, уже находящиеся в Kubernetes secrets, переменных окружения CI или конфигурации шлюза, остаются нетронутыми. Их нужно найти и заменить вручную.

Что унаследуют существующие ключи — и что не изменится

Три сценария, которые стоит назвать явно.

Ключ без даты истечения, созданный до введения политики — по-прежнему действует бессрочно. Ничего не изменилось. Платформа не пометит его как несоответствующий и не откажет ему.

Ключ с датой истечения, превышающей новый организационный максимум, созданный до введения политики — тоже по-прежнему действителен до своей оригинальной даты. Организационный потолок не укорачивает его задним числом.

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

Практическое окно риска: организации, которые установят максимум сегодня, окажутся в смешанном состоянии — новые ключи ограничены, старые нет. Именно это расщепление требует аудита, а не сама политика.

Anthropic против OpenAI: две разные модели принуждения

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

Подход Anthropic, введённый в июле: дата истечения обязательна при создании ключа. Никакого организационного потолка настраивать не нужно — требование безусловное. Каждый новый ключ Anthropic должен иметь явную дату истечения; бессрочный ключ создать невозможно.

Подход OpenAI зависит от конфигурации администратора. Если администратор организации не установил максимум, дата истечения при создании ключей по-прежнему опциональна. Принуждение активируется только тогда, когда администратор явно включает политику. Организации, не трогавшие эту настройку, сегодня не затронуты автоматически.

Это различие важно при написании автоматизации управления ключами для multi-provider шлюза. Интеграция с Anthropic всегда должна передавать дату истечения. Интеграция с OpenAI может и не требовать этого — в зависимости от того, настроил ли администратор вашей организации потолок. Если вы пишете общий инструмент выдачи ключей для routing gateway, нужно запрашивать настройки организации перед тем, как считать, что OpenAI ведёт себя так же, как Anthropic.

Оба провайдера движутся в одном направлении: ротация ключей становится инфраструктурой, а не рекомендацией.

Шлюз — наиболее рискованная точка в вашем инвентаре ключей

Большинство AI шлюзов аутентифицируются у upstream-провайдеров с помощью небольшого числа долгоживущих API-ключей, а не краткосрочных credentials. Эти ключи обычно хранятся в переменных окружения, Kubernetes secrets или менеджере секретов — и зачастую оказываются вне тех практик ротации, которые применяются к IAM-ролям или OAuth-токенам, потому что ни один из провайдеров до недавнего времени не требовал ротации.

Структурная проблема: ключ шлюза используется повторно для каждого запроса, проксируемого к провайдеру. Утечка одного такого ключа раскрывает весь трафик, проходящий через него, а не только запросы одного пользователя или сервиса. Gateway-ключи ценны и при этом нередко получают меньше внимания с точки зрения ротации именно потому, что являются общей инфраструктурой.

Три наиболее рискованных паттерна в инвентаре ключей.

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

Ключи, зашитые в конфигурационные файлы в системе контроля версий — характерно для infrastructure-as-code сценариев, где ключ меняется через обновление ссылки на секрет, но история коммитов сохраняет предыдущее значение.

Ключи, разделённые между несколькими сервисами или окружениями — gateway-ключ, используемый одновременно в staging и production, невозможно ротировать по-отдельности без синхронного обновления обоих окружений.

Чеклист аудита для операторов

Шаг 1: инвентаризация существующих ключей. В Platform settings → API keys просмотрите или экспортируйте все активные ключи. Отметьте те, у которых нет даты истечения, и дату создания каждого. Это ваш остаточный риск — ключи, созданные до введения политики.

Шаг 2: включите организационное принуждение, если ещё не сделали. Определите максимальный срок действия, подходящий для вашего цикла ротации — 30, 60 или 90 дней. Это не затронет существующие ключи, но предотвратит создание новых бессрочных.

Шаг 3: в первую очередь ротируйте долгоживущие gateway-ключи. Новые ключи будут соответствовать требованиям автоматически. Старые требуют ручных действий: создайте замену, обновите конфигурацию в шлюзе и всех сервисах, использующих ключ, убедитесь в корректности трафика, затем отзовите старый ключ.

Шаг 4: обновите автоматизацию выдачи ключей. Любой инструмент, создающий OpenAI-ключи программно — Terraform provider, кастомные provisioning-скрипты, CI/CD onboarding — должен передавать дату истечения, иначе после установки организационного максимума начнут появляться ошибки.

Шаг 5: согласуйте с политикой ротации Anthropic. Anthropic уже требует дату истечения безусловно. Если у вас есть цикл ротации для ключей Anthropic, распространите его на ключи OpenAI и установите организационный максимум, соответствующий этому циклу.

Оба провайдера теперь ожидают, что ротация ключей войдёт в операционный baseline, а не будет периодической уборкой. Команды, которые относятся к управлению ключами как к инфраструктуре — автоматизированная выдача, плановая ротация, мониторинг истечения — не увидят изменений в работе. Командам, полагающимся на бессрочные ключи, нужно выстроить эту автоматизацию до того, как истекут первые новые ключи.

Актуальные детали политики и управление ключами доступны в руководстве по production best practices. В документации TheRouter описана настройка credentials провайдеров в routing gateway для команд, управляющих ключами нескольких upstream-провайдеров.