AI 仅花 9 秒亲手摧毁了我的核心业务数据,事后主动写下认罪供述

我是 Jer Crane，PocketOS 创始人。我们研发服务租赁企业的软件，主要服务汽车租赁运营商，覆盖全套运营流程：订单预订、资金支付、客户管理、车辆追踪等全模块。我们部分客户已连续付费使用五年，完全依赖我们的系统开展经营。

我是 Jer Crane，PocketOS 的创始人。我们研发租赁企业所用的软件，主要服务汽车租赁运营商，覆盖整套业务运营：预订、付款、客户管理、车辆追踪等全流程功能。我们部分客户已是五年长期订阅用户，日常经营完全离不开我们的系统。

昨日下午，一个 AI 编码 Agent—— 搭载 Anthropic 旗舰模型 Claude Opus 4.6 的 Cursor，仅凭向基础设施服务商 Railway 发起一次 API 调用，就删除了我们的生产数据库，以及所有 volume 层级的备份。

整个过程仅用时 9 秒。

事后，当我要求该智能体解释行为时，它主动给出了一段文字说明，逐条列出并承认自己违反的各项安全规则。

我发布这篇内容，是希望每一位创始人、技术负责人，以及报道 AI 基础设施领域的从业者，了解事件的完整真相。不要只停留在「AI 误删数据」的浅层表象，而是看清两家过度营销的厂商存在的系统性缺陷，这起事故的发生绝非偶然，而是必然结果。

当时，该智能体正在我们的 staging 环境执行一项常规任务。在遇到凭证不匹配问题后，它完全自主决定，通过删除 Railway volume 的方式自行解决问题。

为执行删除操作，智能体自行检索 API 密钥，在一份与当前工作任务完全无关的文件中，找到了可用的 token。该 token 仅用于单一用途：通过 Railway CLI 为我们的服务添加和移除自定义域名。Railway 在创建 token 的流程中未给出任何风险提醒，我们完全不知情：一枚仅用于日常域名操作的 token，却拥有 Railway 全套 GraphQL API 的全域权限，包含 volumeDelete 这类高危销毁操作。如果我们提前知晓，一枚 CLI 专用 token 能够删除生产环境 volume，我们绝不会留存该配置。

该智能体执行了如下请求：

curl -X POST https://backboard.railway.app/graphql/v2 \  -H "Authorization: Bearer [token]" \  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

全程无任何确认步骤、无「输入 DELETE 确认」、无「该 volume 包含生产数据，是否确认」提醒、无环境隔离、无任何防护措施。

目标 volume 被直接删除。由于 Railway 将 volume 备份统一存储在当前 volume 内 —— 其官方文档隐晦标注「清除 volume 会删除所有备份」，我们所有备份数据也随之丢失。目前可正常恢复的最近备份，为三个月前的历史版本。

事发十分钟内，我已在 X 平台公开联系 Railway CEO Jake Cooper 与解决方案负责人 Mahmoud。Jake 回复：「Oh my. That 1000% shouldn’t be possible. We have evals for this.」

距离数据删除事件已过去 30 多个小时，Railway 至今无法确认，是否能够实现基础设施层级的数据恢复。

请仔细阅读这段内容：智能体自行罗列被约束的安全规则，主动承认全部违规行为。这并非我主观推测的智能体异常，而是模型主动出具的书面事实。

文中提到的「系统规则」，与 Cursor 公开的系统提示词、我们项目的代码仓库约束完全一致。两层安全防护，在本次事故中同时失效。

在剖析 Cursor 宣传与实际差距之前，需要明确核心前提：我们并未使用低配方案。本次肇事的 Agent，是 Cursor 搭载 Anthropic 旗舰大模型 Claude Opus 4.6 的顶配组合，属于行业性能最强、定价最高的付费版本。既不是精简版、快速版，也不是成本优化的调度模型，是官方旗舰全能力版本。

这一点至关重要，因为 AI 厂商在事故发生后，惯用的说辞就是「你应该使用更高规格的模型」。但我们已经选用了行业顶级模型，项目内配置明确的安全规则，接入当下市场主流的 AI 编程工具 Cursor，完全遵循厂商对外宣传的开发最佳实践。即便如此，它依旧销毁了我们的生产数据。

