ICE's Tech Stack

Appearance

Agent 直连数据库的三道关：身份怎么传进去，SQL 怎么拦下来 ​

封面

Deep Research 报告 | 2026 年 7 月 | 面向数据平台、平台工程与安全架构师，正在把 Agent / MCP 接入生产数据库的从业者

摘要 ​

上一篇《Agent 打破了 20 年数据治理》讲清了一个架构判断：Agent 直连数据库、绕过应用层护栏之后，enforcement 必须下沉到数据库引擎、下沉到 Agent 绕不过去的那一层。 这句话方向没错，但它落到工程上会立刻撞上两个特别具体、特别难的问题：

  1. 数据库凭什么知道，这个 Agent 背后是哪个真人？ 过去数据库只认一个高权限共享账号，根本分不清是财务小王还是一个跑偏的自动化脚本在查。
  2. 数据库凭什么拦住它概率式生成、随时可能越界的 SQL？ Agent 的查询是大模型现场生成的，没有"预定义语句"可言，你没法预测它下一条会写出什么。

这两个问题不解决，"执行下沉"就是一句空话——你把 enforcement 放进了库里，可库里既不知道该按谁的权限判、也不知道该拦哪些语句。这篇就把 MCP 直连数据库的安全模型拆成环环相扣的三道关：

  • 第一道关 · 认证：MCP 服务器到底是什么角色，为什么"万能账号 + 应用层过滤"这套老办法在这里彻底失效。
  • 第二道关 · 身份传播：用 OBO（On-Behalf-Of）/ RFC 8693 token exchange，让"这条查询到底替谁在问"变得可验证、可审计、每跳权限收敛——而不是靠 token 直接透传（一个被规范明令禁止的反模式）。
  • 第三道关 · SQL 闸：最小权限只读角色 + SQL Firewall / allowlist，给概率式生成的 SQL 配一道确定性的闸。

三道关合起来，才是"执行下沉"真正的工程形态：纵深防御，每一层都假设上一层可能被绕过。

一、先认清：MCP 把二十年的后端安全欠账又翻了出来 ​

在讲三道关之前，得先看清 MCP 直连到底把什么暴露了——因为很多团队是在"没意识到攻击面变了"的情况下就把 Agent 接上了生产库。

MCP（模型上下文协议）的设计哲学是"把 LLM 接到外部系统"，但它有意把认证、凭据处理、权限范围、查询校验这些后端安全决策，几乎全部留给了实现者。这句话翻译成人话就是：MCP 本身几乎不管安全，安全全看你这个 MCP 服务器怎么写。于是 2024 年以来，经典漏洞成批地回归了。

最典型的是 Anthropic 官方那个（现已归档的）PostgreSQL MCP 服务器。它号称"只读保护"——做法是把查询包在一个 SET transaction_read_only = true 的事务里。Datadog 的安全研究发现：攻击者只要在查询串里注入一个 COMMIT;，就能结束这个只读事务，然后执行任意写操作。所谓只读，一条多语句 SQL 就绕过去了。教训很直白：客户端层面的"SQL 安全"根本不是真的安全。

这不是孤例。Akamai 在 2026 年 5 月的研究里，一口气在三个数据库 MCP 服务器（Apache Doris、Apache Pinot、阿里 RDS 的相关组件）上找到了 SQL 注入（CVE-2025-66335）、缺失认证、未过滤输入等问题。研究者说得很清醒：重点不是这几个 bug，而是这个模式——MCP 服务器这一层，是一个"继承了几十年未解决的后端安全问题、却穿着新工具外衣、部署速度远超安全指南传播速度"的全新攻击面。整个生态被类比为"早期 npm 的蛮荒时代"：大量未经审计的服务器，请求着过大的权限。

看清这个背景，三道关的意义就清楚了：你不能指望 MCP 服务器自己是安全的，必须在它前面（认证与身份）、在它后面（数据库权限与 SQL 闸）都设防。

二、第一道关：别再用那个"万能账号" ​

传统数据栈里，数据库往往握着一个高权限共享账号，因为"真正的过滤在应用层做完了"。到了 MCP 直连时代，这个假设是最先崩的一块。

问题出在角色错位。先厘清 MCP 授权规范（2025-06-18 版）定义的角色分工：

  • MCP 客户端（Agent 宿主，如 IDE、自研 Agent）：扮演 OAuth 客户端。
  • MCP 服务器（数据/工具提供方）：扮演 OAuth 资源服务器——它只校验 token，不签发 token。
  • 授权服务器（AS）：认证用户、签发 token，通常就是你现有的 IdP。

