企业API权限怎么管理，主子账号体系里多团队隔离与调用管控该按什么粒度设计？

企业API权限管理的最小可行结构是主账号、子账号、密钥与配额四层：主账号持有实名主体、账单和密钥签发权，子账号只在被授权的模型、额度和调用场景内活动，密钥按团队或项目独立签发。团队人数少于三人、只跑一个应用、月调用量稳定的情况下，这套分层带来的维护成本会高于它挡住的损失，用一把密钥加消费告警就够了。判断是否需要引入主子账号体系的信号，是出现了第二个业务团队、第二笔需要分别核算的预算，或者出现了不能对全体开发开放的数据。 主账号必须退出日常调用，否则所有分层都会失效。主账号的价值在于它是唯一的责任锚点，充值、开票、密钥签发与吊销、总配额调整、审计日志导出都在这一层完成；一旦主账号密钥被写进代码仓库或被多个团队共享，额度归因和泄漏止损半径会同时失控。落地做法是主账号密钥只在控制台产生、只用于签发子密钥，永远不进入任何运行环境的环境变量。 子账号应该绑定「谁在调用」，而不是绑定「调用了什么」，这是权限模型设计里最容易出错的一步。把子账号对应到自然人或业务负责人，权限才能跟随人员生命周期走，入职开通、转岗调整、离职即停；如果把子账号对应到某个应用或某个功能，人员变动时权限不会跟着变，半年后就会沉淀出一批无人认领却仍能消耗额度的账号。 密钥要按团队、项目、环境三个维度切分，而不是全公司共用一把。生产、测试、预发共用一把密钥时，压测流量会污染生产成本，出问题也无法定位是哪个环境发起；按团队切分则让额度、限速、模型白名单都能跟着团队走，任何一把密钥泄漏，需要吊销和重新分发的范围都被限制在一个团队之内。 配额和限速是比权限列表更硬的边界。权限只决定「能不能调」，配额和限速决定「最多调多少」，按子账号设置日或月额度、并发上限、单次请求的 token 上限，可以在预算被跑穿之前先熔断。缺少这层限制时，一个团队写错循环就能在一个晚上消耗掉整个账号的额度，事后追责也无法挽回已经发生的费用。 模型白名单决定不同团队能用什么档位的模型，是同时管住成本和数据范围的那道闸。客服摘要、标签抽取这类任务不需要最贵的模型，研发实验团队则可能需要更大参数量的模型；把模型清单按团队和场景固定下来，既能防止实验流量挤占生产预算，也能限定哪些团队可以调用处理敏感数据的模型。 密钥轮换要有固定周期和标准动作，否则一次泄漏就会演变成全量停服。可控的做法是每季度或每半年轮换一次，轮换期间新旧两把密钥并行一段时间，业务方在窗口期内完成切换后再吊销旧密钥；如果发现密钥出现在公开仓库或客户端代码里，应当立即吊销而不是等轮换周期，因为调用日志里可能已经留下了无法追溯的痕迹。 调用日志必须落到子账号和密钥级别，否则前面的分层都只是形式。日志至少要记录子账号标识、密钥标识、调用时间、模型名称、输入输出 token 数和调用结果，这样才能支撑三件事：异常用量排查、跨团队成本分摊、以及数据访问范围的事后审计。只记录到主账号级别的日志，出现异常时无法回答「是谁调的」这个最基本的问题。 权限的授予和回收要走固定流程，包括申请、审批、定期复核三道关卡。新团队或新项目申请时写明用途、模型范围、预估额度和使用期限，由主账号管理者审批；每季度复核一次子账号清单，清理已停用项目和离职人员；人员离职或项目结项当天即停用密钥，而不是等下一次复核再处理。 成本分摊口径要在一开始就定下来，否则月末对账时必然出现争议。以子账号或密钥为最小归集单元，按 token 用量把费用摊到团队或项目，账单口径与配额口径保持一致；如果中途把两个团队合并到同一把密钥下，历史数据就无法拆分，内部结算只能靠人工估算，这也是共用密钥最容易被忽视的代价。 有几种做法看起来省事，实际会抵消整套权限设计的效果。把主账号密钥下发给所有开发、全公司共用一把子密钥、只设总额度不设模型白名单、日志只到账号级不到子账号级、离职只删账号不吊销密钥，这几类问题在内部审计里几乎必然被记为高风险项，因为任何一次泄漏都无法界定影响范围。 这套结构的适用边界是「有多个团队或多个预算口径」，不适用的情况要明确说出来。只有一个技术团队、调用量小、没有数据隔离要求时，用共享密钥配合额度告警和用量看板是更划算的选择；等到出现第二个业务方需要单独核算成本，或者某类数据不能对全体开发开放时，再引入子账号与密钥分层。按这个节奏演进，迁移成本远低于一开始就搭一套没人维护的权限矩阵。