OpenAI 现在在组织层面强制 API Key 过期：网关运营者今天必须审计的事项

9 月 10 日，OpenAI 为 API Key 上线了组织层面和项目层面的过期强制策略。单个 Key 的过期日期以前就可以设置，但新的是强制执行这件事。组织管理员现在可以设置一个最大有效期上限，策略生效后创建的所有 Key 都必须在这个上限内到期。Key 不能在没有过期日期的情况下创建，项目层面的限制也不能超过组织层面的上限。

这距离 Anthropic 把过期日期变成必填项大约过了七周。两家公司的机制不同。Anthropic 在创建时就要求填写过期字段，OpenAI 设置的是一个天花板。方向一致，两家头部 provider 现在都把 Key 轮换变成了强制策略，而不只是建议实践。

强制机制如何运作：组织上限限制项目上限

这个设置在 Platform settings 里。组织管理员一旦设置了最大有效期，项目 API Key 创建时就必须带上在该上限内的过期日期。项目层面可以收紧这个上限，但不能放宽。如果组织设置了 90 天，任何项目都不能签发一个活 180 天的 Key。

强制是前向生效的。OpenAI 没有追溯缩短已有的 Key。策略生效前创建的 Key 保留原有的过期日期，如果当初没设，就依然永久有效。策略只对新建 Key 有约束。

如果你今天设置了组织层面的上限，明天团队创建的替换 Key 都会合规，但已经放在 Kubernetes secret、CI 环境变量或网关配置文件里的老 Key 不受影响，需要你自己找到并轮换。

已有 Key 实际会继承什么，哪些不会改变

三种情形需要明确说清楚。

策略生效前创建的、没有过期日期的 Key 依然永久有效，不会有任何变化。平台 dashboard 不会把它标记成不合规，也不会拒绝它。

策略生效前创建的、过期日期超出新组织上限的 Key 同样依然有效，活到原来的过期日期。组织上限不会追溯缩短它。

策略生效后创建的 Key 必须在组织上限内到期。没有设置过期日期、或过期日期超出上限的创建请求会返回错误。

实际风险窗口在于这个混合状态。今天设置上限的组织，新 Key 有约束，老 Key 没有。需要审计的是这批老 Key，策略本身并不是问题。

Anthropic vs OpenAI：两种不同的强制模型

如果你的网关同时代理两家 provider 的请求，现在需要维护两套工作方式不同的 Key 轮换要求。

Anthropic 在七月引入的方式是在创建时就要求填写过期日期，没有什么组织上限需要配置，要求是无条件的，不管管理员有没有设置什么。任何新的 Anthropic Key 都必须带上明确的过期日期，不存在永久有效的 Key。

OpenAI 的方式依赖于管理员是否配置。如果组织管理员没有设置上限，新 Key 的过期日期仍然是可选的。强制只在管理员明确启用策略之后才生效。今天还没碰过这个设置的组织不会自动受到影响。

这个差异在跨 provider Key 管理自动化里很重要。Anthropic 集成必须始终传过期日期。OpenAI 集成可能需要也可能不需要，取决于你的组织管理员有没有配置上限。如果你在为多 provider 网关编写共用的 Key 签发工具，在写 OpenAI 那条逻辑时需要先查一下组织设置，不能直接假设它和 Anthropic 行为一致。

两家 provider 的方向一致，Key 轮换正在从最佳实践建议变成基础设施层面的强制要求。

网关是你的 Key 库里风险最高的位置

大多数 AI 网关在向上游 provider 认证时，使用的是少数几个长寿命 API Key，而不是短期凭据。这些 Key 通常放在环境变量、Kubernetes secret 或 secrets manager 里，而且往往没有套上应用于 IAM 角色或 OAuth token 的那套轮换规程，因为在过期强制到来之前，两家 provider 都不要求这样做。

结构性问题在于复用。网关 Key 被所有通过该网关转发的请求复用，一旦泄露，暴露的是全部流量，不只是某个用户或某个服务的请求。网关 Key 价值高，却常常因为是共享基础设施而受到较少的轮换关注。

Key 库里三种最高风险的模式。

过期策略出现之前创建的 Key。 这些 Key 没有过期日期，除非手动撤销和轮换，否则永久有效。

提交到版本控制配置文件里的 Key。 在 infrastructure-as-code 场景里很常见，Key 通过更新 secret 引用来轮换，但提交历史里保留着旧值。

跨服务或跨环境共享的 Key。 同一个网关 Key 同时用于 staging 和生产时，轮换必须同步更新两处，漏掉任何一处都会导致某个环境停留在旧 Key 上。

运营者审计清单

第一步，清点已有 Key。 在 Platform settings → API keys 里导出或查看所有活跃 Key，记录哪些没有过期日期，以及各自的创建时间。这些策略生效前的 Key 是你的残留风险。

第二步，如果还没有，启用组织层面强制策略。 根据你的轮换节奏确定一个合适的最大有效期，30 天、60 天或 90 天都是常见选择。设置这个不影响已有 Key，但能防止新 Key 变成永久有效。

第三步，优先轮换长寿命网关 Key。 新 Key 会自动合规，老 Key 需要手动操作，具体来说是新建替换 Key、更新网关和所有共用该 Key 的服务里的配置、验证流量正常，然后撤销旧 Key。

第四步，更新 Key 签发自动化。 任何自动创建 OpenAI Key 的工具，包括 Terraform provider、自定义 provisioning 脚本、CI/CD 入职流程，在组织上限设置后都需要传入过期日期，否则会开始报错。

第五步，与 Anthropic 轮换策略对齐。 Anthropic 已经无条件要求过期日期。如果你已经有 Anthropic Key 的轮换周期，把同样的周期推广到 OpenAI Key，并把组织上限设置成与之匹配。

两家 provider 现在都期待 Key 轮换成为运营基线，而不是周期性清理任务。把 Key 管理当基础设施来运营的团队，做到自动签发、定期轮换、监控过期，不需要改什么。依赖永久有效 Key 的团队需要在第一批新 Key 到期之前，把这套自动化建起来或引入进来。

强制策略详情和 Key 管理 dashboard 参见 OpenAI 生产最佳实践指南。TheRouter 的文档介绍了如何在路由网关里为管理多个上游 provider Key 的团队配置 provider 凭据。