规范对资源服务器提了几条强制要求，每一条都在堵一个具体的窟窿：

  • audience 绑定（RFC 8707 资源指示符）：客户端申请 token 时必须带上 resource 参数，指明"这个 token 只在哪个服务器用"。服务器则必须校验 token 的 aud 声明是不是自己——只接受专门发给自己的 token，拒绝一切发给别的服务的 token，哪怕那个 token 本身合法。没有这一步，用户授权给别的服务的 token 就能被重放到你这个 MCP 服务器上。
  • 禁止 token passthrough：这是被规范明令禁止的反模式——MCP 服务器绝不能把从客户端收到的 token，原封不动地转发给下游 API（比如再拿去连数据库）。

为什么 token 透传这么危险？因为它会制造经典的 confused deputy（混淆代理） 问题：下游（数据库/API）收到一个透传来的 token，会误以为"这是 MCP 服务器验证过、发给我的"，从而错误地信任它。攻击者就能借用 MCP 服务器的信任，去够到本来够不到的下游资源。一句话：token 只应在一扇门有效，绝不能拿着一扇门的钥匙去开另一扇门。

所以第一道关的结论是：MCP 服务器必须先把自己当成一个严肃的 OAuth 资源服务器——校验 audience、拒绝越界 token、绝不透传。远程 MCP 服务器优先用 OAuth 2.1（而不是本地那种把 API key 写进配置文件的模式），token 短时效、自动轮换、存进凭据金库而非环境变量。做到这一步，你才有资格谈下一道关：把"到底是谁"传到库里。

三、第二道关：用 OBO 让"替谁问"可验证 ​

认证解决了"这个连接合法吗"，但还没解决那个真正要命的问题：这条查询，到底替哪个真人在问？ 而且现实往往不是一跳，而是一条链：人 → 编排 Agent → 子 Agent → MCP 服务器 → 数据库。身份必须在这条链上一路传下去，且每一跳都能被验证。

这就是 OBO（On-Behalf-Of）/ token exchange 要解决的事，标准是 RFC 8693（OAuth 2.0 Token Exchange）。它的机制精巧但思路很清楚：**不透传原 token，而是在每一跳用旧 token 换一个新 token。**换出来的新 token 里有两组关键声明：

  • sub（subject）：始终是最初那个真人——不管中间经过多少个 Agent，"这件事最终是替谁做的"不丢。
  • act（actor）：当前这一跳的执行者，而且可以嵌套——act 里再套 act，完整记录"子 Agent 替编排 Agent、编排 Agent 替这个人"的整条委托链。

配上 scope，就能做到每一跳权限收缩（scope contraction）：越往下游，token 能干的事越少。数据库最终拿到的 token，既知道"原始发起人是 X"，又知道"这条链经过了 A、B 两个 Agent"，于是可以据此施加策略——授权按发起任务的真人来判，而不是按那个大权限共享账号。这正好接上了上一篇讲的库内 enforcement：数据库有了可信身份，行列单元级的授权才有了判断依据。

Token 透传（反模式）vs OBO 换发（RFC 8693）：透传导致混淆代理，OBO 每跳换发、权限收敛、可审计

多个业内实现已经独立收敛到这条标准上：AWS 在 2026 年 4 月给 AgentCore Identity 加了 OBO token exchange（文档直接点名 RFC 8693）；RSAC 2026 后，Coalition for Secure AI（CoSAI）的企业指南也明确建议——MCP 生产部署要用 RFC 8693 换取带明确 actor/subject 声明的收敛 token，而不是透传用户 token。

不过有一个务实的提醒：各家 IdP 的实现并不统一。 Okta 走的是 RFC 8693 原生（grant type 是 urn:ietf:params:oauth:grant-type:token-exchange），而微软 Entra ID 用的是 RFC 7523 的变体。这意味着你在多云、多 IdP 环境里搭这条身份链时，得预留适配成本，别指望一套代码到处跑。MCP 核心规范本身也没强制 RFC 8693（因为不是所有第三方 API 都支持 token exchange），它是被企业级 MCP 网关（AgentCore Gateway、Red Hat 的 MCP 参考架构等）叠加在 MCP 之上来做跨跳委托的。

四、第三道关：给概率式 SQL 配一道确定性的闸 ​

身份传进去了，但还差最后、也是最贴近数据的一道关：这个已知身份的 Agent，到底能对数据库跑什么 SQL？ 这一关分两层——一层是"权限不能大"，一层是"语句得可控"。

第一层，最小权限只读，而且必须在数据库这一侧强制。 OWASP 把"过度授权（excessive agency）"列为 LLM 头号风险之一，点名的正是这个反模式：一个本该只读的扩展，却用了一个"不光有 SELECT、还有 UPDATE/INSERT/DELETE 权限"的身份去连库。正确做法是给 MCP 服务账号一个专用的、只读的、锁定到具体 schema（最好指向只读副本而非生产主库）的角色，显式 REVOKE 掉敏感表。这样即便发生 prompt injection 或 SQL 注入，一个只读账号撞上的是数据库的硬墙——它想 DROP 也 DROP 不动。关键在于：这个限制必须是数据库用户级的，而不是客户端事务级的（还记得那个被 COMMIT; 一句就绕过的 read-only 事务吗）。

