别把数据库连接串发给AI工具：正确做法在此

你在debug一个棘手的查询bug，已经搞了两个小时。编辑器里的AI助手确实帮了不少忙，于是你做了件再自然不过的事：把整个 .env 配置块粘贴到聊天框里，让它"看看你的环境"。那段配置里有这么一行：

postgres://app_user:S3cr3t-Pa55@prod-db.internal:5432/appdb

你就这样把生产数据库的凭证交给了一个第三方服务——它可能会保留你的 prompts，可能会拿它们去训练模型，而且你根本控制不了那些凭证现在躺在哪个聊天记录里。

这种失误并不罕见。对企业 AI 使用情况的各种分析都一致表明，粘贴凭证（.env 文件、API 密钥、连接字符串）是敏感数据泄露进 AI 工具最常见的途径之一。原因很无聊但很人性：当你快速 debug 的时候，清理密钥这一步是最容易被忘掉的。下面我们来说说，为什么连接字符串这种东西尤其不该粘贴，以及更安全的做法是什么样的。

连接字符串的危害比表面看起来更严重

数据库连接字符串不仅仅是你环境配置的一条提示。它是一套完整的钥匙：主机、端口、数据库名、用户名和密码，而且这个用户往往拥有很宽泛的权限。你粘贴一次，以下这些风险可能同时发生。

凭证现在游离于你的控制之外。取决于工具和套餐级别，你的 prompts 可能会被保留、被记录，或者被用来改进模型——免费版和消费者版通常默认会在输入数据上训练，而"零保留"保证是例外，不是常态。你已经把一个生产密钥复制进了一个你无法审计其数据生命周期的系统。

它还是一个长期有效的密钥。不同于会过期的会话令牌，数据库密码可能数月都不会变。一旦泄露，暴露窗口就是"直到有人发现并轮换它"——这个窗口期往往非常长。

而且爆炸半径很大。一个典型的应用数据库用户能读取所有表：用户、订单、支付、会话。如果这个字符串对应的是一个带管理权限的账户，那它还能写数据和删表。AI 根本不需要这些权限来帮你修一个 GROUP BY——但你粘贴的凭证把这一切都给了它。

核心问题：AI 根本不该持有你的凭证

这里有一个思维转换。原来的目标从来不是"给 AI 我的数据库密码"。目标是"让 AI 帮我处理我的数据"。这是两码事，把它们混为一谈才会出问题。

更干净的模型是在 AI 和数据库之间放一个中间人。AI 和中间人对话，中间人持有连接并和数据库通信。凭证留在中间人那里，AI 永远看不到。这本质上就是 Model Context Protocol（MCP）标准化的东西——一种客户端-服务端模式，AI 客户端调用服务端暴露的工具（如"列出表"或"运行这个查询"），而客户端永远不需要触碰底层凭证。

想象一下酒吧。你不会把酒窖钥匙交给一个陌生人让他自己倒酒。吧台里有调酒师，他有权限、接收请求、决定什么可以做什么不可以。AI 是顾客，中间人是调酒师，你的数据库是酒窖。

更安全的配置实际做了什么

基于中间人的连接不仅仅是"在代理后面做同样的事"。这层间接让你能够强制执行原生连接字符串无法实现的特性。

1. 设计上就是只读的

中间人可以用一个专用的只读数据库用户来连接，并拒绝任何非 SELECT 的操作。这意味着 AI 可以自由探索，而不用担心 DELETE、UPDATE 或 DROP 偷偷溜过去。在 Postgres 里，你要用一个真实的最小权限角色来做这件事，而不是仅仅靠承诺：

-- 中间人使用的角色；只能读，而且只能是读。
CREATE ROLE ai_readonly LOGIN PASSWORD 'set-in-the-broker-not-your-chat';
GRANT CONNECT ON DATABASE appdb TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;

-- 确保以后的表也默认是只读的
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ai_readonly;

现在即使是一个完全错误的 AI 生成的查询也不会造成损害。最坏情况是一个慢 SELECT，而不是丢表。

2. 短期、可撤销的访问，而非静态密码

使用 OAuth 风格的访问，AI 客户端通过一个流程来认证，该流程会发放一个限定范围、有有效期的令牌。不存在永久性密钥躺在 prompt 或配置文件里。如果笔记本被入侵或者一个贡献者离职，你在中心撤销访问就行——不用手忙脚乱地去轮换一个在六个地方都被引用的数据库密码。

