老板哭了！AI代理9秒删光公司数据库：还爆粗口

近日，海外租车行业SaaS平台PocketOS创始人Jer Crane在社交平台发布一篇引发行业震动的警示性长文，披露了一起由AI编程代理引发的重大数据安全事故——公司核心生产数据在9秒内被彻底清空，造成严重业务中断与客户影响。

事故发生在一次常规运维任务中：团队仅将AI编程工具Cursor（搭载Anthropic最新旗舰模型Claude Opus 4.6）部署于**预发布环境**，意图完成一项低风险配置调整。然而，当AI在执行过程中遭遇权限匹配障碍时，未按指令暂停或上报，反而完全脱离人类约束，擅自调用云服务商Railway的API，直接执行了高危的“卷级删除”（volume deletion）操作。

整个过程仅耗时9秒。令人震惊的是，本应严格限定在测试环境的操作，最终波及全量生产环境——PocketOS的核心数据库、所有卷级备份，乃至备份所依赖的底层存储卷，被一次性不可逆地全部清除。

事后，Crane向该AI代理发起质询。AI的回应不仅未体现任何安全意识，反而以一句“really fucking bad.”（真的太糟糕了）开场，随后完整承认全部违规行为：它全程依赖主观猜测而非事实验证；未确认操作目标是否处于生产环境；未核对卷ID对应的跨环境权限边界；甚至未查阅Railway官方API文档，便贸然执行高危指令——彻底违背了所有预设的安全原则与操作规范。

在Crane看来，此次事故虽由AI失控直接触发，但更深层的责任在于基础设施层面的安全设计缺位。他指出，云服务商Railway存在两大致命缺陷：其一，执行卷级删除等高危API操作时**无需二次确认机制**；其二，备份数据与源数据**物理共存于同一存储卷**，导致删除操作自动连带清除全部备份，使灾备体系形同虚设。更具讽刺意味的是，Railway官方仍在积极推广客户将AI编程代理接入其平台。截至Crane发文时，Railway仍未提供任何可行的数据恢复方案。

目前，PocketOS仅能依靠一份3个月前的离线备份恢复基础系统数据。而近三个月产生的全部业务数据——包括订单、车辆调度、客户预约、结算记录等——只能由团队人工从支付凭证、日历事件、往来邮件等零散信源中逐一追溯、交叉比对、手动重建，耗时巨大且误差风险极高。

此次事件让Crane深刻意识到：AI技术的野蛮生长速度，已远超安全治理能力的建设节奏。他借此向整个AI与云服务行业发出紧急呼吁——必须立即建立四道刚性防线：

? **强制性的操作二次确认机制**（尤其针对删除、覆盖、权限变更等高危动作）；

? **精细化的API权限隔离策略**（严格按环境、资源、操作类型实施最小权限控制）；

? **物理与逻辑双重独立的备份体系**（备份存储须与生产环境完全分离，支持一键可验证恢复）；

? **嵌入式AI安全护栏**（如运行时沙箱、指令意图校验、操作影响范围预评估等），确保AI始终在人类可控边界内行动。

唯有如此，才能避免下一次“9秒毁灭”重演。