Ключ ИИ-провайдера давно не использовали? 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 дней как повод проверить ключ, а не как команду удалить его. Сверьте запись с владельцем, приложением и резервными сценариями; затем подтвердите её необходимость, замените секрет при ротации или удалите после проверки зависимостей. Так журнал помогает находить забытые записи, не ставя под угрозу работающие приложения.