一次阿里云百炼异常扣费的排查和修复总结

一、被一笔“意外账单”敲响的警钟

说实话，最近手头这个My-Notion项目遇到了一次阿里云账户欠费的问题，心里多少有点不是滋味。

一开始看到账户欠费时，第一反应就是：是不是哪个AI功能调用量太大，或者RAG、Embedding这些在后台跑个不停？

排查的过程并不算复杂，但问题本身的属性确实让人警觉。

账单里真正产生费用的，是阿里云百炼的大模型推理服务，而且模型调用集中在很短的时间窗口内，主要是 glm-5.2 的文本 token 消耗。结合项目代码和本地环境来看，更倾向于判断：这是一次 API Key 明文暴露后导致的异常调用。

严格来说，现有证据不足以百分之百证明是谁拿到了 Key，也不足以直接锁定攻击来源。但光是账单行为、模型名称、调用时间和项目配置，就已经足够说明一个事实：密钥管理和模型调用入口，必须收紧防线。

这篇文章就把这次问题从定位、修复到后续防控的全过程记录下来，既是复盘，也是一次技术上的必要提醒。

一、问题现象

阿里云费用中心显示账户欠费。

进一步查看账单后，费用来源基本排除了 OSS、ECS 这类基础资源。真正的蹊跷来自这里：

产品：大模型服务平台百炼
商品：百炼大模型推理
计费项：大模型文本消耗量
模型：glm-5.2
单位：千 tokens

非零的账单主要集中在一个很短的调用时间窗口里：

input_token_cache
input_token
output_token

金额本身不算大，但这类型的问题，重点从来不是这一次扣了多少钱。而是：如果 API Key 泄露后没有及时发现，后续的费用可能被无限放大。这才是最让人揪心的点。

二、初步判断：疑似 API Key 明文暴露

这次账单里的模型是 glm-5.2。

而项目当时的主线模型配置本不应该直接使用它。Web 和 Mobile 的常规路径都有自己的模型列表，正常情况下不应该随便把任意模型 ID 透传到 DashScope。

但排查代码时发现，有两个风险点确实存在。

第一个风险点，是模型解析逻辑过于宽松。当请求体传入一个不在本地枚举里的模型时，旧逻辑会直接原样返回：

return model;

这意味着，只要某个入口收到了 glm-5.2，服务端就可能直接把它转发给 DashScope，完全不经过任何验证。

第二个风险点，是 services/ai 这个独立 AI 服务仍然存在本地环境文件，并且历史上它的设计更像一个独立推理网关。如果这个服务被误部署、误启动，或者 API Key 出现在 AI 对话上下文、日志、截图、本地文件同步这些地方，都有可能导致泄露。

所以最终判断是：最可能的问题不是 My-Notion 主线业务主动消耗了大量 token，而是 API Key 明文暴露后，被外部或非预期调用链路利用。

这个判断虽然还不足以完成完整的攻击溯源，但已经足够指导修复动作了。

三、立即处置：先止血

第一步动作非常直接：换掉阿里云 API Key。

只要怀疑 Key 泄露，就不该再分析半天再决定是否更换。密钥一旦暴露，就默认它已经不可控。这个原则必须坚持。

这次的处理顺序是：

1. 轮换 DashScope / 百炼 API Key。
2. 排查阿里云费用中心，确认费用来源。
3. 检查项目里所有 AI 调用入口。
4. 收紧模型白名单。
5. 收紧独立 AI 服务鉴权。
6. 验证 Web、Mobile、CLI、MCP 主链路。

换 Key 只能止血，不能解决工程层面的深层次问题。真正的修复必须让类似问题在以后更难发生。

四、核心修复：模型调用必须 fail closed

这次最关键的代码修复，是模型白名单机制。

现在项目的模型配置只允许这几个模型：

kimi-k2.7-code
qwen3.7-max-2026-06-08
qwen3.7-plus
qwen3.7-plus-2026-05-26

默认模型是：

kimi-k2.7-code

旧逻辑是，未知模型也可能被原样透传。新逻辑改成了：只接受白名单模型。不在白名单内，直接返回 400 错误。不再透传任何未知模型到上游。

这个变化非常关键。

AI 模型调用不是普通的参数透传。模型 ID 直接决定了计费对象、单价、token 行为以及功能能力。它必须像权限 scope 一样被服务端严格控制，而不是完全信任客户端请求体。

