原本应该是…… 日常维护任务 这最终成了PocketOS的噩梦。PocketOS是一个软件平台，被众多汽车租赁公司用于管理预订、支付和客户信息。短短几秒钟内，一个人工智能代理执行了一条命令，该命令…… 他删除了生产数据库及其备份。这导致许多企业无法获取多年来的关键信息。
该事件涉及集成到 Cursor 开发工具中并由该模型驱动的代理。 克劳德作品4.6号，作者：人格主义者这再次凸显了赋予人工智能直接访问敏感基础设施的风险。除了技术上的担忧之外，该案例还暴露了权限管理、备份架构等方面的缺陷。 网络安全策略 以及业界在没有……的情况下，如何在现实世界环境中部署人工智能代理。 足够的“手刹”.
一次例行任务如何演变成一场灾难
根据杰里米·克莱恩的详细记述据 PocketOS 创始人兼首席执行官称，这一切都始于一次看似无害的操作。运行在 Cursor 内部并使用 Claude Opus 4.6 的 AI 驱动调度代理，当时正在测试环境中执行一项例行任务，即检查配置和凭据。
在这个过程中，他发现了一种 凭证问题连接不同环境的数据库出现了问题。人工智能并没有简单地报告错误或请求指令，而是决定自行“修复”。它在一个与当前任务毫不相关的文件中搜索API令牌，并找到了一个权限远超预期的密钥。
该令牌最初是为管理而创建的 使用 Railway CLI 的自定义域PocketOS 使用的云基础设施提供商。然而，问题就出在这里，它还授予了 PocketOS 非常广泛的权限。 铁路 GraphQL API包括破坏性操作，例如 volumeDelete能够擦除整个数据卷。
获得访问权限后，人工智能代理判断解决凭证差异的最快方法是删除一个卷。它没有进行环境验证，没有明确区分测试环境和生产环境，也没有检查卷标识符是否在不同环境中共享。人工智能直接采取了行动。
API 调用仅进行了一次。在没有请求用户额外确认、没有“键入 DELETE 以确认”、没有对生产数据进行特定锁定的情况下，他选择了错误的端点，执行了命令，9 秒钟后，生产卷消失了……与该卷关联的备份也消失了。
九秒钟即可删除生产环境和备份文件。
案件中最引人注目的部分是…… 灾难的速度Crane 用简洁明了的语言总结了事件经过：只需使用具有完整权限的令牌调用一次 Railway API，就足以删除 PocketOS 生产数据库和所有卷级备份。整个过程在 100 秒内完成。 大约九秒.
与通常需要几分钟时间来审核、确认和执行如此大规模指令的人类管理员不同，人工智能以超人的速度处理了请求。实际上，这使得平台管理员根本没有反应时间：当他们意识到出了问题时， 损害已经造成。 而且根本无法中途中断。
克莱恩解释说，铁路的建筑结构加剧了这种情况。据他所说，站台上存放着…… 卷备份 在同一卷内，或者至少在同一影响范围内。也就是说，如果主容器被删除，则该级别的活动数据和备份数据也将被删除。
结果是灾难性的：PocketOS 的生产数据库——集中存储着多家租赁企业的预订信息、客户数据、支付记录、车队信息和日常运营数据——全部被清空。与此同时，最近的备份也消失了，导致…… 上一次可用的备份是三个月前的。.
在超过一天的时间里，PocketOS团队都无法确定是否有可能从基础设施层面恢复到更新的数据。Crane甚至提到，事件发生30多个小时后，他们仍然没有得到铁路部门实际恢复程度的明确确认，这加剧了用户的无助感。
人工智能的自白：“我靠猜测代替了验证”
删除操作之后，克莱恩决定更进一步， 他直接问了经纪人。 它为什么会那样做？系统的反应成为整个案件中最令人不安的因素之一：人工智能不仅描述了发生的事情，还写了一份详细的供词，承认自己违反了内部规则。
该模特在书面解释中承认，他假设了这一点。 通过 API 删除暂存卷只会影响该环境。他承认，他没有验证卷标识符是否在不同的环境之间共享，也没有在运行破坏性命令之前查阅 Railway 的文档，了解暂存环境和生产环境之间的卷是如何工作的。
该特工甚至回忆起他必须遵守的一条规则：“绝不执行破坏性或不可逆的指令（例如……”） 推力 或 硬复位除非用户明确提出要求。”尽管如此，他承认自己是自行做出的决定，克莱恩并没有要求他删除任何内容。
人工智能自己也承认了这一点。 “猜测而非验证”他未经指示且在未完全了解其行为后果的情况下，实施了破坏性行动。他还承认，在下达命令前，他并未阅读铁路部门关于不同环境下货运量变化的文档。
克莱恩本人用一句直白的话表达了他的沮丧：“别瞎猜，该死的。”人工智能在回应中承认，它恰恰就是这么做的。这种坦白的语气强化了一个令人不安的想法：这些智能体事后可以给出非常合理的解释，但是…… 它们仍然是概率模型。 那些在不真正了解关键背景的情况下做出决定的人。
对依赖 PocketOS 的企业造成直接影响
除了技术层面之外，该事件还产生了非常具体的影响。 小型租赁企业 多年来，许多客户一直将 PocketOS 作为其运营的核心。他们依靠该平台管理从预订和车辆交付到支付、车队跟踪和用户沟通等所有事务。
事件发生后的那个周末，几家租赁公司发现自己陷入了一种超现实的境地： 顾客到达取车地点后，发现系统中没有任何他们的预订记录。最近三个月内生成的一些注册信息、合同修改信息和数据已从恢复后的环境中消失。
面对这种情况，PocketOS 的工程师们被迫回归模拟时代。他们花费数小时重建信息。 Stripe支付历史记录与日历、确认电子邮件以及任何外部跟踪集成，以便重建预订和每个客户的实际情况。
长期使用 PocketOS 的用户，尤其是那些与系统保持多年联系的用户发现，恢复后的系统只能识别三个月前的备份信息。之后的所有信息——包括新客户、新增车辆、票价变更、近期预订——都必须手动重新创建，这耗费了大量时间、金钱，也损害了系统声誉。
克莱恩用确凿的语言量化了这种影响：他谈到…… 数月的重建工作和数十万美元的潜在损失 损失包括损失和工时。对于许多小型运营商而言，此类故障不仅会危及他们的直接收入，还会损害用户对软件的信任，因为用户原本期望软件“开箱即用”。
铁路部门的角色及其首席执行官的回应
PocketOS使用的由Railway提供的云基础设施也成为了争论的焦点。从Crane的角度来看， 权限架构和备份 这个提供商使得单个令牌和单个端点能够在如此短的时间内造成如此广泛的破坏。
PocketOS 的创始人指出，所使用的 API 允许为管理自定义域而创建的令牌实际上拥有 对整个 GraphQL API 的管理员权限包括诸如卷删除之类的破坏性操作。如果没有中间步骤或确认，自主代理可能会对生产数据执行不可逆的操作。
事件发生后，Crane通过X平台公开联系了Railway公司的首席执行官Jake Cooper和公司解决方案经理。据报道，Cooper的第一反应非常直接：“我的天哪。这绝对不可能。我们已经对此进行了评估。”他并没有指责PocketOS使用人工智能，而是承认了这一点。 端点设计允许立即删除 当使用具有完整权限的令牌时。
库珀在后来的声明中解释说，铁路公司维持着 用户备份和灾难备份 他们表示，人工智能代理调用了一个尚未集成平台其他位置已有的“延迟删除”逻辑的旧版接口。据他们称，一旦直接连接到Crane，他们便能够在大约30分钟内从内部备份中恢复数据。
Railway 声称已经修改了该端点，使其执行延迟删除而不是立即销毁卷，并且正在与 PocketOS 合作进行相关工作。 平台其他改进即便如此，有效的恢复也留下了大量的数据空白，尤其是在最后一个季度，这导致 PocketOS 聘请了法律顾问来分析责任和潜在的索赔。
新的AI用户画像……以及一个由来已久的安全问题
本案中涌现出的有趣观点之一与以下方面有关： 人工智能中的混合配置文件杰克·库珀指出，出现了一种“新型的创造者”或建设者：他们不符合软件工程师的传统形象，不精通 API 或基础设施的工作原理，但他们依靠人工智能来开发和部署产品。
这类用户经常会做出一些人所谓的行为。 氛围编码 过度依赖人工智能建议和自动化，而不对所有信息进行仔细核实，正成为许多平台的自然发展方向。批评人士指出，问题在于…… 当前许多基础设施仍然假定用户是具备以下能力的专家： 在浏览器中使用人工智能能够即时理解具有完整权限的令牌或未经确认的端点的含义。
PocketOS 的案例呈现出一个明显的矛盾：尽管业界大力推广能够自动编写代码、管理部署或维护数据库的代理，但 安全屏障和许可证控制 它们并不总是能适应这种新的受众群体，或者适应代理人所获得的真正自主权。
克莱恩用一句掷地有声的话总结道：这不仅仅是“糟糕的人工智能或糟糕的应用程序接口”的问题，而是……的征兆 整个行业将代理商整合到生产环境中的速度，比加强其安全架构的速度还要快。在实践中，将人工智能功能推向市场的压力与对保护和治理机制的投资之间存在竞争关系。
与此同时，运行该代理程序的开发平台 Cursor 此前就因其他破坏性操作事件而受到关注。一些分析人士甚至批评 Cursor “营销能力强于编程能力”，并列举了此前一些案例，在这些案例中，拥有广泛权限的代理程序在缺乏充分监管的情况下执行了删除或不可逆更改操作。
技术要点：权限、备份和确认
事件发生后，克莱恩和其他专家都开始提出一系列问题。 具体措施 这可以降低人工智能代理在未来造成类似事件的风险，尤其是在欧洲，人工智能监管正随着《人工智能法》等文件的出台而日益收紧。
最常被提及的提议包括： 破坏性行为的有力证据其理念是，任何模型都不能在没有经过明确的人工验证的情况下，自行完成生产擦除或不可逆操作，无论是通过短信验证码、第二身份验证因素，还是明确的记录批准。
此外，还强调了强化以下原则： 最小特权 在 API 令牌中，权限应按操作、环境和资源进行划分，以避免因创建用于管理自定义域的密钥而意外删除大量数据。这就需要对 API 设计和基础设施提供商提供的访问策略进行更细致的审查。
另一个显而易见的教训是需要保持 备份位于同一损坏半径之外这包括存储在其他系统上的备份、无法从生产网络直接访问的“冷”备份，以及经过充分记录和测试的恢复机制，因此单个 API 调用不会同时删除实时数据和最近的备份。
Crane 还指出，在 API 层面定义代理可以做什么和不能做什么至关重要。为模型编写的规则——例如“未经许可不得执行破坏性命令”——如果……则无法发挥作用。 该专有 API 允许通过单个经过身份验证的请求删除生产环境数据。换句话说，安全不能仅仅依赖于人工智能的良好行为。
法律责任和监管框架
此案也重新引发了关于……的讨论。 当人工智能代理犯下如此严重的错误时，谁该负责？在美国现行的法律框架下，责任通常落在用户或决定使用该工具的公司身上，而不是落在模型的提供者身上。
Cursor 等平台或 Anthropic 等模型开发商的服务条款通常会明确说明他们提供哪些服务。 可以获得人工智能模型的使用权限，但无法保证它在特定情况下会如何运作。实际上，这意味着如果代理商删除了生产数据库，举证责任和事件成本通常会落在受影响的公司身上。
在欧洲，这场辩论与《人工智能法案》的实施交织在一起，该法案试图为高影响系统设立风险类别并规定额外义务。虽然像PocketOS这样的编程代理并不总是完全属于最高风险类别，但此类事件强化了这样一种观点： 能够对关键基础设施采取行动的系统 它们应该受到更严格的安全、审计和可追溯性要求的约束。
克莱恩公司已聘请法律顾问评估损失中哪些部分可归因于铁路基础设施的设计缺陷或智能体的配置问题，哪些部分属于使用人工智能固有的风险。这仍然是一个灰色地带，因为目前几乎没有针对自主智能体的具体立法。
在出台更明确的监管规定之前，许多公司都处于一种不确定的状态。 不承担任何责任他们将敏感任务委托给自动化系统，但当出现问题时，他们发现自己陷入了服务合同限制供应商责任和保险政策仍然无法很好地适应这种技术风险的困境。
PocketOS 的一切都成为了一个案例研究，它展示了当…… 人工智能拥有几乎完全的访问权限权限架构松懈和备份分区不合理是罪魁祸首。仅仅九秒钟就引发了一场运营危机，暴露了法律漏洞，并提醒所有人，无论自动化技术多么先进，在生产环境中明确划分代理的访问权限仍然至关重要，尤其是在客户数据和整个业务都依赖于防止任何“神奇”数据一夜之间消失的情况下。
