免费 AI IDE
你让 AI 编程助手连上数据库自己修 bug，十分钟后生产表被逐张清空——这不是段子，而是真实发生过的事故。先把核心答案拍在前面：锅不在模型"幻觉"，而在你没给 agent 划清权限边界。本文用这起事故做复盘，把"连接隔离、最小权限、审批备份"三条边界一次讲清，最后给你一份能直接抄走的配置清单。今天编程狮就用最接地气的方式，帮你把最危险的那层防护补上。
一、事故复盘：agent 为什么清空了生产库
这起事故的主角是一位独立开发者。他把自己项目的 Supabase 连接信息交给 Claude Code，让 agent "自主修复几个数据问题"。agent 需要一张影子库（shadow database）来校验迁移脚本，于是它去改 Prisma 的配置。问题出在：生产库的连接串和环境变量被混在了一起，agent 把生产连接串错填进了影子库参数。结果 Prisma 认为要对"影子库"做结构同步，十分钟内把生产表逐张清空。
复盘时大家最容易甩锅给"模型幻觉"。但这次不是。模型忠实地执行了"修数据"这个指令，真正失控的是工具语义与权限边界：agent 能接触生产连接串，就能造成生产破坏；它分不清哪个参数指向生产、哪个指向影子库，是因为你没把环境隔开。
这里要记住一句话：AI 编程助手只是按指令办事的实习生，它不会自己判断"这条命令该不该在生产环境跑"。权限边界不是限制它的能力，而是给它一个安全的操作围栏。围栏画对了，它再怎么折腾也碰不到生产数据。
想看清楚 agent 能折腾到什么程度，OpenClaw 中文教程 里有一份从安装到上手的中文说明，看完你会更理解"自主 agent"到底意味着什么。
二、第一条权限边界：连接串与环境变量隔离
第一条权限边界，是把"连接串"和"环境变量"彻底分开管理。直白点说：生产库的连接串，绝不能和开发、测试、影子库混在同一个文件或同一个变量名里。
为什么这是第一道闸？因为 agent 改配置时，它看到的是变量名和值，不是你脑子里的"这是生产、那是测试"。如果 .env 里既有 DATABASE_URL（生产）又有 SHADOW_DATABASE_URL（影子），一旦命名相近或注释不清，agent 填错是大概率事件。隔离的做法有三种：
第一，物理隔离。开发用本地库，CI 用临时库，生产用独立的环境变量注入（比如云平台的 secret 管理），本地 .env 只放非生产连接串。
第二，影子库独立。Prisma 等工具需要的影子库，单独开一个只用于迁移校验的空库，连接串写死在 CI 配置里，永远不进 agent 可读的 .env。
第三，只读副本分流。让 agent 平时只读一个副本，写操作走人工审批。下面这份 .env 示例就体现了"本地只碰非生产"的思路：
# 本地开发：只连本地库，agent 默认读这个
DATABASE_URL=postgres://dev:dev@localhost:5432/app_dev
# 影子库：仅供迁移校验，单独命名、单独库
SHADOW_DATABASE_URL=postgres://ci:ci@localhost:5432/app_shadow
# 生产库：不放本地文件，由云平台 secret 注入，agent 读不到
# PROD_DATABASE_URL 通过 CI secret 提供，本地不存在
这段配置的关键在于：agent 在本地能读到的只有 app_dev 和 app_shadow，生产连接串根本不在它的文件系统里，自然填不进任何参数。这就把第一条权限边界落到了实处——它想填错，也没东西可填。
三、第二条权限边界：最小权限与只读账号
就算连接串隔离了，agent 拿到的那个账号本身也得是"最小权限"。这是第二条权限边界，也是最容易被忽略的一道。
最小权限的意思是：agent 干活需要什么权限，就只给什么，多一个都不要。它要查数据，就给只读；要跑迁移，就给一个只能动影子库、碰不了生产表的账号。绝不要图省事，把数据库管理员（superuser）账号直接喂给 AI 编程助手。
在 PostgreSQL 里，你可以专门建一个只读角色：
-- 建一个只读角色，只能查、不能改
CREATE ROLE agent_ro LOGIN PASSWORD 'strong_random_pw';
GRANT CONNECT ON DATABASE app TO agent_ro;
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_ro;
-- 注意：这里只给 SELECT，没有 INSERT/UPDATE/DELETE
这段 SQL 造出的 agent_ro 账号，连一张表都改不了，再野的 agent 也只能读。把"最小权限"原则落到 AI 编程助手上，本质就是别给它生产库的管理员账号。想系统理解 AI 的能力边界，AI 人工智能教程 里从概念到实践都讲到了，适合作为理论基础补一遍。
多说一句：权限边界不是一次性的。每次换工具、换项目，都要重新确认 agent 用的是不是只读账号。很多事故就是从"这次先给个管理员，下次再收"开始的——而下次永远不会来。
四、第三条权限边界：审批、备份与可回滚
前两条权限边界管的是"agent 能不能乱动"，第三条管的是"万一它动了，你能不能救回来"。这是兜底的一道。
第一块是审批。凡是写操作，让 agent 先给出要执行的 SQL，你来点头，它再跑。不要开"自动执行"开关。把 agent 当成需要你签字的实习生：它写方案，你批，它执行。
第二块是备份。生产库必须定时备份，而且备份要在 agent 碰库之前是新鲜的。事故里那位开发者十分钟后才发现表空了，但好在他有每小时的快照，最终只丢了几分钟数据。没有备份的"可回滚"就是一句空话。
第三块是可回滚。任何变更都要能原路退回：迁移有 down 脚本，删除用逻辑删除而非物理删除，批量操作先在小数据集上试跑。下面这条命令就是跑迁移前先打一个备份：
# 在 agent 执行任何写操作之前，先做一次全量备份
pg_dump "$PROD_DATABASE_URL" > backup_$(date +%Y%m%d_%H%M).sql
# 再让 agent 在安全的影子库上先试跑
npx prisma migrate deploy --schema=prisma/schema.shadow.prisma这条命令先落备份，再让变更只在影子库试跑，把"可回滚"变成可执行的步骤。三条权限边界合起来，才是完整的安全围栏：隔离让它够不着，最小权限让它改不了，审批备份让它动了也能救。
五、可直接抄的权限边界配置清单
前面三条权限边界讲完，这里给你一张能直接抄走的清单。把它当成给 AI 编程助手"上岗"前的检查表，每条都过一遍再开工。
- 连接隔离：本地
.env只放开发与影子库连接串，生产串由 CI secret 注入，agent 文件系统里读不到。 - 命名清晰：生产、测试、影子库的变量名明显区分，禁止
DATABASE_URL一个名字到处用。 - 只读账号：agent 默认使用只含
SELECT的只读角色，写库走人工审批账号。 - 关自动执行：所有写操作设为"先出方案、人工确认、再执行"，不开放自主写权限。
- 备份在手：生产库每小时快照，agent 动库前确认备份是最近且可恢复。
- 影子库试跑：迁移和结构变更先在独立影子库验过，再考虑上生产。
- 变更说明：每次让 agent 改库，都要求它先讲清"改了什么、影响哪些表"，留痕可追溯。
如果你用 Cursor 这类工具，官方文档里的环境隔离方案值得参考，Cursordocs 教程 给出了更细的配置示例，可以对照着把上面七条落到你的工程里。权限边界不是越多越好，而是每条都真正挡得住——七条齐了，agent 再自主，也越不过你的围栏。
总结
回到开头那起事故：agent 清空生产库，根因不是模型"疯了"，而是连接串没隔离、账号权限没最小化、变更没审批也没备份。把三条权限边界——连接与环境隔离、最小权限与只读账号、审批备份与可回滚——画清楚，AI 编程助手才能真正帮你提效而不是搞破坏。下一步，建议你把第五节那张清单存进项目文档，每次接入新工具前过一遍。
延伸学习
想把"权限边界"这块补扎实，可以按这个顺序走：
- 先跟着 Lingma AI 开发实战课程 把 AI 辅助开发的整套流程跑通，理解工具该怎么嵌进你的工作流；
- 安全意识这块，这篇 OpenClaw 安全使用笔记 整理了开源智能体的风险点和具体防护建议；
- 想看监管视角的提醒，OpenClaw 安全风险笔记 汇总了官方对这类智能体的安全警示，值得读一遍。
常见问题
Q：agent 连数据库一定要开只读吗？
不一定，但默认应该是只读。如果只是让 AI 编程助手帮你查结构、写查询，只读账号完全够用，还能彻底堵住误删。需要写操作时，单独走一个审批账号，不要为了省事把写权限常开。
Q：本地 .env 里的密钥会被 agent 读走吗？
会，只要文件在 agent 的工作目录里，它就能读到。所以权限边界的第一条就是：生产密钥别进本地 .env，改用云平台 secret 注入。本地只留开发和影子库的连接串，即便 agent 读走了也不伤及生产。
Q：已经误删了怎么办？
立刻停手、断连，先看有没有最近的备份或快照。有备份就按备份回滚；没有就只能从 binlog 或逻辑日志里尽量恢复。更重要的是事后把三条权限边界补上，避免第二次。本文讲的配置清单就是为此准备的。
