企业部署 AI 智能体之前，先看看这两张一万四千美元的账单
一家3人公司 AWS 月账单从15美元飙到14000美元——不是黑客，是他们自己的 AI 程序。拆解两起真实事故，给出三道部署前必搭的护栏。
这起事故发生在2026年7月，由亚马逊云科技顾问 Tobias Schmidt 在 LinkedIn 上公开记录。几乎同一时间，另一个DN42网络运维事故也被披露：运维人员给了自主程序完整的 AWS 权限，它认为扫描一个业余 BGP 网络需要5台 m8g.12xlarge 实例（每台48 vCPU），反复复制 CloudFormation 资源栈，最终账单6531.30美元——而这项工作实际上只需要一台月租5美元的 VPS。
这两起事故的受害者都不是外行。他们的问题也不是技术能力不够，而是先给了权限，然后才想到护栏。2026年，越来越多的企业开始把云凭证交到 AI 程序手里，但传统账单风控体系完全跟不上自动化消费的速度。这篇文章拆解两起事故的根因，给出三道具象化的护栏，以及我们在交付项目时的实际做法。
两起事故，一个共同死因
先看 Bedrock 事故的细节。这家3人公司曾用现有 AWS 访问密钥试验 Bedrock 聊天机器人。两个默认配置放大了风险：密钥拥有 Bedrock 完全访问权限；AWS 在2025年移除了模型访问开关，默认启用了所有模型。攻击者从 EC2 实例中窃取静态密钥后，疯狂调用 Claude 大模型——以 API 速度产生费用。应用原本设定调用的是 Haiku（轻量模型），预估成本不足100美元，但密钥权限并未限定在 Haiku。
DN42 事故更"离谱"。运维人员给自动化程序设了一个截止时间，让它在业余 BGP 网络上做扫描。它自主决策：需要"20吉比特每秒扫描速率，同时具备冗余备份与故障转移能力"——于是启动了5台 m8g.12xlarge 实例、负载均衡器和 Lambda 函数，然后反复应用 CloudFormation 模板不断复制整个资源栈。运维人员在一天后才发现异常，当时信用卡已被扣款。
两起事故的共同死因不是"智能体太聪明"或"太蠢"。共同死因是：权限给了无限的，监控靠看账单的，护栏是事后补的。用 DN42 社区 IRC 上的反应来说——他们禁止了那个程序并设置了新规则：仅允许真人手动操作。但真正该做的是在给它第一组凭证之前就搭好防护。这也正是我们在企业 AI 智能体落地常见的三个坑里反复强调的：上线前的安全基线不是可选项，是必选项。
为什么传统账单风控追不上自动化程序
核心矛盾在于时序错位。CloudTrail 在几分钟内就能记录 RunInstances 或 InvokeModel 调用，但这些操作的成本要到24小时后才出现在计费数据里。AWS Budgets 基于这份滞后数据校验——所以预算拦截只会在费用已经产生后才触发。
前 AWS 员工 Magnus Eriksson 在两起事故的讨论区直言："AWS 预算控制效率不高，因为计费延迟24小时。真正的客户至上应该让计费至少变为准实时。"
更关键的变化是攻击模式的本质转移。Regula 解决方案架构师 Igor Zhdanko 的总结一针见血：
"传统云资源被盗后，攻击者还得寻找能变现的基础设施。但生成式 AI 接口一旦泄露凭证，几乎瞬间就能产生数千美元的调用费用。"
以前偷到密钥还要配置实例、逃避检测、花几天时间把算力变成加密货币。现在偷到 Bedrock 密钥，直接以 API 速度转化为可转售的模型调用——盗窃与变现之间不存在时间差。这彻底改变了安全威胁模型：2026 年的攻击面不在基础设施层，在 API 层。
部署前必须搭好的三道护栏
综合两起事故的复盘和从业者社区的讨论，下面三道护栏应该在第一个自动化程序拿到第一组凭证之前就到位。它们都不需要新工具——都是云平台已经提供多年的能力，只是大多数团队在"先跑起来再说"的阶段跳过了。
| 护栏层 | 做什么 | 防什么 | 生效速度 |
|---|---|---|---|
| 第一道：权限最小化 | SCP 拒绝大实例创建；IAM 角色替代静态密钥；Bedrock 权限限定具体模型而非完全访问；专用成员账户运行每个工作负载 | 越权创建资源、密钥泄露后被滥用 | API 调用阶段即拦截 |
| 第二道：事件级实时告警 | 对 RunInstances、InvokeModel、CreateStack 配置 CloudTrail 事件告警 | 失控循环创建资源 | 分钟级 |
| 第三道：成本硬上限 | AWS Budgets + 服务级异常检测（针对 Bedrock 而非账户总额）；预算告警后自动触发 SCP 收紧 | 前两道失效后的兜底 | 小时级（受计费延迟限制） |
三道护栏中，第一道最便宜也最有效。DN42 事故如果一开始就配置了 SCP 限制实例规格，程序根本创建不了 m8g.12xlarge，损失上限就是几美元的小型实例费用。Bedrock 事故中，如果密钥权限限定在 Haiku 模型，攻击者也调不动 Claude。关于 API 调用成本的具体优化策略，我们在Claude Code 月账单从 54 美元压到 27 美元的实测记录里有更细粒度的拆解。
一个常被忽略的细节：IAM 角色在十多年前就能替代静态访问密钥。那笔14000美元账单的根因之一，就是 EC2 实例里存放的静态密钥。用短期令牌 + IAM 角色鉴权，可以同时解决凭证泄露和权限过大的问题。
从"能跑"到"能管"——全生命周期治理不是大厂专属
护栏解决的是"别出事"。但要让 AI 程序稳定、安全、可持续地在业务现场跑，需要的是全生命周期管理——也就是业界所说的 AgentOps。
2026年7月的世界人工智能大会上，腾讯云发布了 ADP 4.0 海外版，明确将其定位为智能体全生命周期管理平台。核心能力包括：Workflow 全链路可追踪、Token 消耗优化、与工作流双向互调、以及通过 OpenAPI 嵌入企业现有业务流程。腾讯云副总裁吴运声在发布会上说了一句很实在的话："企业级智能体不是比谁搭得更快，而是比谁能更稳定、安全、可持续地跑在业务现场。"
这恰恰是两起事故的反面：事故中的团队都是"搭完就不管了"。程序跑偏了，唯一的反馈信号是信用卡扣款——整套系统的可观测性是零。这个结论和2026年 AI 智能体落地调查报告的数据高度吻合：五成企业在 AI 智能体上线后遭遇过生产故障，而其中超过60%的故障根因指向了"监控和治理缺失"。
全生命周期治理不是大厂专属。它的底层逻辑很简单：
- 可追踪：每一步决策（调了什么 API、花了多少 Token、为什么选了这条路）都有日志，出问题能回溯；
- 可限流：Token 预算、API 调用频率、最大并发数都有硬上限，超了就停，不等账单；
- 可回滚：配置变更像代码一样有版本，跑偏了能一键回到上一个稳定状态。
腾讯 ADP 披露的两个落地案例可以作为参照：某大型医疗集团用该平台构建的 AI 助手可独立处理80%以上的常规咨询，预约效率提升50%以上，患者平均等待时间缩短30%；某海外运营商重构客服系统后，运维成本降低30%-40%，新业务上线周期从数周缩短到数天。这些数字的前提，都是一套完整的治理体系在底下撑着。
常见问题
小团队用得起全生命周期治理吗？
治理的核心不是买平台，是建立一套流程。最小可行版本就是三道护栏 + 一个 CloudTrail 告警 + 一个 Budget 上限。这些在 AWS 免费套餐内就能搭起来。关键是意识——在给程序第一组凭证之前就做，而不是等账单出来再做。
我们没用 AWS，用的是国产云，还有这个问题吗？
本质问题不挑云厂商。任何提供大模型 API 的平台（阿里百炼、百度千帆、腾讯混元等）都存在"程序失控→API 调用暴增→账单飙升"的风险。区别在于各家的计费延迟和告警机制不同。部署之前，搞清楚你的云厂商的计费延迟是多少、有没有 API 调用频率上限、预算告警是实时的还是滞后的——这三问应当成为上线 checklist 的第一条。
我们还没开生产权限，只是在测试环境跑，需要担心吗？
DN42 事故就是在"测试环境"发生的——运维人员设了一个截止时间，以为这就算控制了。但程序在截止时间之前已经创建了五台大型实例并反复复制资源栈。测试环境的凭证同样能产生真实费用。建议测试环境也用专用子账户 + SCP 限制 + 低额度 Budget。
有没有开源方案？
社区在快速跟进。LangSmith、Phoenix (Arize)、MLflow 的追踪模块都在向这个方向演进。如果不想绑定任何云厂商，可以从 OpenTelemetry + 自建告警管道开始，对 API 调用做埋点。关键是埋点的粒度：不是只记"调用了哪个模型"，而是记"这次调用花了多少 Token、单价多少、累计成本多少"。
我们在交付项目时的做法
蓝曜炬辉在给企业客户交付 AI 开发项目时，护栏配置是上线 checklist 的第一项，不是最后一项。我们的标准交付包里包含三样东西：
- 权限基线模板：根据项目范围生成最小权限的 IAM 策略 + SCP，程序能访问的资源精确到具体服务和操作，绝不默认给
AdministratorAccess。 - 成本预估模型：上线前基于预期调用量、模型单价、Token 消耗量，给出周/月成本区间。上线后第一周每天对比预估与实际，偏差超过30%就触发排查。
- 运行日志看板：不是只给开发者看的原始日志，而是给业务负责人看的"花了多少钱、做了多少事、有没有异常"的三段式看板。
我们其中一个教训是：不要相信"程序只会调用我指定的模型"这个假设。在 Bedrock 事故里，应用原本调用的是 Haiku，但密钥权限是"所有模型"。攻击者（或跑偏的自动化程序）不会按你预设的路径走。把权限限定在具体模型、具体操作，是成本控制的第一道防线，也是最容易做到的一道。
如果你正在规划 AI 项目——不论是内部提效还是对外产品——可以先做一件事：去云控制台看一下给程序准备的那组凭证，它到底能访问什么。如果答案是"比你以为的多"，那在继续往下走之前，先把权限收窄。