一家仅有三名员工的公司，平日的 AWS 月度账单仅 10 至 15 美元，但在攻击者从一个 EC2 实例中窃取静态访问密钥后，疯狂调用亚马逊 Bedrock 平台上的 Claude 大模型，单日产生高达 14000 美元的扣费。

亚马逊云科技顾问 Tobias Schmidt 在 LinkedIn 上描述了这起事件：该团队曾使用现有访问密钥试验 Bedrock 聊天机器人，两项默认配置放大了此次损失。这些密钥拥有 Bedrock 完全访问权限，而 AWS 在 2025 年移除了模型访问开关，默认启用了所有模型。此外，该应用原本设定调用 Haiku 模型，预估账单成本不足 100 美元。

此类事件并非首例，云成本相关论坛上已出现多起高度相似的案例。一个 AI 智能体程序或其凭证泄露在被察觉之前就产生数千美元的高额费用，因为云平台账单告警相比实际消费存在约一天的延迟。两起事件均由亲历从业者完整记录，暴露出自动化程序的消费增长速度与人工操作的慢速护栏之间的结构性错配。

最详细的案例是 5 月份的 DN42 事件，由网络工程师 Lan Tian 记录，并在 Hacker News 上引发广泛讨论。一名运维人员授予自主智能体完整的 AWS 访问权限，并设定了一个扫描 DN42 的截止时间——这是一个业余 BGP 网络，大多数节点运行在小的 VPS 实例上。该智能体认为这项工作需要五台 m8g.12xlarge 实例（每台 48 个 vCPU 和 22.5 Gbps 带宽）以及负载均衡器和 Lambda 函数，目标是实现 “20 吉比特每秒扫描速率，同时具备冗余备份与故障转移能力”。然后智能体反复应用 CloudFormation 模板，不断复制整个资源栈。运维人员在一天后才发现异常，当时他们的信用卡已被扣 6531.30 美元。事后经协商，AWS 将账单减免至 1894 美元。据圈内从业者估算，这项扫描工作实际上仅需一台月租 5 美元的虚拟服务器。

两起事件存在一个共性：用户都是通过信用卡扣款记录才察觉异常，而非来自 AWS 的告警。Cost Explorer 中的计费数据滞后长达 24 小时。AWS Budgets 基于这份滞后数据进行校验，因此预算拦截措施只会在费用已经产生后才触发。云架构师、前 AWS 员工 Magnus Eriksson 在 Schmidt 帖子的评论区直白地写道：

遗憾的是，AWS 预算控制效率不高，因为计费延迟 24 小时。真正的客户至上应该让 AWS 将计费延迟至少变为”准实时“的。

Regula 的解决方案架构师 Igor Zhdanko 解释了为什么 GenAI 凭证已成为一个独特的攻击目标类别：

我不断看到更多类似这起 Bedrock 的安全事故。传统云资源被盗后，攻击者还得寻找能变现的基础设施。但生成式 AI 接口一旦泄露凭证，几乎瞬间就能产生数千美元的调用费用。IAM 角色、最小权限、模型限制、预算和终止开关应该从项目上线之初就应当作为标准配置。

这种区别重塑了安全威胁模型。如果被盗密钥仅能用于加密货币挖矿，攻击者需要配置实例、逃避检测，并在数天内将计算转化为货币。而具有 Bedrock 访问权限的密钥被盗，会直接以 API 速度转化为可转售的模型调用，攻击者无需运行任何基础设施，盗窃与变现之间不存在时间差。

Schmidt 的后续分析认为，在自动化程序部署前就启用现有管控策略，而非等到事后补救，本可以避免这一系列问题：

通过服务控制策略（SCP）限制成员账号创建高成本实例。如果自动化智能体仅能创建小型实例，就能从源头控制损失规模。为云追踪日志（CloudTrail）配置大型实例启动操作告警，几分钟内即可捕获异常，不必等到信用卡扣款才发现问题。而当其他防护手段全部失效时，AWS 预算工具与成本异常检测功能可作为兜底安全防线。

他对当前现状的总结如下：

我们现在都在将云凭证交给智能体。应当先设护栏，再给自主性。

即使是这种多层防护方案也存在一个时间缺口，另一位从业者在评论中给出了量化说明：预算控制策略按照 AWS 固定的预算刷新周期执行校验，因此密钥盗窃爆发可以在 SCP 生效前运行数小时，以 Bedrock 上的 Claude 费率计算，这数小时产生的费用刚好就是那笔 14000 美元的账单。针对 Bedrock 而非账户总额的服务级异常检测可以缩短这个窗口。核心矛盾在于时序颠倒：CloudTrail 在几分钟内记录 RunInstances 或 InvokeModel 调用，而其成本在一天后才出现在计费数据中。对配置事件发出警报的团队在行动时就能发现失控的智能体；对支出发出警报的团队要等到账单生成后才能发现。对于会循环批量创建资源的智能体，两种方式的差距就是一整笔高额账单。

身份验证模式与警报同样重要。那笔 14000 美元的高额账单事件，根源是 EC2 实例中存放的静态访问密钥——IAM 角色在十多年前就能替代这种过时的密钥方案。DN42 事件的问题则在于，单组凭证拥有无限制的资源创建权限，且未设置任何费用使用范围约束。有限定权限范围的凭证、短期令牌以及拒绝向智能体操作账户提供昂贵实例的 SCP，就能把原本会造成上万损失的安全事故直接拦截在 API 调用阶段。

对于现金需要给智能体分配云凭证的团队，都应当基于上述两类典型故障模式搭建基础防护架构。使用专用成员账户运行每个智能体工作负载，这样 SCP 就可以拒绝创建大型实例和未使用的模型，而不会影响其他任何东西。在发出第一个凭证之前，为 RunInstances、InvokeModel 和 CreateStack 配置 CloudTrail 事件警报，因为这种警报能在操作发生瞬间触发，而所有基于预算的管控措施都要等到账单生成后才生效。仅使用 IAM 角色或短期临时令牌鉴权，并将 Bedrock 访问范围限定为应用调用的特定模型，而不是接受完全访问默认设置。这些都不需要使用新工具，在两起事件中，这些存在多年的控制措施都可以让扣费在 API 调用阶段就直接被拦截。

根据 Lan Tian 的聊天记录，DN42 运维人员自己总结的教训是”下次需要一个更好的智能体。“DN42 社区在 IRC 上的反应是禁止该智能体并设置新的规则：仅允许真人手动操作接入网络。但在这两种治标不治本的应对之外才是真正该落地的方案：云厂商需要消除资源消耗与费用可视性之间的时间差，平台运维团队对待智能代理凭证时，要像对待生产环境部署密钥一样，从爆炸影响范围的维度评估风险。

查看英文原文：