AI连接数据库：OAuth令牌为何比静态密钥更安全

你想让你的 AI 助手回答关于你生产数据的问题。所以你做了显而易见的事：拿到数据库连接字符串，粘贴到工具配置里，然后继续。它能工作。AI 开心地运行 SELECT 语句，然后把数字交给你。

这就是问题所在。那个连接字符串——postgres://app_user:s3cr3t@db.internal:5432/prod——现在躺在一个配置文件里，可能在聊天记录里，可能在云端同步的设置 blob 里。它永不过期。它授予该数据库用户能做的任何操作。如果它泄露了，攻击者就能访问你的数据库，只要密码有效——通常是"永远，直到有人发现"。

这是将 AI 连接到数据库的核心矛盾。访问的方式比大多数团队意识到的更重要。2026 年，实际的选择归结为两种模式：长期有效的静态凭证或短期可撤销的 OAuth 令牌。让我们看看为什么它们的行为如此不同，以及这对将 AI 助手连接到真实数据意味着什么。

静态凭证的问题

静态凭证是一个秘密，只要你不手动更改它就能工作：数据库密码、API 密钥、个人访问令牌。设置简单，这就是为什么它们无处不在。截至 2026 年初，公共 MCP 注册表中的服务器仍有约 91.5% 依赖静态密钥或根本没有身份验证——只有约 8.5% 使用 OAuth。

问题是静态凭证不提供的东西：

无过期机制。 如果密码通过泄露、钓鱼攻击或意外提交而暴露，攻击者的窗口一直敞开，直到有人手动轮换它。行业报告描述了泄露的长期凭证授予了数月甚至数年的访问权限。

无身份标识。 一个共享密钥无法告诉你哪个 AI 代理或哪个用户在发起查询。你无法区分是 Claude、Cursor 还是凌晨两点有人写的脚本。

全有或全无的撤销。 因为大家共享同一个密钥，你无法在不轮换凭证的情况下切断单个客户端，那样会同时破坏所有其他集成。

范围过广。 连接字符串通常携带通用应用用户的权限——往往远超"读取几个表用于报告"所需的范围。

这不是假设。仅 2026 年第一季度，就发现了数万个配置错误的 AI 工具服务器暴露在公共互联网上，泄露了 API 密钥、凭证和聊天历史。那些日志中的每一个长期密钥都是一张开放邀请函。

OAuth 如何改变模式

OAuth 颠覆了这种关系。你不再给 AI 工具一个永久密码，而是让它通过一个授权流程，颁发一个精确限定操作范围的短期访问令牌。数据库密码永远不会接触到 AI 工具。

AI 访问的现代基准是 OAuth 2.1 配合 PKCE（Proof Key for Code Exchange），这是 Model Context Protocol 为远程服务器推荐的方案。流程如下：

1. AI 客户端请求访问数据库网关。
2. 网关将用户重定向到登录并同意。
3. 客户端 + 网关交换 PKCE 代码——传输中无共享密钥。
4. 网关颁发短期访问令牌（几分钟到约 1 小时）
   和一个刷新令牌。
5. 客户端在每个请求中发送访问令牌。
6. 令牌自动过期；刷新流程颁发一个新令牌。

PKCE 很重要，因为它保护代码交换免受拦截，即使客户端无法安全存储密钥——这正是大多数 AI 工具的描述。结果是访问默认情况下是临时的。

直接比较两种模式：

最后一行是最重要的一行。使用 OAuth 时，经纪商或网关持有真实数据库凭证，AI 工具只看到一个有限范围的、临期的令牌。泄露的爆炸半径从"整个数据库，永远"缩小到"读取权限，仅接下来的几分钟"。

范围和最小权限

短期并非唯一的优势——OAuth 令牌也是受限范围的。令牌可以携带声明，说明"此会话可能对 analytics schema 运行读取查询"，仅此而已。一个设计良好的网关会强制执行：报告用的令牌永远不能运行 UPDATE、DELETE 或 DROP。

这与团队实际希望 AI 访问数据的方式很好地对应。大多数报告和探索工作负载是只读的：

-- 适用于 AI 报告会话
SELECT date_trunc('week', created_at) AS week,
       count(*) AS signups
FROM   users
WHERE  created_at >= now() - interval '90 days'
GROUP  BY 1
ORDER  BY 1;

-- 只读范围应该直接拒绝的东西
DELETE FROM users WHERE created_at < now() - interval '2 years';

使用静态 app-user 连接字符串时，第二个查询在 AI 决定写它时就能运行。使用受限的只读令牌时，网关会在其到达数据库之前拒绝它。

经纪商/网关的实际形态

你不需要从零开始构建 OAuth。常见的模式是一个托管网关，坐落在 AI 客户端和你的数据库之间。你连接一次作为自定义连接器；它处理 OAuth 流程、持有凭证、执行范围，并暴露安全操作如"列出数据库"、"获取 schema"、"运行查询"和"保存查询"。托管 MCP 服务器如 Draxlr 的实现正是这样做的——OAuth 连接、只读（仅 SELECT）、数据库密码保留在经纪商上——但模式才是关键，在整个生态系统中你会找到相同的形式。

AI 客户端的通用连接器配置大致如下——注意里面没有任何密码：

{
  "mcpServers": {
    "analytics-db": {
      "url": "https://gateway.example.com/mcp",
      "auth": "oauth"
    }
  }
}

AI 客户端打开那个 URL，被重定向到登录、同意，然后收到一个令牌。你的 prod 密码永远不会出现在文件、聊天记录或同步设置中。

常见错误和陷阱

把 OAuth 当作"设置后忘记"。 刷新令牌也可能是长期有效的。要轮换它们，在可疑活动时撤销——OAuth 给了你撤销的能力，但你仍然需要使用它。

请求广泛的权限范围"以防万一"。 那就违背了要点。只读时只请求只读权限。

跳过 HTTPS。 符合规范的远程 MCP 服务器需要在每个端点上使用 HTTPS。在明文 HTTP 上发送的令牌可以被嗅探。

假设 JWT 可以立即撤销。 签名 JWT 在本地验证而不需要数据库查询（很快），但这也意味着它们在过期前一直有效。对于高敏感操作，使用令牌 introspection 或不透明令牌，以便撤销是立即生效的。

将数据库直接暴露在网络上。 即使在应用层有 OAuth，也不要让每台机器都能访问 DB 端口。网关应该是唯一与数据库通信的东西。

结论

授予 AI 对数据库的访问权限是一个安全决策，而不是配置细节。静态凭证设置简单但危险：它们不过期、无法识别调用者，单次泄露永久有效。OAuth——特别是带 PKCE 的 OAuth 2.1——给你短期、受范围限制、可集中撤销的令牌，并将实际数据库密码保留在 AI 工具永远看不到的经纪商身后。

如果你今天要将 AI 助手连接到真实数据，清单很简单：保持数据库密码远离 AI 工具，优先使用短期令牌而非永久密钥，将访问权限限制为只读（除非有充分理由不这样做），并确保你能撤销单个客户端而不破坏其他一切。

你现在如何处理 AI 对数据库的访问——粘贴连接字符串，还是通过 OAuth 经纪访问？是什么阻止了你切换？我很想在评论中听到其他团队是如何处理这个问题的。

来源：Curity — API 安全趋势 2026，LastPass — 管理 AI 代理凭证，Stytch — MCP 身份验证和授权指南，Aembit — MCP、OAuth 2.1、PKCE 和 AI 授权的未来，Token Security — 短期凭证。