上个月，一家金融科技公司的内部运维 Agent 在接入 MCP 协议后，直接把生产环境的只读从库给跑崩了。起因很简单：用户问了一句“对比过去三个月的订单趋势”，Agent 生成了一个未经优化的 CROSS JOIN 语句，在没有索引的百万级大表上触发了全表扫描，CPU 瞬间飙到 100%。
很多团队解决了 MCP 的鉴权和连接池问题，就觉得“通了”。但当自然语言通过 LLM 转化为 SQL 并执行时，风险才真正开始。LLM 不理解你的数据库执行计划，也不在乎索引成本。
连上就乱码？端到端编码没对齐
这是最常见的低级错误。LLM 输出是 UTF-8，MCP 传输是 UTF-8，但很多企业的 legacy 数据库还在用 latin1 或 gbk。
当 Agent 查询中文客户资料时，如果 MCP Server 连接字符串没强制指定编码，就会出现“乱码回传”：数据库返回 utf8mb4 → 驱动误认为 latin1 → MCP Server 转码 → LLM 收到一堆 ??。更糟的是，如果执行 UPDATE，乱码会直接写入数据库，造成数据损坏。
怎么防：
在 MCP Server 的数据库连接池配置里，必须强制 characterEncoding=UTF-8 和 serverTimezone=UTC。对 MySQL，建议连接会话开始时执行 SET NAMES 'utf8mb4'。别依赖数据库默认配置，Agent 的连接是动态高频的，一次编码漂移就可能废掉整个结果集。
NL2SQL 跑慢查询？用超时和截断来兜底
NL2SQL 是概率预测，不是逻辑推演。模型可能为了一个简单统计，写出多层嵌套子查询，或者在 WHERE 子句里用 LIKE '%xxx%'，导致索引失效。这种“逻辑正确但性能毁灭”的查询，在并发高时会迅速占满连接池，拖垮整个应用。
防御三件套：
- 物理隔离： MCP Server 只能连只读从库，绝对禁止连主库。
- 强制超时： 在数据库用户级别设置超时。比如 PostgreSQL 里用
ALTER USER agent_user SET statement_timeout = '5s'，超过 5 秒的查询直接被 kill。 - 结果集截断： 在 MCP Server 层拦截 SQL，强制所有查询末尾加
LIMIT 100。别让 Agent 一次拉万级数据，LLM 上下文窗口也装不下，传输还慢。
权限给大了？Agent 会变成内部黑客
最危险的是“权限穿透”。为了方便，给 MCP Server 配了一个 SELECT * 的通用账号？一旦遇到提示词注入，攻击者可能引导 Agent 执行 SELECT * FROM users，窃取所有用户数据。
即使你只给了读权限，Agent 还能通过 INFORMATION_SCHEMA 探测整个数据库结构，找漏洞。传统防火墙对这种从“自然语言”到“数据库元数据”的穿透，基本没辙。
正确姿势： 别给 Agent 真实数据库账号，给它一个“虚拟视图层”。
- 建隔离 Schema： 创建
agent_api这样的 Schema，只放 Agent 需要访问的视图（View），比如把orders表简化成不含敏感字段的v_order_summary。 - 开行级安全（RLS）： 如果 Agent 服务特定用户，必须在数据库层开启 Row Level Security，确保用户的 Agent 只能看到自己的数据，即使 SQL 里没写
WHERE user_id = X。 - 加 SQL 审计网关： 在 MCP Server 和数据库之间加一层轻量级网关，只允许
SELECT、COUNT、SUM等算子，一旦发现DROP、GRANT等关键字，立即阻断并报警。
别靠 Prompt 优化，靠工程约束
回顾《实测Claude 4沙盒模式：用脱敏数据跑通反欺诈规则》里的思路，金融级场景的共识是：数据不能直接交给 AI，中间要有“脱敏-过滤-审计”屏障。
MCP 解决了接入数据的“管道”问题，但管道里的水干不干净、压力大不大，需要靠工程手段去约束。一个靠谱的链路应该是：
LLM → MCP Server (强制UTF-8) → SQL审计网关 (算子白名单) → 只读从库 (超时+RLS) → 隔离视图 (Schema Isolation)。
永远别指望让 Agent 自己“写出高效安全的 SQL”。概率替代不了确定性的工程约束。在生产环境里，最可靠的防御就是：底层把权限关死，入口把超时设短。
