LLM 数据库只读账号为何会引发熔断，权限回收为何拖延36小时？

某团队在使用 Cursor 连接数据库查询 Schema 时，仅因只读账号权限过于宽泛，就触发了云厂商的“异常连接熔断”机制。主库只读副本因此宕机 40 分钟，后续的权限回收流程则更加复杂：跨越 DBA 手动执行 REVOKE、清理 连接池、修改 Terraform 配置 和轮换凭证，整个过程耗时 36 小时。

1. “超级只读”账号为何会引发熔断？

大多数团队在为 LLM 配置数据库访问时，通常会选择 db_owner 或“超级只读”权限，认为“仅查询 Schema 和数据，不涉及修改即可”。然而，LLM 在查询过程中会自动调用 pg_stat_activity、慢查询视图，甚至探测 pg_catalog.pg_authid，导致连接池中的闲置连接可能保留前一个 Session 的事务快照。一旦执行 REVOKE，旧连接并不会立即断开：它们仍能通过查询继续运行，直到通过 pg_terminate_backend 逐个终止进程才能完全清理。这意味着权限调整后，系统仍可能处于不稳定状态，进一步加剧了熔断风险。

2. 审计链路断裂，追责成本高昂

在实际应用中，凭证往往被硬编码在 .env 文件、环境变量或 Python 脚本中，导致应用层连接池无法区分 LLM 自动生成的请求 和 人工操作的请求。追责时，团队只能依赖应用层请求日志和模型调用链路，通过 时间戳对齐 来反推责任方。例如，一名数据分析师使用 LangChain 跑报表时，模型将 LIMIT 100 误改为 LIMIT 1000000，导致从库负载飙升。事后调查发现，仅凭“该时间段内仅该用户调用过 API”这一线索，耗时 两天 才能定性责任。

3. RLS 策略为何难以落地？

PostgreSQL 15+ 支持 Row Level Security（RLS），结合 SET ROLE 或 SET SESSION AUTHORIZATION 可实现租户隔离。但在实际部署中遇到多重挑战：

• ORM 工具（如 SQLAlchemy、Prisma、Django）对 SET ROLE 的支持不完整，需手动封装中间件；
• 连接池复用 时，执行 DISCARD ALL 会清空 Session 变量，导致 RLS 策略失效；
• DBA 普遍不信任应用层权限控制，坚持在数据库层创建 专用账号，增加部署复杂性。

4. 最小可行方案：动态凭证 + 连接池清理

为了降低运维成本，Vault 和 PgBouncer 可以配合使用，实现 15 分钟 TTL 的动态凭证和连接池清理：

# Vault 动态凭证，TTL 15 分钟
database:
  creds_path: "database/creds/llm-readonly"
  ttl: "15m"
  max_ttl: "1h"

# PgBouncer 连接池配置
pgbouncer:
  pool_mode: transaction
  server_reset_query: "DISCARD ALL; SET ROLE llm_guest;"
  admin_users: "pgbouncer_admin"

在 SQL 权限层面，需要精细化限制：

-- 仅授予 information_schema 和业务 Schema 读权限
REVOKE ALL ON ALL TABLES IN SCHEMA pg_catalog FROM llm_guest;
GRANT USAGE ON SCHEMA information_schema TO llm_guest;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO llm_guest;

同时，应用层 需要强制标记请求：

SET app.request_id = 'req_abc123';
SET app.actor = 'langchain-agent-v3';

关键优化点 包括：

• 凭证自动过期（15 分钟），避免手动 REVOKE；
• DISCARD ALL + SET ROLE 清除连接池脏状态；
• 仅授予必要 Schema 权限，系统表和统计视图 不可见；
• 应用层标记请求 ID，便于审计追责。

5. “只读”并不等同于安全

即使限制为 SELECT 权限，仍存在潜在风险：

• SELECT pg_sleep(10000); 可长时间占用库资源；
• SELECT * FROM pg_largeobject; 可能读爆磁盘；
• SET enable_seqscan = off; 可干扰查询优化器。

唯一可行方案 是严格限制权限范围，仅授予特定 View，并配置 statement_timeout = 5s 和 RLS 按 request_id 限行。这样才能在确保 LLM 查询功能的同时，最大限度降低风险。