AI API密钥被盗，单家公司损失近百万美元

事件概述

据 Hacker News 上的一则讨论，有公司因 AI API 密钥被盗用，产生了近 100 万美元的账单。该帖子在 Hacker News 上获得了 4 个点数，虽然讨论热度不高，但事件本身暴露出的安全问题值得关注。

Hacker News 原帖截图

从标题信息来看，这是一起典型的 API 密钥泄露导致的经济损失事件。近百万美元的金额并非小数目，对于任何规模的公司来说都是一笔需要严肃对待的支出。

为什么 API 密钥被盗会如此昂贵

AI API 的计费模式通常基于使用量——每次调用、每个 token 都会产生费用。与传统的固定订阅制不同，这种按量计费的方式意味着一旦密钥落入他人之手，攻击者可以在短时间内发起大量请求，费用会像滚雪球一样累积。

更棘手的是，API 密钥往往被硬编码在代码仓库、配置文件或环境变量中，开发者可能无意间将其推送到公开的 GitHub 仓库，或者在不安全的日志中暴露。攻击者一旦获取密钥，就可以在暗网或 Telegram 群组中出售，或者直接自己使用。

按量计费（Usage-based Pricing） 是云服务与 AI API 最主流的计费模型，其核心是按实际消耗的资源单位（如 API 调用次数、输入/输出 token 数、GPU 计算时长）累加收费，而非按月或按席位收取固定费用。这种模式对用户友好——用多少付多少，但也意味着成本与调用量线性甚至指数相关。对于大语言模型 API，token 计费通常区分输入与输出，输出 token 单价往往更高；若攻击者调用的是高参数量的旗舰模型，单次请求成本可能是轻量模型的数十倍。因此，密钥泄露后的损失规模不仅取决于请求数量，还取决于攻击者选择的模型档位与并发强度。理解这一计费逻辑，是评估密钥泄露风险敞口的前提。

密钥泄露的常见途径

从行业内的公开案例来看，API 密钥泄露的途径大致有几类：

代码仓库泄露：开发者将密钥提交到公开仓库，或者 Fork 的仓库中保留了原始密钥。
客户端反编译：移动应用或前端代码中嵌入的密钥被逆向工程提取。
日志与监控系统：密钥被意外记录在日志中，而这些日志的访问权限管理不严。
第三方依赖：使用了不安全的第三方库或服务，导致密钥被窃取。

这些途径的共同点是，泄露往往发生在开发者没有意识到风险的情况下，而非主动的恶意行为。

密钥管理服务（Secrets Management Service） 是专门用于集中存储、分发和审计敏感凭据的系统，典型代表包括 HashiCorp Vault、AWS Secrets Manager、Google Secret Manager 以及 Kubernetes 的 External Secrets Operator 等。与将密钥写入代码或 .env 文件不同，密钥管理服务提供加密存储、细粒度访问控制、自动轮换和访问日志审计等能力。应用在运行时通过身份认证（如 IAM 角色、Service Account）动态拉取密钥，密钥本身不会出现在代码仓库或构建产物中。这类服务还支持短期凭据（如 STS 临时令牌），进一步缩短密钥的有效期，从而在泄露发生时压缩攻击窗口。对于高频调用 AI API 的团队，引入密钥管理服务是从根源上降低泄露概率的关键基础设施。

如何降低此类风险

针对 API 密钥的安全管理，有几条实践值得参考。首先是密钥的轮换机制——定期更换密钥，即使泄露也能将损失窗口控制在有限时间内。其次是使用密钥管理服务，而不是将密钥明文写在代码或配置文件中。

此外，设置用量告警和预算上限是成本控制的最后一道防线。当 API 调用量或费用在短时间内异常飙升时，系统能够自动触发告警甚至暂停服务，避免损失进一步扩大。

对于 AI API 这种高频调用的场景，还需要在架构层面考虑密钥的隔离——不同环境（开发、测试、生产）使用不同的密钥，且权限最小化。这样即使某个环境的密钥泄露，影响范围也有限。

最小权限原则（Principle of Least Privilege） 要求每个密钥、服务账号或身份仅被授予完成其既定任务所必需的最小权限集合。在 AI API 场景中，这意味着开发环境的密钥不应具备生产环境的调用额度，只读用途的密钥不应拥有写入或管理权限，单个微服务的密钥不应能访问全部模型端点。配合按环境隔离的密钥体系（开发、测试、生产各自独立），即使某一环境的密钥泄露，攻击者能造成的损失也被限制在该环境的配额与权限范围内。最小权限原则与密钥轮换、预算告警共同构成纵深防御：前者限制单点泄露的爆炸半径，后者缩短泄露的持续时间并设置成本熔断。

对行业的警示

这起事件虽然只涉及一家公司，但它反映的问题具有普遍性。随着 AI API 在各行各业的应用越来越广泛，API 密钥的安全管理需要被提升到更高的优先级。近百万美元的损失是一个具体的数字，但背后暴露的是整个行业在密钥管理实践上的薄弱环节。

对于使用 AI API 的团队来说，这件事提醒我们：安全不是一次性的配置，而是需要持续关注的流程。从密钥的生成、存储、使用到轮换，每个环节都需要有明确的规范和工具支撑。

供应链安全（Supply Chain Security） 指的是对软件依赖、构建流程和第三方服务全链路的信任管理。现代应用大量依赖开源库、容器镜像和 SaaS 服务，任何一个环节被攻破都可能成为密钥泄露的入口——例如恶意或被劫持的 npm 包在安装脚本中读取环境变量并外传。针对 AI API 密钥，供应链风险还包括第三方 SDK、日志聚合服务和监控代理：它们往往拥有较宽的运行时权限，一旦被植入后门或配置不当，密钥便可能在开发者毫无察觉的情况下流出。因此，密钥安全不能只盯着自家代码仓库，还需要对依赖来源、版本锁定、构建产物的完整性以及第三方服务的访问权限进行系统性审查。