第二层，SQL Firewall / allowlist，给不可预测的语句配确定性的闸。 只读还不够——一个只读账号照样能读到不该读的表、跑出拖垮库的昂贵查询、或通过反复查询做数据推断。这里就轮到上一篇提过的 SQL Firewall 登场：它内建在数据库引擎里，检查所有进来的 SQL，只放行显式授权（allowlist）的语句，异常的记录并拦截；因为长在引擎里，本地/网络、明文/加密都绕不过。

这一层的哲学值得单独点出来：Agent 生成 SQL 是概率式的、不可预测的；那就用一道确定性的闸去框住它。 你没法预测大模型下一条写出什么，但你可以预先声明"只有这些形态的语句能跑"。这也是为什么很多生产实践更进一步——干脆不给 Agent 裸 SQL 执行工具，而是用抽象层（如参数化的预定义工具）暴露有限的、参数化的操作，从源头上消灭"任意 SQL"这个攻击面。再叠加语句超时、行数上限、破坏性操作（DELETE/DROP）的人工审批（human-in-the-loop），一道闸就基本成形了。

五、三道关合起来：一张纵深防御图 ​

把三道关串起来看，就是一条层层收敛的漏斗——每一层都不假设上一层绝对可靠：

MCP 直连数据库的三道关纵深防御：认证 → 身份传播 → SQL 闸 → 行列级 enforcement → 审计

用一张清单把每道关要做的事和它挡住的攻击对上，方便直接拿去自查：

关卡核心动作挡住的攻击 / 风险强制层
① 认证OAuth 2.1 资源服务器；校验 aud（RFC 8707）；禁止 token 透传越界 token 重放、confused deputyMCP 服务器
② 身份传播OBO / RFC 8693 token exchange；sub 保真人、act 记链路、每跳收缩 scope万能账号、过度授权、无法归因IdP + 网关
③ SQL 闸（权限）专用只读角色、锁定 schema、指向副本、REVOKE 敏感表prompt injection / SQL 注入的破坏面数据库引擎
③ SQL 闸（语句）SQL Firewall / allowlist、参数化工具、超时/行数限制、破坏性操作人工审批任意 SQL、昂贵查询、数据推断数据库引擎
贯穿审计每一条查询（谁、经过哪条链、跑了什么、何时）静默滥用、事后无法追责数据库 + 网关

这张表最该记住的一点是最右列——强制层。三道关分别落在 MCP 服务器、IdP/网关、数据库引擎三个不同的地方，缺一层，Agent 就多一条绕过去的路。而它们共同指向同一个原则：把每一道防线，都放到 Agent 绕不过去的那一层去强制。

六、ICE 观察 ​

技术视角：这是"执行下沉"在身份与 SQL 两个维度的具体化 ​

上一篇讲"enforcement 要下沉到绕不过去的那一层"，这一篇其实是把那句话拆成了可施工的两根钢筋：身份的下沉（OBO 让真人身份一路传到库，而不是停在应用层）和 SQL 管控的下沉（allowlist/Firewall 让语句在执行入口被框住，而不是靠客户端自觉）。它和"编译期治理"是同一套世界观——不信任任何单点、把强制点尽量前移到数据被访问的那一刻。 对架构师最实际的判断标准是：评估一套 Agent 数据方案时，逐一问这三道关分别落在哪一层、能不能被直连绕过。 如果某一关的答案是"在客户端"或"靠 MCP 服务器自觉"，那它基本等于没有。

落地视角：先上"便宜且高价值"的两关，再啃 OBO ​

三道关的落地成本差异很大，别一上来就啃最硬的。务实的优先级是：先做第三道关里最便宜、收益最高的两件事——专用只读角色（锁定 schema、指向副本）+ 全量查询审计，这两件几乎不依赖改造 IdP，却能立刻把"破坏面"和"追责能力"拉到及格线。然后补第一道关的 OAuth 资源服务器与 audience 校验（尤其别再透传 token）。最后再啃第二道关的 OBO 身份链——因为它牵涉 IdP 适配（Entra 与 Okta 实现不同）、多跳网关，改造最重。反过来先追求"完美的身份链"、却留着一个高权限账号和裸 SQL 工具，是典型的把力气花错地方。记住上一篇那个数字：48% 的生产 Agent 还处于无监控状态——对大多数团队，先把只读 + 审计这两块地基打上，比什么都实在。

本土视角：国产栈里，这三道关每一关都有"再落一次地"的活 ​

