网关治理的第一原则（Sub2API 与 LiteLLM 两边一致）：上游凭据只留在网关里，成员拿到的是平台发的、可单独吊销的 Key。Sub2API 侧是 API Key Distribution（给 users 生成/管理 Key，默认前缀 sk-）；LiteLLM 侧把同一原则做成 Virtual Keys 并明确警告：全队共用一把真 Key，一周内就可能被提交进 GitHub、成本失控、半夜轮换凭据。
适用场景：新成员入职开通、给新项目/脚本/定时任务发调用凭据时。
API Key 分配 一人一Key 可吊销 Virtual Keys
操作步骤
- 以“成员”为单位发 Key；成员名下有独立项目/自动化任务时，再按项目多发一把，不要一人一把走天下。
- 每把 Key 在发放时就限定分组（见条目 2 第 4 步的做法），并登记：持有人、项目、分组、发放日。
- Key 只通过安全渠道交付一次，团队台账只记 Key 的标识/备注名，不记明文。
- 人员变动走条目 12 的回收流程，不靠“改密码”解决 Key 问题。
配置说明
Sub2API 已核验：default.api_key_prefix: "sk-"（config 示例）。借鉴 LiteLLM（明确标注，非 Sub2API 功能）：其 team key（Service Account，只带 team_id）与 user key 的生命周期不同——删用户不会连带删 team key；在 Sub2API 里给“项目”发 Key 时同样要想清楚：这把 Key 的存续跟人不跟项目？要在台账里写明。⚠️ Sub2API Key 是否支持过期时间/IP 白名单等字段，本次只核验到存在 api_key_acl 相关配置，字段级细节未核验，上线前在 LIN 版本后台逐项确认。
注意事项
- ⚠️ 全员共用一把 Key：用量无法归属、泄露无法定位、吊销即全员断服。
- ⚠️ 把上游 OAuth/API Key 直接发给成员绕过网关——等于放弃全部治理。