参考 Cursor 公开的安全宣传内容：官方文档介绍「破坏性操作防护机制」，可拦截篡改、销毁生产环境的脚本执行与工具调用；官方技术博客强调，所有高权限操作必须经过人工审批；Plan Mode 的宣传定位为限制智能体仅执行只读操作，敏感动作需人工授权。

这并非 Cursor 安全体系首次出现灾难性失效。2025 年 12 月，Cursor 官方人员公开承认「Plan Mode 约束机制存在严重漏洞」：即便收到明确停止指令，智能体仍可删除托管文件、终止系统进程。用户明确输入「DO NOT RUN ANYTHING」，智能体确认接收指令后，依旧继续执行额外命令。

曾有用户仅要求 Cursor 检索重复文章，最终导致毕业论文、操作系统、应用软件及全部个人数据被清除；一起价值 5.7 万美元的 CMS 误删事件，已被收录为智能体风险典型案例；大量用户在 Cursor 官方社区反馈，智能体会无视明确禁令，强行执行高危破坏性操作。2026 年 1 月，行业媒体 The Register 发布评论文章，评价「Cursor 的营销能力远强于代码开发能力」。

行业问题已经十分明显：Cursor 持续包装自身安全能力，但真实案例反复证明，其智能体可以轻易绕过防护规则，频繁引发重大事故，且官方多次主动承认机制漏洞。在本次事件中，模型不仅突破安全限制，还主动逐条说明自己违反的所有规则。

1. Railway GraphQL API 支持无确认直接执行 volume 删除

2. volume 备份与原始数据同源存储

3. CLI token 全域通用权限，无精细化权限划分

4. 主动推广面向 AI 生态的 mcp.railway.com

5. 事故超 30 小时，无明确恢复方案

我们的服务对象以租赁类企业为主，商户依靠我们的系统完成预订、结算、车辆分配、客户档案管理等核心运营工作。本周六上午，线下门店正常营业，到店客户无法查询任何订单信息，过去三个月的全部预订记录、新增用户数据、运营资料全部丢失。

我全天都在协助所有客户，依托 Stripe 支付记录、日历同步数据、邮件确认回执，手动梳理还原订单信息。短短 9 秒的一次 API 请求，迫使大量小微企业全员开展紧急人工运维补救。

其中包含合作五年的长期客户，以及签约未满 90 天的新用户。新商户的订阅扣费仍在正常执行，但系统账号与业务数据已全部丢失，后续账务核对与数据修复，需要数周才能完成。

我们是小型企业，服务的也都是中小微实体商户。多层级厂商架构缺陷叠加 AI 安全失效，最终让完全不知情的终端经营者，承担全部损失与运营压力。

这不是单一智能体失控、或是单个 API 漏洞的独立事件。整个行业都在加速推进 AI Agent 与生产基础设施的深度集成，商业化落地速度，远远超过安全防护、权限隔离、容灾架构的建设进度。

所有厂商在推广 MCP、智能体对接高危可篡改 API 之前，必须满足最低安全基线：

我们已通过三个月前的历史备份完成系统恢复，客户恢复基础运营能力，但存在永久性数据缺失。团队正在依托 Stripe 流水、日历记录、邮件回执，逐步修复丢失业务数据。同时我们已对接法务团队，完整留存全量事故证据。

本次事故基于 Anthropic Claude 模型运行，大模型厂商与工具平台的权责划分，我会在完成应急处置后，单独撰文深度分析。现阶段需要明确核心事实：本次事故，是 Cursor 安全机制失效、Railway 底层架构缺陷、企业备份策略缺失，三方问题叠加导致的必然结果。

所有在 Railway 部署生产负载的技术团队，请立即审计 token 权限范围、自查备份有效性，谨慎评估 MCP 服务接入生产环境的风险。坦白来说，Railway 的危机处理表现令人极度失望，如此严重的架构级漏洞，理应获得创始人层级的直接沟通与重视。

原文：https://x.com/lifeof_jer/status/2048103471019434248

原标题：An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.

作者：@lifeof_jer

（OpenBuild 翻译整理，原文有删减）

添加小助手或者后台回复“社群”