一个由 AI 生成的 cron job 在不到十秒的时间内删除了某初创公司所有的 Stripe 活跃订阅，导致公司的月经常性收入 (MRR) 骤降至 38 美元。这次事件表明，危险存在于部署流水线中，而非编写代码的语言模型本身。

发生了什么

上周，BridgeMindAI 团队醒来时，发现仪表盘显示的月经常性收入 (MRR) 仅为 38 美元。一个 AI 模型生成了一行代码，并由调度器自动运行。这行代码针对每个客户记录调用了 Stripe 的订阅取消接口。该调用在七秒内完成，并清空了整个客户群。

该脚本将一个空的删除队列误读为“删除所有内容”的信号。这种“空 = 全部”的模式自 20 世纪 80 年代以来就一直存在于生产代码中，远早于生成式 AI 的出现。

为什么模型不是罪魁祸首

人们很快就开始指责 AI 模型不可信。但即便更换模型也无法阻止这次清空，因为缺陷在于逻辑设计，而非幻觉或偏见。

真正的失败在于架构层面：

  • 脚本存储了一个具有取消订阅权限的 Stripe 生产环境 API 密钥。
  • 它在没有任何运行时监督的情况下运行。
  • 在代码生成与执行之间没有任何人工检查点。

这些漏洞使得一个单一的 Bug 在几秒钟内就摧毁了收入流。

任何自主流水线都需要思考的三个安全问题

  1. 哪些操作是不可逆的？ 取消订阅、删除记录或退款都是无法撤销的操作。它们需要比只读查询更高等级的保护。

  2. 代理 (Agent) 持有何种凭据？ 将 Stripe 主密钥交给自主进程意味着赋予了其不受限制的权力。应遵循最小权限原则：使用仅能执行所需任务的受限密钥 (scoped keys)。

  3. 人工检查点在哪里？ 仅靠代码审查是不够的。应在代码生成之后、任何破坏性操作之前设置一道关卡。

实际的安全护栏

  • 空运行关卡 (Dry-run gate) —— 在进行任何删除或取消调用之前，先记录预期的目标。如果列表为空或规模异常庞大，请立即中止并提醒人工介入。
  • 受限凭据 (Scoped credentials) —— 默认使用只读密钥。当任务必须取消订阅时，创建一个每次只能针对单个客户 ID 进行操作的受限密钥。
  • 人工介入提示 (Human-in-the-loop prompt) —— 向频道（如 Slack）发送一条简短消息，例如：“我即将取消 47 个订阅。确认吗？”其成本微乎其微，但带来的安全收益却巨大。

无论由哪个模型编写代码，这些措施都有效，因为它们保护的是执行环境，而非生成器。

自主代理的生产环境检查清单

  • 将每项操作分类为只读、可逆或不可逆。
  • 所有不可逆操作都必须经过明确的人工批准。
  • 将凭据权限限制在完成任务所需的最小范围内。
  • 对删除或修改记录的循环设置规模限制。
  • 首先在镜像生产数据的沙盒环境中运行代理；在触及真实数据之前，先确认执行结果。
  • 在执行前以自然语言记录代理的计划，以便审核人员能一眼看清其意图。

遵循此检查清单可以将“一键运行且不再管”的脚本转变为受控的工作流，一旦发现异常，即可进行审计并停止运行。

教训很明确：信任流程，而非模型。