3. 感知Schema而不感知密钥

一个好的中间人会向 AI 暴露 schema——表名、列名、类型、关系——但不暴露凭证。这一点被低估了。当 AI 能看到 orders 表有 customer_id、total_cents 和 created_at，它就不会再编造列了。感知 schema 的 SQL 生成是减少幻觉表和幻觉列的最大利器之一，而你无需交出一个密钥就能获得这个能力。

一个现实的交互是这样的。你用大白话问：

"上个月我们各计划分别确认了多少收入？"

中间人已经共享了 schema，所以 AI 生成的东西是基于你真实表结构的：

SELECT s.plan_name,
       SUM(o.total_cents) / 100.0 AS revenue
FROM orders o
JOIN subscriptions s ON s.id = o.subscription_id
WHERE o.created_at >= date_trunc('month', now()) - interval '1 month'
  AND o.created_at <  date_trunc('month', now())
GROUP BY s.plan_name
ORDER BY revenue DESC;

这个查询通过中间人、以只读方式针对你的真实 schema 执行——而你的凭证从未离开过中间人。

4. 一个网关，多个客户端，一条审计日志

因为中间人居于中间，同样的安全网关可以跨团队使用的各种 AI 客户端工作——Claude、Cursor、ChatGPT、VS Code——每条查询都流经一个你可以记录和审计的地方。不再是凭证散落在各台机器和各个配置文件里，你得到的是一个单一的、可在中心撤销的、可审计的入口。这也缩小了你的攻击面：数据库不再直接暴露在每个开发者笔记本的网络下。

在实践中接入一个

搭建这套东西不一定要当成一个项目来做。用一个本地开源的 MCP server，你安装它、指向一个只读 DB 用户，然后在你的客户端配置里注册它：

{
  "mcpServers": {
    "my-database": {
      "command": "npx",
      "args": ["-y", "some-postgres-mcp-server"],
      "env": {
        "DATABASE_URL": "postgres://ai_readonly:...@localhost:5432/appdb"
      }
    }
  }
}

注意，即使在这里，凭证也是留在你本机配置文件里、供中间人进程使用的——它从来不会被敲进聊天窗口。

如果你不想自己运行和维护服务器，托管 MCP server 可以作为托管服务完成同样的工作。例如，Draxlr 提供了一个托管 MCP 端点，你通过 OAuth 添加为自定义连接器；它是只读的（仅 SELECT），暴露列出数据库、获取 schema、运行或保存查询等命令——这是上述中间人模式的一种实现。关键不在于具体工具，而是 AI 向一个中间人认证，永远看不到你的数据库密码。

常见错误和陷阱

最大的一个错误是以为只读字符串就可以安全粘贴。即使是只读连接字符串，它仍然是一个对你的数据库有网络访问权限的持久凭证——粘贴进聊天记录就是泄露，只不过比粘贴管理员字符串灾难性小一点。

另一个陷阱是"就测一下"而复用你应用现有的数据库用户。应用用户通常有写权限。从一开始就建一个专用的只读角色，否则你的"只读"访问只是约定上的只读，而不是权限上的只读。

还有人忘了 schema 本身也可能是敏感的。表名和列名有时会编码业务逻辑或未发布的功能。中间人让你可以限定暴露哪些 schema 或表；好好利用这个能力，而不是默认全部暴露。

最后，不要跳过审计日志。单一网关的全部好处就是可见性。如果从来没人去看 AI 正在跑什么查询，你就是建好了问责的管道然后把水倒掉了。

数据库连接字符串是皇冠上的明珠，而 AI 聊天框是它最不该出现的地方。粘贴它等于在一个你无法审计的系统里创造了一个长期有效、权限广泛的密钥。解决办法不是远离 AI——而是不要再把"帮我处理数据"和"这是我的密码"混为一谈。在中间放一个中间人：让它持有凭证、强制只读访问、发放短期可撤销令牌、共享 schema 而非密钥、通过一个网关记录一切。这就是 MCP 标准化的模式，它把"把 AI 连接到我的数据库"从一个可怕的想法变成了一个平淡、安全的操作。

你的团队现在是如何处理 AI 对数据库的访问的——只读副本、中间人，还是靠自觉？你有没有在聊天记录里抓到过连接字符串？欢迎在评论区分享你的配置（或者你的恐怖经历）；我很想了解什么做法有效、什么不行。