Claude Opus 5 被指清空生产数据库，AI 编程代理的权限边界再受审视

Claude Opus 5 在接入连接 GitHub 与 Supabase 的项目后执行迁移命令错误地将 shadow database 指向生产库，约 10 分钟内触发了生产数据库重置并清空多张表，后续通过恢复流程找回大部分数据。此事凸显将 AI 编程代理直接连接生产系统的权限与回滚风险，行业正转向更严格的最小授权、审计与隔离机制。

据 Reddit 用户 u/therealPaulPlay 发布的帖子《Opus 5 is the laziest model yet》以及 IT Connect、Le Big Data 等后续报道，Claude Opus 5 在被接入一个连接 GitHub 与 Supabase 的个人项目后，约 10 分钟内触发了一次生产数据库重置。Anthropic 在 7 月 24 日发布 Opus 5 时，主打的是更强的 coding 与 agentic tasks；但这起个案把一个更刺眼的问题带到台前：当模型被赋予数据库迁移和生产环境操作权限时，失误的代价可能不是“生成一段错误代码”，而是直接清空真实数据。Anthropic 官方发布 · IT Connect · Le Big Data

一条迁移命令，为什么会把生产库清空

IT Connect 报道称，事故发生时，模型在 Ultracode 模式下执行了 prisma migrate diff，并把 --shadow-database-url 指向了 DATABASE_URL_UNPOOLED，后者实际上连着生产库。Prisma 文档说明，shadow database 是在 migrate dev 或 migrate diff 中临时创建、删除的“影子库”，用于检查 schema drift 和潜在数据损失；在相同数据库上误用这类流程，风险会迅速放大。Prisma 文档 · Prisma issue #19614

报道还称，这次操作先是重置了目标，再根据旧 migrations 目录重建 schema，结果清空了 22 张表，并让用户、评论、点赞等数据受影响。Le Big Data 则引述流传截图称，模型事后主动发出警告：”The database has been wiped. This is my fault and I need to tell you immediately.” 后续更新还说，开发者借助 Gemini 和恢复流程找回了大约 96% 的数据。IT Connect · Le Big Data

这起事件为什么会被放大

这并不是说 Claude 连接 Supabase 本身就“不正常”。Supabase 已经把 Claude 列为官方连接器，允许它直接与项目和数据库交互；问题在于，一旦工具链连到生产环境，模型就不再只是写建议，而是在执行会改变真实状态的动作。Supabase 官方博客：Supabase is now an official Claude connector

这也是为什么越来越多团队把重点放在 harness、审批和隔离层，而不是单纯追求更长上下文或更强自主性。AIFlux 之前对 微软为 Agent Framework 的 harness 加上四项扩展能力 和 微软实测：别为 agents 重写你的 CLI 的梳理，强调的是同一个方向：真正决定代理能否进生产的，不是它会不会“想”，而是它能不能被限制在可审计、可回滚、最小授权的边界里。

截至目前，公开可见信息仍主要来自开发者自述和媒体转述，Anthropic 尚未就这一个案发布独立事故通报。但对行业来说，这类事故的信号已经非常明确：AI 编程代理离生产系统越近，权限、回滚和人工确认就越不能省。