MCP 安全：该让 Claude 或 Cursor 直接访问数据库吗？

先讲一个 2026 年越来越常见的场景。你一直用 Claude 或 Cursor 写应用。有人（也许是我，在之前的文章里）建议通过 MCP 把 AI 连到你的数据库，让它能回答关于真实数据的问题、设置视图、甚至管理表结构。它确实有用——我每天都在用。但在把 AI 助手接到生产数据库之前，有一个问题你应该深思熟虑地回答，而不是默认带过：

你到底在授予什么，授予给谁？

诚实的答案是："MCP 数据库访问"不是一回事。它是一条光谱，从"对开发数据库的无害只读探索"到"生产数据库凭证流经第三方基础设施"。你的配置的安全姿态取决于三个变量，在连接任何东西之前，你应该能说出全部三个。

变量 1：AI 的连接实际住在哪里？

这是最大的一个决定，也是最容易被搞错的一个，因为从外面看选项几乎一模一样。

直连（凭证在 MCP 配置里）。 最常见的配置：你运行一个 MCP 服务器进程，用存在配置文件里的连接串直接连你的数据库——claude_desktop_config.json 或 .cursor/mcp.json。AI 调用工具时，服务器执行查询。连接是本地的，但你的数据库凭证躺在明文配置文件里，而且只要进程在跑，MCP 服务器进程本身就有一条开放、高权限的到数据库的连接。如果那个进程被攻破——或者 AI 被诱骗执行破坏性工具调用——AI 和数据之间没有任何东西。

云中继（凭证在他们的服务器上）。 一些"把你的数据库连到 ChatGPT/Claude"的服务根本不本地运行。你通过网页面板把连接信息交给他们，他们从自己的基础设施连到你的数据库，你的 AI 客户端跟他们的云服务对话。现在你的凭证和数据都在别人的服务器上。这是两个世界最差的部分，也最难辩护。

本地应用 + 受管 MCP 服务器（凭证永不离开你的机器）。 这是我围绕 Basevolt 构建的配置：一个桌面应用持有你的数据库连接，它在 localhost 上暴露一个 MCP 服务器，你的 AI 客户端连上去。AI 从不见你的凭证——它跟本地应用说话，应用跟数据库说话。凭证文件问题消失，而且你得到一层真正可以控制访问的地方。

经验法则：AI 绝不应该持有你的数据库凭证，你的凭证绝不应该离开你的机器。 如果你的配置里任一条为真，你就处在光谱上危险的一端。

变量 2：AI 实际能做什么？

"MCP 数据库访问"可以意味着从"跑 SELECT 查询"到"删表"的任何东西。AI 能做什么的范围，是一个你正在做的安全决定，不管你有没有意识到。要问的问题是：这个配置最坏能做什么，我有阻止它的控制手段吗？

按重要性大致排序的控制手段：

只读模式。 如果 MCP 服务器支持，这是价值最高的单一控制。AI 可以查询和描述表结构，但不能写、不能改、不能删。对生产数据库，这是"AI 当分析师"和"AI 拿着上膛的枪"的区别。如果你要把助手接到任何有真实数据的东西上，从只读开始。

限定到特定数据源或表。 你大概连接了不止一个数据库——一个生产的和一个实验的，或几个项目。能选择 AI 能碰哪些，意味着一个地方的错误不会波及一切。

不执行任意 SQL。 一些 MCP 配置暴露结构化操作而不是原始 SQL——"创建视图"、"设置字段类型"、"列出表"——而不是"执行这个任意查询字符串"。这是有意义的改进：AI 能做有用的事，却不能运行它想到的任何东西。

撤销访问。 立即切断 AI 访问的能力——关应用、断开 base、关掉服务器——比你想象的重要。本地应用是一个按钮；云中继你只能依赖他们的管理面板和他们的节奏。

变量 3：AI 读取数据时，你的数据去了哪里？

这是人们忘记的部分。即使在完全本地的配置里，当 AI 回答关于你数据的问题时，查询结果会被发给 AI 提供商——这是 AI 能读到并回应的方式。这是这些工具运作的基础；模型需要看到数据才能谈论它。

所以真正的问题不是"我的数据离开机器了吗？"——任何 AI 助手，你问到的数据都会去模型那里。问题是你在问什么数据，你有权把它送到那里吗？ 如果你在探索一个用合成数据的本地开发库，这不是问题。如果你把助手接到有客户 PII 的生产数据库，你在把数据送到第三方的模型基础设施——这在你的政策下可能没问题，也可能是 GDPR/合同合规问题。在连接之前知道自己在哪种情况，而不是之后。

我实际会推荐的配置

给你一个具体的姿态，不只是原则。这是我为自己项目运行的配置：

本地应用（或本地 MCP 服务器）持有连接——绝不云中继，也绝不把凭证放在 AI 客户端的配置文件里。
生产数据库从只读开始。 如果你想让 AI 写入，先把它指向暂存或实验副本。"把列名改到错误表上的热心 agent"不是假设性故事。
把 AI 限定到它需要的 base。 如果 MCP 服务器允许你选择暴露哪些数据源，暴露最小集。
假设你问的一切都会去模型那里。 所以不要问助手关于你不该发给第三方的问题。这是抓住人的规则：架构没问题，数据才是问题。

最后一点值得强调，因为大多数"MCP 安全"讨论都在这里悄然结束：协议可以是本地的，凭证可以是安全的，你仍然可以仅仅通过问对问题就泄露客户数据。MCP 数据库访问的安全是三分架构加一分判断——而那一分判断是你的。

连接之前要问的问题

如果你要接 MCP 数据库访问，过一遍这些：

凭证住在哪里？ 如果答案是"在 AI 客户端的配置文件里"或"在中继的服务器上"，先修这个。
AI 能跑的最坏查询是什么？ 如果答案是"删掉一切"，在继续之前你需要只读模式或一个限定的数据库。
我会问什么数据？ 如果其中任何是客户数据，查一下你的政策对把它发给模型提供商是怎么说的。
我怎么撤销访问？ 如果它不是即时且本地的，那是个缺口。

这些不是稀奇的问题——它们是你会对任何能碰你数据库的集成问的同样问题。MCP 的不同在于表面更大：AI 助手比 cron 任务更有能力、更有创造力、更难预测。这正是值得深思熟虑的原因。

结论

MCP 数据库访问是 AI 工具浪潮里最有用的东西之一——我每天都在用，也写过在本地设置它和比较架构选项。但"有用"和"安全"不是一回事，两者之间的差距是你的责任。

好消息是：安全版并不比不安全版更难。一个本地 MCP 服务器，凭证由你自己的应用持有，对任何重要的东西只读，限定到它需要的数据库，加上每次对话前问一句"我乐意把这份数据发给模型吗？"的习惯——这个配置让你得到大部分价值，几乎没有任何风险。危险的版本不是防火墙配错的那个；是有人把有能力的 AI 连到生产数据库、却完全没问过这些问题的那个。