Michael JohnsonВнутренняя проверка OpenRouter обнаружила более 1 000 активных API-ключей у 85 сотрудников; 168 ключей, по словам компании, не использовались месяцами. Это цифры самоаудита OpenRouter, а не независимое исследование отрасли. Но даже как частный пример они показывают знакомую инженерную ловушку: ключ можно забыть, а приложение, которое на него полагается, — нет. Компания датировала анонс Security Center 28 сентября 2026 года.
Проблема не сводится к тому, чтобы найти самый старый credential и удалить его. Команде нужно установить владельца, выяснить, где ключ используется, и понять, как заменить его так, чтобы не отключить редкую задачу или забытый сервис. Без этих сведений отзыв доступа превращается из уборки в рискованный эксперимент.
Что видно в Security Center — и чего это не доказывает
По описанию OpenRouter, Security Center объединяет ключи в учетной записи и показывает владельца, последнее использование, лимит расходов и срок действия; администраторы организации видят все ключи, а участники — созданные ими. Для массовых действий можно выбрать до 500 ключей: отключить, архивировать или установить лимит расходов. Отключение обратимо, архивирование — нет. Это характеристики инструмента, изложенные самим поставщиком, а не независимая оценка его эффективности.
Особенно важно читать статус «можно удалить» как подсказку для проверки, а не как доказательство отсутствия зависимостей. Метрика использования показывает прошлые запросы, но не обязательно объясняет, какой крон-задаче, аварийному сценарию или сезонному процессу принадлежит ключ. Сам OpenRouter советует подтвердить удаление у владельца; документация по настройкам безопасности также предупреждает проверить зависимости перед отключением или архивированием.
У сетевых ограничений есть отдельная оговорка: IP allowlist доступен администраторам на Enterprise-плане и применяется ко всем ключам организации. Запросы с адресов вне списка отклоняются с ошибкой 403, а изменения вступают в силу сразу. Поэтому до включения ограничения нужно учесть адреса production-серверов, офисной сети и CI runners; иначе сама мера защиты может прервать легитимные вызовы.
Порядок очистки: сначала владелец, затем отзыв
- Составьте инвентарь. Для каждого ключа зафиксируйте владельца, назначение, среду, потребителей, лимит расходов и срок действия. Если система показывает владельца только как человека, назначьте также команду или сервис, которые примут ответственность при его уходе.
- Проверьте использование и зависимости. Сопоставьте время последнего запроса с расписаниями фоновых задач, резервными сценариями, релизными пайплайнами и внешними интеграциями. Отсутствие недавней активности — причина спросить владельца, а не достаточное основание для немедленного удаления.
- Уменьшите риск до миграции. Где это поддерживается, задайте разумный лимит расходов и срок действия. Сверьтесь с принципом наименьших привилегий и правилами хранения секретов: руководство OWASP по управлению секретами рассматривает учет, доступ и жизненный цикл credentials как отдельные части процесса.
- Создайте замену и перенесите потребителей. Обновите секрет в хранилище или конфигурации развертывания, затем переводите приложения поэтапно. Не вставляйте значение ключа в тикеты, логи или исходный код.
- Проверьте production до отзыва. Убедитесь, что новый ключ работает во всех известных потребителях, включая CI и редкие задачи. Затем сначала отключите старый ключ, если доступна обратимая операция; архивируйте или удаляйте его после подтверждения миграции и принятого периода наблюдения.
Последовательность «создать новый ключ → перевести приложения → проверить работу → удалить старый» совпадает с инструкцией OpenRouter по ротации. Это рекомендуемый порядок, а не гарантия отсутствия простоя: результат зависит от того, нашли ли вы все системы, которые используют credential.
Ключи сервиса — не все секреты организации
Панель конкретного поставщика помогает управлять ключами этого сервиса, но сама по себе не централизует секреты из облака, баз данных, CI/CD и других API. Общая рекомендация OWASP по жизненному циклу секретов охватывает централизованное хранение, контроль доступа, аудит, ротацию и отзыв. А рекомендации Google Cloud отдельно советуют ограничивать область применения ключей, удалять ненужные credentials и отслеживать использование.
OpenRouter также утверждает, что Security Center использует метаданные ключей, расходы и сроки действия, а не читает промпты и ответы. Это заявление самого поставщика; в рассмотренных источниках независимой технической проверки нет. И в целом наличие панели не доказывает, что команда уже сократила число инцидентов или расходы: публичных результатов после запуска в изученных материалах не обнаружено.