速记engineeringsecuritydatabase

给 AI 编码助手数据库权限：最小特权

助手若持有生产写权限，误操作成本极高；用只读账号与本地工具降低风险。

约 813 字 · 2 分钟读完

背景

AI 编码助手（IDE Agent、脚本化 Agent）常被授予仓库读写与终端权限，以便改代码、跑测试、看日志。效率上来之后，下一步很容易变成：「把数据库也接上，让它自己查、自己改。」

若助手持有 生产库写账号，一次错误的 UPDATE/DELETE、一次指错环境的迁移，影响面会远大于一次失败的单元测试。问题不在「模型聪不聪明」，而在 权限边界有没有被当成一等公民设计。

要点

  1. 环境隔离：开发 / 预发 / 生产凭证分离；助手默认只拿本地或开发库。
  2. 最小特权：助手用只读角色看 schema 与样本数据；结构变更走迁移脚本 + 人工 Approve。
  3. 可审计：SQL 与迁移进 Git；禁止「对话里直接对生产执行未审查语句」。
  4. 连接信息先辨认：主机名、库名、账号角色看清楚，再决定是否允许自动化。

「能写代码」不等于「该写生产数据」。把这句话写进团队约定，比事后找回误删数据便宜得多。

怎么做

推荐的默认姿势：

Agent 账号：SELECT 为主（必要时加有限 EXPLAIN）
迁移 Job：CI 中受控运行，需人工 Approve
生产写：仅部署角色 / DBA 流程，不进日常 Agent 会话

具体检查项：

  • 连接串里是否误用生产主机？（用本地工具拆开看）
  • 助手环境变量是否混入生产密码？
  • 是否存在「为了省事」把 GRANT ALL 给了个人账号？
  • 回滚方案是否写在迁移说明里？

本地演练迁移时，用容器或快照库；确认脚本幂等后，再进受控流水线。不要让 Agent 在对话中「顺手」连生产热库做试验。

和本站工具

排障与评审前，先在浏览器里把语句和连接信息看清楚——本站工具默认 本地运算、数据不上传（见首页「0 上传」与 隐私说明）：

更多入口：Tools。

补充一条常见误区：把「只读」理解成「不能改业务表」却仍开放 DROP/CREATE 或文件系统写路径，风险同样很大。权限矩阵要按对象细化：表级、schema 级、是否允许 DDL、是否允许访问密钥列。开发库也建议定期刷新脱敏快照，避免助手在开发环境接触真实用户隐私字段。

出现误操作演练时，优先验证：备份可用、回滚脚本可跑、告警能叫人。文档里写清「Agent 禁止事项」三五行，比口头叮嘱可靠。把这些约定和本站「数据不上传」的本地工具习惯放在一起，团队会更容易形成一致的安全手感。

小结

给 Agent 的数据库权限，应按 事故半径 设计，而不是按「能不能跑通 Demo」设计。只读默认、迁移受控、生产写离开日常会话；再用本地工具预处理样例。这样助手仍然提效，却不会一句话毁掉生产数据。

← 全部速记