AI 连接数据库的账号，为什么必须先收回写入权限？

给 AI 问数工具接数据库时，最危险的快捷方式是复用管理员账号。OWASP 在“大模型应用过度代理”风险中明确举例：只需读数据的扩展若持有 INSERT、UPDATE、DELETE 权限，模型被误导或工具出错时，影响范围会被放大。连接账号应从数据库层先变成只读。

只读不是一句提示词

“请不要修改数据”只影响模型行为，不能约束一个已经拥有写权限的连接。应创建专用服务账号，只授予获批库、表或视图的 SELECT；禁止建表、修改、删除、调用危险存储过程。数据库侧的授权应能独立拦截越界操作。

受控视图适合把敏感列移走、固定业务过滤条件，也便于后续调整字段。若在生产库直接跑复杂分析，还要单独限制超时与资源占用。

产品层与数据库层互相补位

AskTable 文档说明，其 SQL 校验拒绝写操作、DDL 和 SELECT *，并在执行前施加行级与字段级权限。这是产品侧的控制；数据库只读账号则是另一道边界。两者同时存在，比只依赖其中一层更容易审计和解释。

产品策略决定“这个人此刻能看哪些数据”，数据库账号决定“服务本身最远能做什么”。不要把两种授权混为一谈。

上线前做失败用例

请 DBA 尝试用该服务账号执行 UPDATE、DELETE 和读取未授权表，预期都应失败。再用 AskTable 普通角色提出修改数据或查询敏感列的请求，检查响应和数据库审计记录。

测试时使用隔离环境与无敏感样本，不要在生产环境故意发写入语句。最终保留账号授权清单和验证日期，后续每次扩大数据范围都重新审查。

别忘了密钥和退役流程

连接凭据放在企业认可的密钥管理设施中，明确轮换责任；停用旧智能体或更换数据源时撤销无用账号。长期不轮换的只读账号虽然不能改数据，仍可能被滥用于批量读取。

参考资料

• •OWASP LLM06 过度代理风险
• •AskTable 如何工作
• •AskTable 权限配置