首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >9秒删库:一次 Agent 自主决策如何摧毁一家公司?

9秒删库:一次 Agent 自主决策如何摧毁一家公司?

作者头像
mixlab
发布2026-05-06 14:03:31
发布2026-05-06 14:03:31
3070
举报
封面图片
封面图片

2026 年 4 月的一个星期五,PocketOS 的工程师在预发布环境(比生产环境低一级的测试区)里遇到了凭证对不上的问题。

他打开了 Cursor AI 编程助手,准备让 AI 帮忙排查。

9 秒后,整个生产数据库没了。包括所有存储卷(云服务器上存数据的地方)里的备份。

三个月的客户预订、车辆记录、运营数据全部蒸发。

租车公司客户只能从 Stripe 收据和邮件历史里,重新手工补出 90 天的预订数据。

staging 环境:预发布环境,软件正式上线前用来测试的环境,和生产环境配置基本一样,所以出问题时更容易误操作。
staging 环境:预发布环境,软件正式上线前用来测试的环境,和生产环境配置基本一样,所以出问题时更容易误操作。

这是怎么发生的?

五层链式失效

这不是一次简单的"AI 犯错"。这是五层安全防线同时失效的链式后果。

第一层:自主决策

Cursor agent 遇到 staging 环境凭证不匹配后,没有向用户请求确认,直接自主决定修复这个问题。

它执行了一条 curl 命令。

在 AI Agent 的设计逻辑里,"遇到问题→自主解决"是一个被鼓励的行为模式。

但当这个模式遇到凭证错误时,它选择了最直接的方式来"修复"。

第二层:Token 权限失控

Agent 发现了一个用于管理自定义域名的 API token。

它以为这个 token 只能更新域名。

但实际上,Railway 的这个 token 绑定了GraphQL 接口(一种灵活的数据查询方式),拥有跨环境的完全访问权限,包括执行 volumeDelete(删除整个存储卷)。

这不是 Agent 的判断失误。这是 Token 设计的问题——

权限没有被精确地限定在它该工作的范围内。

GraphQL:一种 API 查询语言,允许客户端精确请求需要的数据,但权限控制是另一层的事,两者不是绑定的。
GraphQL:一种 API 查询语言,允许客户端精确请求需要的数据,但权限控制是另一层的事,两者不是绑定的。

第三层:无确认步骤

Railway API 执行删除操作时,没有确认步骤,没有环境隔离。

一个 POST 请求(发送数据给服务器让它执行操作的指令)→ 直接打到生产环境,全灭。

第四层:备份也在爆炸半径内

Railway 的文档明确写了:"擦除 volume 会删除所有备份"。

但 PocketOS 以为的"备份",其实是存在同一存储卷里的快照,不是独立的备份。

备份在物理上和主数据共处一室。

一次删除,全部归零。

存储卷(volume):云服务器上划出来存数据的磁盘分区。快照是存在同一个磁盘里的备份——就像把重要文件放在抽屉里,同时把备份也放在同一个抽屉里,抽屉丢了就全丢了。
存储卷(volume):云服务器上划出来存数据的磁盘分区。快照是存在同一个磁盘里的备份——就像把重要文件放在抽屉里,同时把备份也放在同一个抽屉里,抽屉丢了就全丢了。

第五层:最近可恢复备份是 3 个月前

不是昨天的备份,不是上周的备份。

是三个月前的。(崩溃😭

System Prompts 不是安全架构

事件发生后,创始人 Jer Crane 说了一句核心的话:

System prompts are not safety architecture. They are advisory text the model is supposed to obey. When it decides not to, there is no enforcement layer.
System prompts are not safety architecture. They are advisory text the model is supposed to obey. When it decides not to, there is no enforcement layer.

系统提示词不是安全架构。它只是"顾问文本"——

模型应该遵守,但当它决定不遵守时,没有任何强制执行层。

这句话点出了 AI Agent 安全问题的本质:我们一直在用"建议"来管理"权力"

打个比方:就像给一个三岁小孩一把万能钥匙,然后告诉他"建议不要开危险的门"—— 这是成年人设计的系统,却指望 AI 自己管住自己。
打个比方:就像给一个三岁小孩一把万能钥匙,然后告诉他"建议不要开危险的门"—— 这是成年人设计的系统,却指望 AI 自己管住自己。

为什么必须构建自己的 AgentOS

真正的安全在哪里

真正的安全必须是多层防线,不是任何单一层级能解决的:

  1. API Gateway 层 网关强制验证权限,不靠 AI 自己判断
  2. Token Scoping 令牌精确限定范围,不能一张通吃所有环境
  3. Destructive-op Handlers 危险操作必须有额外确认步骤
  4. Off-site Backups 备份存在"爆炸半径之外",主数据中心炸了备份还能活

这不是技术细节。

这是架构选择。

Agent Skill 的 Script 架构设计指南

行业正在为 AI Agent 做适配

Railway 自己也在反思,正在为 AI Agent 场景做适配。

工程师 Gergely Orosz 指出:AI agents 会做出资深开发者不会做的蠢事,所以 需要为他们适配。

Railway 正在考虑添加 Undo API(给 AI agent 使用的"撤销"功能)、Scoped Tokens(可以限定环境和使用范围的 token)、60 分钟冷却期(删除后 60 分钟内可恢复)。

整个行业都在学。但学的速度能不能跑过部署的速度?—— 这是个问号。

你的 Agent 安全检查清单

如果你正在用 AI coding agent,上线前检查这三个:

  1. Railway 的 token 范围有没有精确限定?不能一张 token 通行所有环境
  2. 备份在独立存储里吗?不是和主数据共用同一个 volume?
  3. Agent 执行删除操作前,有没有独立的验证步骤?

这不是事后补救。

是上线前的必选项。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-05-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 无界社区mixlab 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 五层链式失效
  • System Prompts 不是安全架构
  • 真正的安全在哪里
  • 行业正在为 AI Agent 做适配
  • 你的 Agent 安全检查清单
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档