MCP 让智能体连数据库变得很容易，pgEdge Starfleet 这类产品甚至内置了 MCP server。但在你把生产库的写权限交给一个智能体之前，有些护栏必须先装好。
护栏一：只读要真的只读 这是最低要求，也是最容易出问题的地方。很多实现的「只读」只是在应用层不发 INSERT/UPDATE，但智能体可以通过调用存储过程、触发器、或者某些函数的副作用写数据。
正确做法是在数据库层面用只读角色和只读事务强制。SafeSession 这类机制做的就是这件事。另外连接串里的角色权限要定期审计。
护栏二：权限不继承、不提升 智能体 A 有读权限，它调用的工具或服务不该因此获得写权限。每个智能体的工具白名单独立配置，跨智能体调用时权限取交集而不是并集。
护栏三：敏感操作人工确认 写操作、DDL、DROP、批量 DELETE、外发数据，这些动作在智能体链路里不应该自动放行。
做法是给工具分风险等级：读操作自动执行，写操作暂停等待确认。这个暂停的成本很低，但能挡住绝大部分灾难。
护栏四：完整的调用链日志 出事后你要能回答：哪个智能体、在什么时间、因为什么指令、执行了什么操作、影响了多少行。
所以日志要记录的不只是 SQL，还有触发这个 SQL 的完整上下文——用户的原始请求、中间的智能体消息、工具调用参数。
护栏五：资源限制 智能体不知道「这个查询会扫全表」。要设：
- 查询超时。
- 返回行数上限。
- 单会话的查询次数上限。
- 对大表的访问告警。
关于数据库分支 如果要让智能体做 schema 变更，写时复制的数据库分支几乎是必需品。开分支成本接近零，改坏了删掉重来。没有分支的话，多个智能体并行改同一个库基本没法收场。
一个原则 把智能体当成一个能力很强、但没有判断力的初级工程师。你会给初级工程师生产库的 root 权限吗？不会。那也别给智能体。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。