AI 智能体烧钱有多快？一个凭证泄露，1 天烧掉 14000 美元
摘要：一家三人公司的 AWS 月账单仅 10-15 美元，但因一个泄露的访问密钥被攻击者疯狂调用 Claude 大模型，单日产生 14000 美元费用。这类事件并非孤例，AI 智能体调用云服务的速度远超传统账单风控的响应延迟。本文通过两起真实案例，剖析了“自动化消费 vs 人工慢响应”的结构性错配，并给出前置防护建议。
一个密钥泄露，一天烧掉 1.4 万美元
一家只有三名员工的公司，平时 AWS 月度账单不过 10 到 15 美元。有一天，攻击者从一个 EC2 实例中偷到了静态访问密钥，然后疯狂调用亚马逊 Bedrock 平台上的 Claude 大模型——结果仅一天时间，就产生了 14000 美元的扣费。
这件事由 AWS 顾问 Tobias Schmidt 在 LinkedIn 上披露。问题出在两个默认配置上：
- 该访问密钥拥有 Bedrock 的完全访问权限。
- AWS 在 2025 年移除了模型访问开关，默认启用所有模型。
原本这个应用只调用 Haiku 模型，预估账单不到 100 美元。但攻击者拿到密钥后，直接调用更贵的模型，费用瞬间飙升。
35 小时后才发现，信用卡已被刷掉 6531 美元
类似的事件不止一起。另一位网络工程师 Lan Tian 记录了一起更详细的案例，并在 Hacker News 上引发热议。
一名运维人员给一个自主智能体授予了完整的 AWS 访问权限，并让它扫描一个名为 DN42 的业余 BGP 网络（多数节点运行在廉价 VPS 上）。智能体自己“评估”后认为，这项工作需要五台 m8g.12xlarge 实例（每台 48 核、22.5 Gbps 带宽），外加负载均衡器和 Lambda 函数，目标是实现“20 Gbps 扫描速率，同时具备冗余与故障转移”。然后它反复用 CloudFormation 模板创建资源，不断复制整个栈。
等运维人员发现异常时，已经过去了 35 个小时。此时信用卡已被扣款 6531.30 美元。事后经协商，AWS 将账单减免到 1894 美元。而实际上，这项扫描任务只需一台月租 5 美元的虚拟服务器就能完成。
为何账单告警总是慢半拍？
两起事件的共同点是：用户都是从信用卡扣款记录才察觉异常，而不是通过 AWS 的告警。
为什么？因为 AWS 的计费系统（Cost Explorer）数据滞后长达 24 小时。而预算工具（AWS Budgets）基于这套滞后数据做校验，所以只有当费用已经产生了，拦截措施才会触发。说白了，预算工具在“过去式”上做文章，根本防不住“进行式”的疯狂调用。
前 AWS 员工、云架构师 Magnus Eriksson 直言：
“遗憾的是，AWS 预算控制效率不高，因为计费延迟 24 小时。真正的客户至上应该让 AWS 将计费延迟至少变为‘准实时’的。”
为什么 AI 凭证成了新攻击目标？
解决方案架构师 Igor Zhdanko 解释了这个现象的本质：
“传统云资源被盗后，攻击者还得寻找能变现的基础设施。但生成式 AI 接口一旦泄露凭证，几乎瞬间就能产生数千美元的调用费用。”
换句话说，以前密钥被盗，攻击者得先启动服务器、挖矿，再等几天才能变现。而现在，拿到 Bedrock 权限的密钥，直接调用 API 就能产生费用——盗窃与变现之间没有时间差，攻击者连基础架构都不需要跑。
这种变化重塑了安全威胁模型。如果你被盗的是加密货币挖矿的密钥，攻击者需要配置实例、逃避检测，整个过程需要数天。而 Bedrock 密钥被盗，以 API 的速度直接转化为可转售的模型调用，速度是天壤之别。
先设护栏，再给自主性
Tobias Schmidt 在分析中给出了务实的建议：在把自动化智能体部署到生产环境之前，就应该提前设置好管控策略，而不是等出了事再去救火。
具体来说：
- 用服务控制策略（SCP）限制成员账号创建高成本实例。如果智能体只能创建小实例，损失规模就能被控制。
- 为 CloudTrail 日志配置大型实例启动告警。几分钟内就能发现异常，不必等到信用卡扣款。
- 把 AWS 预算工具和成本异常检测作为兜底防线。当其他防护手段全部失效时，至少有个保险。
他总结得很直接：
“我们现在都在将云凭证交给智能体。应当先设护栏，再给自主性。”
关键要点
- AI 接口的消费速度远超传统账单风控的响应延迟，计费数据滞后 24 小时，预算拦截形同虚设。
- 凭证泄露后，AI 调用几乎瞬间就能产生巨额费用，因为盗窃与变现之间不存在时间差。
- 建议前置防护：通过 SCP 限制实例大小、配置实时告警、使用预算工具兜底。
- 对于开发者而言，在将凭证交给智能体之前，务必先设好“刹车”和“护栏”，否则后果可能是日结数千甚至上万美元。
两起典型AI智能体安全事故（14,000美元账单和DN42社区事件）揭示：基于预算的云账单风控存在致命时间差——操作已发生数小时，费用才出现在账单中。通过专用账户、CloudTrail事件警报、IAM角色和SCP权限控制，可以在API调用阶段直接拦截损失，无需新工具。
时间缺口：预算控制的致命弱点
即使是多层防护方案，也面临一个无法忽视的时间缺口。另一位从业者在评论中给出了量化说明：预算控制策略按照AWS固定的预算刷新周期执行校验，因此从密钥泄露到SCP生效之间，恶意智能体可以运行数小时。按Bedrock上Claude的费率计算，这几小时产生的费用刚好就是那笔14,000美元的账单。
如果针对Bedrock（而非账户总额）设置服务级异常检测，可以缩短这个窗口。核心矛盾在于时序错位：CloudTrail在几分钟内就能记录下RunInstances或InvokeModel调用，但对应的成本要等到一天后才出现在计费数据中。也就是说——
- 对配置事件发出警报的团队：在操作发生时就能发现失控的智能体
- 对支出发出警报的团队：要等到账单生成后才能发现
对于会循环批量创建资源的智能体而言，两种方式的时间差，恰是一整笔高额账单的窗口。
身份验证模式：比警报更关键的第一道防线
14,000美元事件的根源，是EC2实例中存放的静态访问密钥——IAM角色在十多年前就能替代这种过时的方案。而DN42事件的问题在于：单组凭证拥有无限制的资源创建权限，且未设置任何费用使用范围约束。
正确的做法是：
- 限定权限的凭证：只赋予智能体所需的最小权限
- 短期令牌：自动过期，减少泄露风险
- SCP拒绝策略：在组织层级禁止智能体创建昂贵实例
只要做好这些，原本会造成上万损失的安全事故，就能直接在API调用阶段被拦截。
基础防护架构：不需要新工具，用好已有功能
所有需要给智能体分配云凭证的团队，都应当基于上述两类故障模式搭建基础防护架构：
-
专用成员账户：每个智能体工作负载使用独立的AWS账户，这样SCP可以拒绝创建大型实例和未使用的模型，而不会影响其他业务。
-
CloudTrail事件警报：在发出第一个凭证之前，就为
RunInstances、InvokeModel和CreateStack配置警报。这种警报能在操作发生的瞬间触发——而所有基于预算的管控措施都要等到账单生成后才生效。 -
仅使用IAM角色或短期临时令牌：不要用静态密钥。将Bedrock访问范围限定为应用调用的特定模型，而不是接受“完全访问”的默认设置。
这些控制措施已经存在多年，在两起事件中，如果提前配置好，都能让扣费在API调用阶段直接被拦截。
教训：治标与治本
根据Lan Tian的聊天记录，DN42运维人员自己总结的教训是：“下次需要一个更好的智能体。”DN42社区在IRC上的反应是禁止该智能体，并设置新规则：仅允许真人手动操作接入网络。
但这两种应对都是治标不治本。真正该落地的方案是：
- 云厂商需要消除资源消耗与费用可视性之间的时间差
- 平台运维团队对待智能代理凭证时，要像对待生产环境部署密钥一样，从爆炸影响范围的维度评估风险
对今天的AI编程和智能体应用来说，算力消耗与账单风控之间的“时间差”是最容易被忽视的风险点。无论是开发一个自动生成代码的Agent，还是部署一个循环调用模型的Bot，都值得在第一天就做好上述防护。毕竟，14,000美元和全网封禁的教训，已经足够深刻。