把 Key 交给第三方之前的权限收敛清单

把 API Key 填进第三方工具，本质上是把调用能力外包出去。降低风险的办法不是逐家审查，而是把 Key 本身的破坏力限制住。

第一条是专用。为每个场景单独签发 Key：生产业务一把、内部工具一把、临时验证一把。这样出问题时能精确定位到某一环，也便于单独吊销而不影响其他系统。共用一把 Key 的团队，一旦泄漏只能全量停摆。

第二条是限额。多数平台支持给 Key 设置每日或总额度上限。即使 Key 泄漏，损失也有上限。这个设置通常被忽略，但它是成本最低的一道防线。

第三条是可撤销与可轮换。签发时记录 Key 的创建时间与用途，设置季度轮换。轮换期间用新旧双 Key 并行一周，确认没有遗漏的调用方再吊销旧的。没有轮换机制的系统，往往在真正需要撤销时才发现没人知道这把 Key 被哪些服务引用。

第四条是传输方式。Key 只应出现在请求头，不应出现在 URL 查询参数里。URL 会进入代理日志、浏览器历史与错误上报，一次误配就相当于公开。客户端侧用环境变量或密钥管理服务注入，不要硬编码进前端代码。

第五条是本地排查。把 Key 交给检测工具时，优先用临时 Key，并在完成后立即吊销。正规工具会说明 Key 是否落盘、是否进入日志、保留多久；说不清这几点，就不要用生产 Key。

把这五条写成接入规范，比在事故后复盘更有效。团队越大，越需要把 Key 当作一次性凭证管理，而不是长期资产。

补充一个常见疏漏：把 Key 写进 CI 变量但忘记限制分支权限，任何能提 PR 的人都能通过流水线打印出变量。CI 侧的密钥应当只对受保护分支可见，且日志要过滤敏感字段。这类问题的修复成本很低，但需要有人在接入时想到。