帖子说了什么
@livetab_ 提醒在 Claude 前面挂了代理或网关的人：支持 API 版本 2026-10-21 的新 SDK（例如 Python 的 anthropic 2.0.0）和 CLI，会把你的 Key 放在 Authorization: Bearer <key> 里发送，而不再放在 X-Api-Key。在有人升级 SDK 之前，先把读取 X-Api-Key 的中间件、日志过滤和测试桩改掉。
对照官方迁移指南
我们核对了官方的 2026-10-21 迁移指南，它有一节专门讲这件事：
- SDK 和 CLI 改为用
Authorization: Bearer发送 API Key，ANTHROPIC_API_KEY环境变量里的 Key 同样适用。 - Claude API 两种头都接受，所以直接请求官方接口不受影响；受影响的是你自己写的、读
X-Api-Key的代码：代理、网关、中间件、日志过滤、测试桩。 - 开了
--debug时，请求日志里原来显示X-Api-Key的地方，现在显示Authorization: Bearer。 - 不同平台客户端规则不一样，例如 Foundry 客户端仍然用
x-api-key发送，Bedrock Mantle 客户端原本就是 bearer token。 - 一个客户端现在只持有一种凭证，同时传 Key 和 token 的写法在部分 SDK 里会直接报错。
- SDK 跟随重定向到其他来源（包括同一主机从 http 跳到 https）时，会丢掉
Authorization头，Key 也就不会被带过去。
为什么这是安全问题
很多团队的日志脱敏规则是「看到 X-Api-Key 就打码」。头换了名字，规则不跟着改，Key 就会以 Authorization: Bearer sk-ant-... 的形式原样进日志。最近几起 Key 被盗刷的事件，源头都和日志或环境变量外泄有关；日志一旦暴露，别人拿到 Key 就能按你的账单调用。另一头，只认 X-Api-Key 的网关会因为找不到 Key 而拒绝请求，表现为升级后突然全部 401。
落地做法
- 全仓搜一遍
X-Api-Key/x-api-key。 网关、反向代理、中间件、日志脚本、测试桩都要查。 - 日志过滤同时屏蔽
Authorization。 最好整个头都不记录，而不是只打码一部分。 - 网关改为从
Authorization读 Key。 暂时改不了的，迁移指南给了各语言把 Key 放回X-Api-Key的写法，但那只是过渡。 - 先在测试环境升级 SDK。 用
--debug看一次实际发出的头，再上生产。 - 查旧日志。 如果已经有人升级过，翻一下日志里有没有出现
Bearer sk-ant，有就立刻在 Console 吊销并换新 Key。
小结
这次改动不影响直接调用官方接口，但会悄悄改变你自己系统里「Key 在哪个头」的假设。升级 SDK 前，把网关和日志脱敏一起改好。
来源
- @livetab_：新 SDK 用 Authorization: Bearer 发送 API Key
- 官方文档：Migrating to API version 2026-10-21（API keys are sent as Authorization: Bearer）
