Michael JohnsonOpenRouter 的内部检查发现，85 名员工持有 1,000 多个有效 API 密钥；据该公司称，其中 168 个密钥已闲置数月。这些数字来自 OpenRouter 的自查，并非独立的行业研究。但即便只是个别案例，它们也揭示了一个常见的工程陷阱：密钥可能被遗忘，但依赖它的应用不会因此消失。该公司将Security Center 公告的日期标为 2026 年 9 月 28 日。
问题并非找到最旧的凭据并将其删除这么简单。团队需要确认所有者、查明密钥的使用位置，并了解如何替换密钥，避免中断低频任务或被遗忘的服务。缺少这些信息，撤销访问权限就会从整理工作变成一次冒险的试验。
Security Center 能显示什么——又不能证明什么
根据 OpenRouter 的介绍，Security Center 会汇总账户中的密钥，并显示所有者、最近使用时间、支出上限和到期时间；组织管理员可以查看所有密钥，成员则只能查看自己创建的密钥。批量操作最多可选择 500 个密钥：停用、归档或设置支出上限。停用可以撤销，归档则不可逆。这些是供应商对其工具功能的说明，并非对工具有效性的独立评估。
尤其要注意，应将“可以删除”状态视为需要进一步核查的提示，而非不存在依赖关系的证明。使用指标能显示过去的请求，却不一定能说明某个密钥属于哪项定时任务、灾备场景或季节性流程。OpenRouter 自己也建议先向所有者确认；其安全设置文档同样提醒，在停用或归档密钥前检查依赖关系。
网络限制方面还有一项需要注意：IP 允许列表仅向 Enterprise 计划的管理员开放，并适用于组织的所有密钥。来自列表之外地址的请求会被拒绝并返回 403 错误，变更会立即生效。因此，启用限制前，应确认生产服务器、办公网络和 CI runner 的地址；否则，安全措施本身可能中断正常调用。
清理步骤：先确认所有者，再撤销密钥
- 建立清单。记录每个密钥的所有者、用途、环境、使用方、支出上限和到期时间。如果系统只显示个人作为所有者，也应指定负责的团队或服务，以便该员工离职时有人接手。
- 核查使用情况和依赖关系。将最近请求的时间与后台任务计划、灾备场景、发布流水线和外部集成进行比对。近期没有活动，应当成为联系所有者的理由，而不是立即删除密钥的充分依据。
- 在迁移前降低风险。在支持的情况下，设置合理的支出上限和有效期。参考最小权限原则和机密信息存储规则：OWASP 机密信息管理指南将凭据的盘点、访问控制和生命周期视为管理流程中的独立环节。
- 创建替代密钥并迁移使用方。更新密钥库或部署配置中的机密信息，然后分阶段迁移应用。不要将密钥值粘贴到工单、日志或源代码中。
- 撤销前验证生产环境。确认新密钥在所有已知使用方中均能正常工作，包括 CI 和低频任务。然后，如果有可逆操作，先停用旧密钥；确认迁移完成并经过商定的观察期后，再归档或删除旧密钥。
“创建新密钥 → 迁移应用 → 验证运行 → 删除旧密钥”的顺序，与OpenRouter 的密钥轮换指南一致。这是推荐的操作顺序，并不能保证不会停机：结果取决于你是否找全了所有使用该凭据的系统。
服务密钥并非组织的全部机密信息
特定供应商的控制面板有助于管理该服务的密钥，但它本身并不会集中管理云服务、数据库、CI/CD 和其他 API 中的机密信息。OWASP 关于机密信息生命周期的建议涵盖集中存储、访问控制、审计、轮换和撤销。Google Cloud 的建议也单独指出，应限制密钥的适用范围、删除不再需要的凭据并监控其使用情况。
OpenRouter 还表示，Security Center 使用的是密钥元数据、支出和到期时间，而不会读取提示词和回复。这是供应商自己的说法；在所查阅的资料中，没有发现独立的技术验证。总体而言，控制面板的存在并不能证明团队已经减少了事件或开支：在所研究的资料中，也没有找到上线后的公开成果。