Давно не использовали ключ ИИ-провайдера? Cloudflare добавила дату последнего использования

Как понять, можно ли удалить давно сохранённый ключ API модели? С 6 ноября 2026 года Cloudflare AI Gateway показывает для сохранённых ключей провайдеров псевдоним, дату последнего использования и дату последнего изменения. В разделе Key security панель выделяет ключи, для которых учтённая активность не фиксировалась более 90 дней. Для команд, управляющих несколькими ключами через шлюз, это конкретный список записей для аудита. При этом история использования ведётся только с ноября 2026 года.

Что именно появилось?

Обновление касается ключей провайдеров, сохранённых в AI Gateway. В объявлении Cloudflare указано, что ключи сгруппированы по провайдерам; рядом отображаются маскированные значения, псевдонимы и даты последнего использования и изменения. Раздел Key security выделяет записи, для которых последняя зафиксированная активность была более 90 дней назад. Cloudflare сообщает, что учёт использования начался в ноябре 2026 года.

Дата последнего использования показывает, когда шлюз в последний раз зафиксировал обращение с помощью ключа. Дата изменения показывает, когда запись обновляли. Маска и псевдоним помогают распознать запись, не раскрывая секретное значение в списке. Это инвентаризация и сигнал для проверки, а не автоматическое решение о судьбе ключа.

Как читать дату активности?

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

Порог в 90 дней относится к активности, зафиксированной системой после начала учёта в ноябре 2026 года. Поэтому отметка не отражает полную историю использования за предыдущие месяцы. Кроме того, редкая задача, резервный маршрут или приложение, обращающееся к провайдеру в обход AI Gateway, требуют отдельной проверки. Например, резервный ключ может месяцами не понадобиться, но оставаться частью плана восстановления.

Документация BYOK описывает хранение ключей в Secrets Store и их использование через AI Gateway. Удаление ключа немедленно остановит запросы, которые от него зависят. Поэтому удалять запись стоит, предварительно выяснив её назначение и зависимости, а не только ориентируясь на возраст отметки.

Как безопасно провести аудит?

1. Начните с отмеченных ключей. Составьте список записей, для которых последняя зафиксированная активность была более 90 дней назад. Пока ничего не удаляйте.
2. Найдите владельца и назначение. Сверьте псевдоним с конфигурациями шлюза и документацией команды; выясните, кто отвечает за приложение. Если назначение неизвестно, сначала установите его.
3. Проверьте, где используется ключ. Уточните, обслуживает ли он редкий отчёт, резервный маршрут или среду вне AI Gateway. Журнал активности шлюза не даёт ответов на эти вопросы.
4. Если ключ нужен, подготовьте ротацию. Создайте новый ключ у провайдера и замените секрет в существующей записи AI Gateway. Согласно документации, приложения продолжат использовать обновлённый ключ через ту же запись; после замены проверьте работу реальных запросов.
5. Удаляйте после проверки зависимостей. Убедитесь, что приложения переключены на другой ключ или прежний выведен из эксплуатации. При удалении ключа зависящие от него запросы прекратятся.

Представим, что команда обнаружила ключ, активность которого не фиксировалась более 90 дней. Владелец выясняет, что запись использовалась в тестовой среде, а тесты уже переключены на другой ключ. После проверки конфигурации её можно удалить. Если ключ нужен как резерв на случай отказа основного провайдера, следует зафиксировать его назначение и владельца и сохранить запись.

Что это меняет для команды?

Вместо общего напоминания «проверьте старые ключи» команда получает дату последней зафиксированной активности каждой записи. Это помогает решить, с чего начать ревизию доступа, особенно если через AI Gateway управляют ключами нескольких провайдеров.

Используйте отметку о более чем 90 днях без активности как повод проверить ключ, а не как команду удалить его. Сверьте запись с владельцем, приложением и резервными сценариями; затем подтвердите необходимость ключа, замените секрет при ротации или удалите запись после проверки зависимостей. Так журнал помогает находить забытые записи, не подвергая риску работающие приложения.