密钥交给工具托管那一刻：归属、轮换与爆炸半径要重新写清
一、托管改变的不是有没有风险，而是风险归谁、怎么计量
据公开报道，一款编程智能体的在线服务被曝发生安全事件，部分通过它托管第三方大模型接口密钥的用户受到影响，密钥层面存疑。来源只给到受影响范围这一层，泄露原因、波及规模与厂商处置过程都不在本次讨论之内，我们也不做推测。
值得单独写下来的是这类结构本身。团队把各家大模型的密钥交给一个在线工具代管，收益直白：不必给每人配一份，不必处理各自的报销与额度，新人开箱就能用。代价不在方便性上，而在两个计量口径被同时换掉了。
第一个口径是归属。密钥在自己手里时，它是公司的资产，出问题由公司吊销；交给别人代持之后，这把密钥的存在形式、存储位置、被谁能读到，都变成对方系统里的一件事，公司只剩下一条查询不到细节的账单。第二个口径是单位。自管时的最坏情况是一把 key 泄露，影响的是一个账号名下的额度；托管后的最坏情况是一批 key 连着调用日志一起出去，因为对方要转发请求，就要同时持有密钥、看到请求内容、留下路由记录。泄露面从某个员工的笔记本，变成那个工具的库。这不是风险变大了或变小了，是风险的形状变了，而多数团队在同意服务条款时并没有意识到单位已经换掉。
二、两种形态要先分清：自管转发与平台代持
同样的接入体验背后可能是完全不同的实现。讨论条款之前先做形态判定，判据只看四件事。
| 判定项 | 本地自管，只把请求发出去 | 平台代持并转发 |
|---|---|---|
| 密钥存储位置 | 自己的配置中心或员工本机，加密由自己控制 | 对方服务端存储，加密方式与主密钥归属由对方定义 |
| 是否代持身份 | 否，调用方标识始终是自己的账号 | 是，对方以自己的方式持有多家密钥，甚至与别人共用 |
| 能否看到提示词与响应 | 理论上只经过传输层，数据去向由自己决定 | 对方为完成转发必须见到请求体，是否留存取决于其条款 |
| 审计落在哪一侧 | 全部在自己系统，吊销即时生效 | 一半在对方日志里，自己看不到完整链路 |
中间态还有第三种：对方只做密钥库，转发仍由本地客户端完成。这种形态比完整代持好一档，因为流量不经它的手，但它仍然持有凭据，泄露后果与自管不同。判定时不要把托管密钥和托管调用混为一谈，两者的处置流程差别很大。
三、允许团队使用之前必须问清的六项
这六项不是道德问卷，每一项都要有能写进合同的答复。对方拒绝回答或回答含糊，本身就是结论。
| 要问的六项 | 可接受的答复形态 | 拒答意味着什么 |
|---|---|---|
| 密钥如何加密存储，主密钥归谁 | 说明加密层级与主密钥是否在对方可及范围内 | 无法评估内部人员与越权的暴露面 |
| 员工离职或整体退订后密钥是否立即删除，如何证明 | 给出删除动作、时限与可核对的回执 | 撤不回，吊销要靠自己逐家操作 |
| 调用日志的保留期与可见范围 | 明确保留多久、谁能查、能否关闭留存 | 提示词在对方系统里长期可读 |
| 是否将调用数据用于训练或改进模型 | 有明确选项且默认关闭，能逐项设置 | 数据用途不在自己手里 |
| 泄露事件的告知时限与方式 | 写进条款的时限与联系人，而非仅原则承诺 | 发现自己被波及的时间不可控 |
| 能否只做转发而不代持，由客户自持密钥 | 支持自持凭据直连的配置路径 | 只能接受代持，风险单位无法缩小 |
第六项最容易被忽略，它其实决定了能不能把上面五种风险整体绕开。如果一家工具不支持客户自持凭据直连，那它给团队的便利就要用风险单位去换，这时审批的意义才真正出现。
四、爆炸半径要按业务折算，不要按密钥数量数
评估一把被托管的 key 值多少钱，不能只看账户余额，也不能只数它有几把。可用的算法是三步。第一步列覆盖：这把密钥能开启哪些能力，哪些能力被多少个业务在用，是否有业务把它当作唯一的模型出口。一把 key 同时供生产客服、内部工单摘要和一份夜间批处理时，出事就是三处同时降级。第二步算窗口：从异常发生到自己发现，中间有多长。发现窗口取决于监控，而不是取决于运气，没监控时这个窗口通常要按天算。第三步折损：按该账号的日消耗量与额度上限折算，把最坏损失分两类写清楚，一类是额度被消耗掉的直接损失，另一类是被迫中断的交付与需要重建的信任。前者能用钱表示，后者不能，但两类都要出现在评估结论里，否则很容易被只写前者。
同一套折算做完，会得到一个有用的排序：真正需要盯的不是那把最贵的密钥，而是覆盖业务最多、发现窗口最长、又不在自己手里的那把。这三条同时命中的，往往就是团队为了省事接进来的那一个统一入口。
五、轮换在两种形态下的成本完全不同
自管形态下的轮换是一条配置变更：新 key 生成、旧 key 保留双活一段时间、灰度切流、确认无残留调用后吊销。整个过程在自己手里，可以随时提级处理。
代持形态下要复杂一层。旧 key 在对方系统里被引用，客户侧吊销之后对方是否还在使用、什么时候替换成新的，全依赖对方的流程；而自己这边要完成两件事，一是在对方工具里删除并重新录入，二是在新 key 生效期间保证不出现调用中断，因此新旧必须短暂共存。这个共存窗口就是最容易出事故的时段：一边已经吊销、一边还在用旧凭据重试，表面看是接口突然报错，实际是两处状态没对齐。做法上要有明确顺序，先让新的可用、再切流、确认对方侧引用已更新、最后吊销旧的，并把每步的时间与执行人记进变更单。
无论哪种形态，被托管的密钥都要设独立额度与独立告警，不与主账号共用，这样吊销的影响面才可控。
六、该看什么监控，以及怎么定默认策略
监控项不要只看调用量。真正能提前给出信号的是三类：一是非预期来源的调用，比如出现新的出口地址、新的客户端标识或从未用过的接口路径；二是按调用方拆开的增长，把总量按业务、按人、按接入形态分别看，合并的曲线会把异常抹平；三是权限范围外的模型被调用，团队只开通了两种模型，却出现第三种模型的请求，这一条几乎不可能是正常业务。发现异常后的第一动作应当是吊销而不是排查，排查在吊销之后做，这是被托管形态和自管形态最大的操作差异。
还有一处容易漏：使用面的治理。团队里谁能接入新的托管入口，应当和谁能开银行卡放在同一级审批上，而不是由个人在本地试装。已经接入的入口要进资产台账，字段最少包括工具名称、接入形态（自管还是代持）、覆盖的模型与业务、密钥归属、轮换责任人、最后一次确认条款的日期。台账的作用在人员变动时才显现：负责接这个工具的人离开时，如果表里没有代持密钥这一格，那把密钥事实上就失去了归属，直到某天账单异常才被重新发现。
策略上，洹拓科技在给客户做接入评审时用的默认线很简单：允许自管加转发，代托管列入需审批项。审批要看四样东西，逐条对着第三节那张表核：那六项答复有没有落到条款里、爆炸半径评估表填没填完、轮换由谁执行、发生事件时对方通知到我们这边的哪一个人。四样里有任何一样答不上来，就先不接，等它答全再走一次评审。便利确实要还债，只是不该由员工个人来还。