放到信创与可信数据空间的语境，这三道关一个都不能少，而且每一关都要在国产组件上重新落一遍。认证与身份传播这一关尤其要早做规划：OBO/token exchange 依赖 IdP 支持，国产 IdP（统一身份认证平台）对 RFC 8693 的支持程度参差不齐，多半需要在网关层做适配、甚至自建 STS（安全令牌服务）来完成 sub/act 的换发与链路留痕——这恰恰是国产身份厂商的一个机会点。SQL 闸这一关则要看国产数据库的底子：行列级安全、SQL 防火墙/白名单、审计这些能力是否内建、能否被直连绕过，直接决定了"库内 enforcement"能不能真正兜住。把这三道关和上一篇讲的可信数据空间合起来看，一条清晰的产品主线就浮现了：用途合约（定义）→ OBO 身份链（谁在用、替谁用）→ 域内 SQL 闸与行列级 enforcement（能用到什么程度）→ 可重放审计（事后能不能查）。 谁能把这条链在国产栈上打通，谁就握住了强监管客户"敢让 Agent 碰核心数据"的完整答案。

结论 ​

把这篇收束成几句话：

  1. MCP 直连是个全新攻击面，且大多是老欠账回归。 客户端层面的"只读""SQL 安全"都不可信（一个 COMMIT; 就绕过），必须在 MCP 服务器前后同时设防。
  2. 第一道关——认证：MCP 服务器要当一个严肃的 OAuth 资源服务器，校验 audience、拒绝越界 token、绝不透传（否则就是 confused deputy）。
  3. 第二道关——身份传播：用 OBO / RFC 8693，让 sub 保真人、act 记链路、每跳收敛 scope，数据库才有可信身份去做行列级 enforcement。注意 Entra 与 Okta 实现不一致，要留适配成本。
  4. 第三道关——SQL 闸：数据库侧的专用只读角色（防破坏）+ SQL Firewall/allowlist（框住概率式 SQL），再加审计与破坏性操作人工审批。
  5. 三道关的共同原则：纵深防御，把每一道防线都强制在 Agent 绕不过去的那一层。

最后留个问题给正在把 Agent 接上生产库的你：此刻，如果一个 Agent 通过 MCP 直连你的数据库，你的系统里有几道关是真正"在数据库/引擎侧强制、绕不过去"的，又有几道其实只是写在客户端和 MCP 服务器的代码里、指望它们自觉？ 这个盘点的结果，大概就是你离"敢让 Agent 上生产"还差多远。

参考资料 ​

  1. Model Context Protocol. Authorization（2025-06-18 规范：OAuth 2.1 / 资源服务器 / RFC 8707 audience 绑定 / 禁止 token 透传）. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
  2. Model Context Protocol. Security Best Practices（Token Passthrough 与 Confused Deputy）. https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
  3. IETF. RFC 8693 - OAuth 2.0 Token Exchange（subject_token / actor_token / act 嵌套声明）. https://datatracker.ietf.org/doc/rfc8693/
  4. ScrambleID. Multi-Hop Agent Delegation Chains: Identity Propagation Across Human → Agent → Agent → Tool → Resource. 2026. https://www.scrambleid.com/learn/multi-hop-agent-delegation-chains
  5. Oleria. On-behalf-of Identity at Machine Speed: What AI Agents Change About Delegated Access（AWS AgentCore / CoSAI 指南）. 2026. https://www.oleria.com/blog/on-behalf-of-identity-at-machine-speed
  6. Heeki Park. Crossing Trust Boundaries with On-Behalf-Of Token Exchange（Entra RFC 7523 vs Okta RFC 8693 实现差异）. 2026-05. https://heeki.medium.com/crossing-trust-boundaries-with-on-behalf-of-token-exchange-664b62bc84dd
  7. ChatForest. Connecting AI Agents to Databases with MCP: Patterns, Security, and Production Best Practices（Anthropic PostgreSQL MCP 只读绕过 / Datadog 研究）. 2026. https://chatforest.com/guides/mcp-database-connection-patterns/
  8. LLM-Hacking. MCP Back-End Vulnerabilities: Classic Flaws Resurface Across AI Database Bridges（Akamai 2026-05；CVE-2025-66335）. 2026. https://www.llm-hacking.com/hacks/mcp-backend-vulnerabilities-pattern.md/
  9. Sequel. MCP Security and Governance Guide（只读角色 / 作用域 / 审计 / 人工复核清单）. 2026. https://sequel.sh/blog/mcp-security-governance
  10. Descope. MCP Server Security Best Practices to Prevent Risk（渐进式授权 / 凭据金库 / OWASP 过度授权）. 2026. https://www.descope.com/blog/post/mcp-server-security-best-practices
  11. Oracle. Oracle SQL Firewall is Now Built into Oracle AI Database（26ai 内建 SQL Firewall，allowlist 强制）. https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/release-changes.html