换句话说：前端可以选择模型，但服务端必须决定哪些模型真的允许被调用。

五、独立 AI 服务也加了防护

项目里还有一个 services/ai 目录。

现在 Mobile 主线已经切换到 Web 路由：

Mobile -> Web /api/agent/stream

旧的 /api/chat、/api/rag 也只是作为兼容性的 fallback 存在。并且当前 Mobile 配置同样指向 Web 站点，不是独立的 services/ai。

也就是说，services/ai 目前不是主线服务，更像一个备用部署方案。

但只要它还在仓库里，就不能让它处于一个容易被误用的状态。所以这次也给 services/ai 加了几层防护：

• 增加了 AI_SERVICE_AUTH_TOKEN。
• 未配置 token 时，非 health 请求直接拒绝。
• 请求必须带 Bearer token。
• 增加了基础限流。
• 同样复用模型白名单，不允许任意模型 ID 透传。

这不是在鼓励继续部署独立 AI 服务，而是防止它作为备用路径时，变成新的风险入口。

如果未来确认不再需要 services/ai，更彻底的做法是直接删除这个目录，同时清理 Fly.io 文档、workspace 配置和相关脚本。

六、验证结果

修复完成后做了几类验证。

AI / Web / Mobile / AI Service：

@notion/ai typecheck
@notion/web typecheck
@notion/mobile typecheck
@notion/ai-service typecheck
@notion/web build
@notion/ai-service build

CLI / MCP：

@mynotion/cli typecheck
@mynotion/mcp typecheck
@mynotion/cli test
@mynotion/mcp test
@mynotion/cli build
@mynotion/mcp build

真实链路 E2E：

pnpm e2e:cli
pnpm e2e:mcp
pnpm e2e:mcp:client

其中 CLI E2E 还顺手暴露了一个小问题：CLI 的 prod endpoint 被设计成固定线上，不应该因为本地保存配置而自动切换。E2E 里临时 PAT 对应的是测试 Machine API，所以脚本必须显式指定测试 API URL。这一项也已经修掉。

最终结果很清晰：

• Web 构建通过。
• Mobile 类型检查通过。
• AI service 类型检查和构建通过。
• CLI/MCP 包测试通过。
• CLI 真实 create/fetch/update/search/export/import/archive/revoke/logout 链路通过。
• MCP STDIO 和真实 MCP SDK Client 调用链路通过。

七、这次的教训

这次问题让我重新确认了几条工程上的基本原则。

第一，API Key 不能出现在任何会被复制、同步、上传、截图、喂给 AI 的地方。

本地 .env 文件虽然通常不会提交到仓库，但它仍然是高风险文件。如果把完整的 key 贴进 AI 对话、日志、Issue、文档、截图，这风险和提交到仓库没有本质区别。

第二，LLM 网关必须有服务端白名单。

模型 ID、base URL、工具能力、是否启用联网、是否启用代码解释器，这些都不应该完全由客户端单方面决定。

第三，备用服务也要有默认的安全状态。

一个“不在主线使用”的服务，如果还保留着部署配置和启动脚本，就仍然是攻击面。它要么被直接删除，要么在默认情况下拒绝所有未授权请求。

第四，费用告警必须做。

代码防护只能降低风险，并不能替代云平台侧的消费额度、预算告警和异常调用监控。尤其是大模型调用，token 消耗非常容易在短时间内被迅速放大。

八、后续计划

这次已经完成了止血和主链路修复。

后续还会继续完成几件事：

• 删除本地不再需要的明文 key 文件。
• 评估是否彻底移除 services/ai。
• 在阿里云侧设置百炼消费告警和额度限制。
• 检查历史文档、博客草稿、进度记录里是否出现过敏感 key。
• 保持 AI 调用入口的白名单策略，避免再次回到任意模型透传的状态。

这次问题的金额虽然不大，但它用最直接的方式提醒了所有做 AI 工程的人：安全问题很多时候根本不是复杂攻击，而是一个 key、一个默认开放的接口、一个过于宽松的透传逻辑。

修复这个问题不只是换一个 API Key，而是把整个调用链路改成了更可控的形态：

密钥轮换 → 模型白名单 → 服务端鉴权 → 基础限流 → 真实链路验证 → 云平台费用告警

对于任何一个 AI Native 项目来说，能跑通模型调用只是第一步。真正重要的是：当模型调用涉及真实费用、真实数据和真实用户时，系统必须默认保守、边界清晰、且时刻可验证。