文章警示AI代理连接数据库的安全风险。强调MCP服务器是核心安全边界，必须实施只读连接、SQL验证、PII修订等严格控制，并优化工具设计，确保AI安全访问数据。
译自：Your database is about to become an AI tool. Is it ready?
作者：Dan Baskette
25年来，我眼看着数据库被层层保护：防火墙、VPN、连接池、基于角色的访问，甚至变更审查委员会。我们花费了几十年构建工具，以确保错误的查询永远不会到达生产环境。
如今呢？我们即将把连接字符串交给一个AI代理，而这个代理却会幻觉出列名。
这并非对AI的抨击，而是一次现实检验。模型上下文协议 (MCP) 为大型语言模型（LLM）提供了一种结构化的方式来发现和调用外部工具。数据库访问是自然而然的下一步，但它也是最危险的一步。
症结在此：MCP的采用正在加速。2025年，GitHub和公共注册中心出现了数千个服务器，主要供应商也开始尝试集成。但目前的实施尚处于早期阶段，安全态势不一致，而且大多数将数据库连接到AI代理的团队尚未认真应对威胁模型。
本文是一篇面向数据库管理员（DBA）和平台架构师的MCP数据库服务器管理入门指南。我将向您展示为什么它们是一种不同的“野兽”，规范实际保护了什么，以及不可协商的控制措施在实践中是怎样的。
示例来源于gp-mcp-server，这是一个我为探索Greenplum和PostgreSQL安全模式而构建的开源Spring Boot原型。它涵盖了许多共通之处，并为我们提供了具体的代码进行讨论。
没有虚张声势，只有真实的代码、真实的安全控制和真实的架构决策。
为什么数据库访问是最难的MCP问题
大多数MCP工具对可能出错的范围都有一个天然的上限。文件读取器读取文件，日历工具管理事件。影响范围是可预测的。但数据库则不然。
SQL具有表现力、可组合性，但落入不当之手，则具有破坏性。一个有效的查询就能导出敏感表、锁定生产资源或大规模窃取数据。
“MCP服务器不仅仅是一个适配器。它是所有其他一切的基石。如果基石出错了，整座房子都会倒塌。”
现在，再将其与一个自信地产生幻觉、容易受到提示注入攻击、并优先考虑“有帮助”而非“安全”的LLM结合起来。传统的数据库访问假设调用者理解其正在做什么。当AI代理成为调用者时，这个假设就失效了。
MCP服务器不仅仅是一个适配器。它是所有其他一切的基石。如果基石出错了，整座房子都会倒塌。
规范涵盖了什么（以及没有涵盖什么）
你需要了解规范处理了什么，以及它留给了你什么。这个空白就是你的工程工作所在。
规范的安全演进
MCP规范发展迅速，每次修订都提升了安全底线：
- 2024-11-05：开发者自行实现身份验证。一场噩梦。
- 2025-03-26：通过OAuth 2.1和PKCE实现标准化身份验证。
- 2025-06-18：强制性的资源指示器以阻止令牌透传攻击。
- 2025-11-25：企业IdP集成和机器到机器身份验证。
方向很明确：更严格的身份验证，更好的企业控制。这是个好消息。
真正重要的空白
坏消息是：规范不管理服务器到数据库的授权。它定义了AI客户端如何向你的MCP服务器进行身份验证。它不涉及你的服务器如何向数据库进行身份验证。它也不定义允许哪些查询。
规范将服务器视为中间人，而不是透明的令牌转发代理。
“代理转发身份。中间人强制执行策略。它自己做决策。”
代理转发身份。中间人强制执行策略。它自己做决策。
规范为你提供了基础，但你需要建造墙壁。
那么，团队实际上是如何建造这些墙壁的呢？答案取决于你问谁。
现状
数据库MCP服务器领域正在发展。成熟度差异巨大，其中一些解决方案确实令人担忧。
那个出错的参考实现
Anthropic将其最初的PostgreSQL MCP服务器设计为只读。它将查询包装在一个事务中并进行回滚。表面上看是合理的。
但Datadog安全实验室发现了一个关键漏洞：服务器接受以分号分隔的多语句查询。攻击者可以发送COMMIT; DROP SCHEMA public CASCADE;。COMMIT退出包装事务，而DROP则在安全机制之外执行。
“将查询包装在只读事务中并非安全边界。这就像试图把万磁王关在钢笼里一样。”
教训是：将查询包装在只读事务中并非安全边界。这就像试图把万磁王关在钢笼里一样。防御本身成了攻击者对付你的武器。
如何阻止：攻击绝不应该到达数据库。生产环境的MCP服务器 需要默认强制执行只读模式，并使用基于策略的控制来限制每个角色允许的SQL语句类型。DROP语句应该在连接层面就因只读数据库用户而失败。
在gp-mcp-server中，我构建了一个额外的保障措施：每个查询在执行前都会使用JSQLParser解析成抽象语法树（AST），直接拒绝多语句查询。攻击在到达数据库之前就在解析器中被终结。这种分层就是深度防御在实践中的体现。
悄无声息的提示注入
这种攻击更为微妙。一名研究人员演示了一种攻击，其中一个支持工单包含读取敏感表的指令。当具有提升权限的AI代理审查该工单时，它遵循了指令并窃取了数据。
我称之为“响指条件”。攻击要奏效，必须集齐三颗“宝石”：
- 访问之石：代理可以访问私有数据。
- 暴露之石：不可信内容进入代理的上下文。
- 窃取之石：代理有途径将数据发送出去。
这三者必须同时存在。移除任何一个，响指就会失败。
如何阻止：你无法通过单一控制来修复提示注入。但你可以移除“手套”中的宝石：
- 策略控制：成熟的MCP服务器需要一个策略层，根据角色定义允许和拒绝的SQL语句类型，限制代理可以访问的内容。在gp-mcp-server中，我出于同样的目的在应用层构建了模式和表的允许列表。
- 个人身份信息（PII）修订：在敏感数据进入 LLM的上下文 之前对其进行掩码处理。基于角色的列级掩码是理想选择，但即使是基于正则表达式的修订也能发挥作用。在gp-mcp-server中，我构建了一个修订引擎，在响应发出之前扫描结果集中的电子邮件、SSN和自定义令牌等模式。
- 凭证范围：企业实施应将IdP角色直接映射到数据库用户，因此只读角色获得
readonly_user凭证，分析师获得analyst_user凭证。对于尚未部署OAuth基础设施的环境，gp-mcp-server使用每个API密钥的连接池，并配有专用的HikariCP实例来提供工作负载隔离。
数百台服务器。零认证。
2025年的安全扫描描绘了一幅严峻的景象。研究人员发现数百个公共MCP服务器暴露在互联网上，没有任何身份验证或加密。这些并非边缘案例或业余项目，而是具有直接数据库访问权限且没有审计跟踪的生产级服务器。
如何阻止：身份验证必须是一流特性，而不是事后考虑。生产服务器应支持多种身份验证模式：仅用于开发的开放访问、用于简单部署的基本身份验证（Basic Auth），以及用于真实环境的OAuth 2.1与企业IdP集成。TLS和mTLS应得到全面支持。
在gp-mcp-server中，我构建了结构化的API密钥（gpmcp_live_{id}.{secret}），其中ID在日志中可见，用于审计跟踪，密钥存储为bcrypt哈希，并在每个工具执行上进行方法级别的@PreAuthorize门控。
不可协商的要点
上述攻击场景展示了可能出错的地方。这里是必须正确的地方。任何数据库MCP服务器在没有这些控制措施的情况下，都不应触及生产数据。无一例外。
原则零：代理不可信
将每个查询都视为恶意输入。LLM不理解你的数据模型或合规义务。不信任任何东西。验证所有一切。
- 只读连接：数据库层面的不可协商的权限边界。所有其他控制都假定此项存在。
- SQL验证：基于策略的过滤、AST级别的解析，理想情况下两者兼有。格式错误或恶意的查询在到达数据库之前就被阻止。
- 结果限制：行数限制、字节上限、超时。感知令牌的截断很重要。返回50,000个令牌并不能让LLM得到更好的答案。它只会浪费金钱并降低推理能力。
- 个人身份信息（PII）修订：服务器端执行，在结果进入LLM的上下文之前。一旦数据到达模型，就无法控制。没有“撤销”选项。
- 凭证隔离：数据库凭证绝不出现在MCP负载中。无论是OAuth令牌范围限定还是静态加密，攻击者即使攻破传输层也一无所获。
- 身份验证：强制性。非可选。不是“我们以后再添加”。没有密钥，没有令牌，就没有查询。
组合堆栈
这些控制措施没有一个是单独起作用的。只读连接不能阻止数据窃取。SQL验证不能修订PII。它们作为一个系统协同工作。
单独的每项控制措施都像一个独立的复仇者。能力强大，但容易受到攻击。将它们堆叠在一起，你就拥有了一个集结的团队。威胁必须同时击败所有这些措施。
工具设计是一项安全决策
这些控制措施让你进入了“牌桌”。但你如何构建工具本身，决定了代理的行为是安全还是鲁莽。
诱惑在于暴露一个单一的execute_query工具，让LLM自行解决。这是一种伪装成简单性的安全失败。只有一个原始查询工具的代理将生成它认为有用的任何SQL。没有护栏。没有引导工作流。没有对其首先探索内容的限制。
更好的方法是围绕一个精心设计的工作流组织专用工具：发现模式。约束查询。控制数据。监测系统。
发现工具让代理在编写SQL之前理解模式。诊断工具返回预计算的结构化结果，而不是原始查询输出。这种方法可以显著节省令牌，可能将使用量减少一个数量级或更多。这不仅仅是成本上的胜利。上下文窗口中更少的令牌意味着更小的幻觉表面积和更少的注入内容隐藏空间。
这种分解本身就是一种安全模式。具有独立发现、查询和诊断工具的代理将自然地在尝试即席SQL之前探索模式。具有内置分析工具的代理有更少理由编写超出策略边界的复杂查询。工具设计是另一种形式的提示工程。大多数团队尚未利用这一优势。
在gp-mcp-server中，我应用了这一原则，提供了12个专注于模式发现、验证查询执行和数据分析的工具，以及对大型结果集的服务器端游标支持。我深入研究了安全性和可观测性，而不是广泛涵盖DBA工具包。生产实现可以通过数十个涵盖诊断、分析和管理的专用工具显著扩展这一领域。尽管如此，原则依然成立：你如何限定工具范围决定了代理操作的安全性。
最被低估的安全特性
一个值得更多关注的模式是通过配置实现的用户定义工具。在运行时定义自定义的、由SQL支持的工具，无需代码更改。想想这意味着什么。数据库团队可以定义精确范围的工具。
针对特定表、带有特定参数的特定查询。他们将这些工具交给AI代理用户，而不是开放式的查询访问。代理获得了所需的能力。数据库团队保留对实际执行的SQL的完全控制权。
这是大多数MCP实现完全缺失的灵活性和治理的交集。但即使所有这些控制措施都已到位，大局仍比任何单一功能都重要。
“AI代理与你的数据之间的服务器才是安全边界。而不是数据库自身的访问控制。也不是LLM的训练。是MCP服务器。”
MCP数据库集成已到来。该协议正在成熟。用例引人注目。我在gp-mcp-server中探索的模式表明，安全设计是可实现的：只读默认设置、基于策略的访问控制、分层身份验证以及从根本上约束代理行为的专用工具。
但更广泛的领域仍然从“有趣的实验”到“主动危险”不等。AI代理与你的数据之间的服务器才是安全边界。而不是数据库自身的访问控制。也不是LLM的训练。是MCP服务器。
这些模式已经存在，规范也已准备就绪。这些实现是开源且可测试的。问题不在于AI代理是否会连接到你的数据库。而在于当它们连接时，安全边界是否已经就位。
发现模式。约束查询。控制数据。监测系统。
这就是蓝图。
