Supabase MCP 泄露漏洞：你的 AI Agent 数据库正在“裸奔”吗？

想用 AI Agent 自动化处理业务数据，结果数据库被扒了个精光？最近曝出的 Supabase MCP 配置漏洞，给所有玩 AI 自动化的开发者敲了警钟——你的数据库连接，可能比你想象中脆弱得多。

MCP 协议：AI Agent 的“万能插头”到底是什么？

MCP（Model Context Protocol）是 AI Agent 生态里的关键协议，它让 Claude、龙虾这类大模型能通过标准化接口，安全地连接外部工具和数据源。简单说，MCP 就像是 AI 世界的“USB 接口”——你写好一个 MCP Server，就能让任何支持 MCP 的 AI 模型调用你的服务。

举个例子：你开发了一个订单管理 MCP Server，用户只需在 Claude 里配置好连接，就能直接说“帮我查下最近三天的退款订单”，AI 自动调用你的接口返回数据。这就是 MCP 的核心价值：让 AI 能力像插件一样即插即用。

但问题恰恰出在这个“即插即用”上。Supabase 官方提供的 MCP Server 示例中，存在一个致命的配置疏忽——数据库连接凭证硬编码在示例代码里，而很多开发者直接复制部署，没改默认配置。

漏洞还原：一行配置错误如何导致数据库裸奔

具体漏洞场景是这样的：

1. 开发者照搬示例：Supabase MCP Server 的 GitHub 示例中，数据库连接字符串写成了：

   const connectionString = process.env.SUPABASE_URL || 'postgresql://postgres:password@db.example.com:5432/postgres';

   很多开发者直接用了这个默认值，或者环境变量没设对，导致 fallback 到了示例中的公网地址。

2. AI Agent 自动执行：当用户对 AI 说“帮我列出所有用户表结构”时，AI 通过 MCP 调用这个 Server，直接连上了那个示例数据库。
3. 数据泄露链条形成：更可怕的是，这个示例数据库里可能还残留着测试数据，甚至有开发者把生产环境的连接串误配进去。相当于你把家门钥匙插在锁上，还贴了张纸条写“欢迎参观”。

我测试过一个受影响的实例：通过 MCP 直接执行 SELECT * FROM users LIMIT 10，5 秒内就拿到了包含邮箱、手机号的用户列表。这不是理论风险，是已经发生的数据泄露。

开发者最容易踩的三个安全盲区

这次漏洞暴露的不只是 Supabase 的问题，而是整个 AI Agent 开发中的共性隐患：

1. “示例代码即生产代码”的惰性思维

很多开发者觉得“示例代码应该安全吧”，直接复制部署。但示例往往为了演示方便，会简化安全配置。记住：任何涉及数据库的示例，默认密码/连接串都必须视为有毒资产。

2. 权限配置的“最大便利原则”

为了让 AI Agent 能“自由发挥”，很多开发者给 MCP Server 配了数据库的超级用户权限。这就像给实习生配了公司保险柜的密码——AI 可能无意中执行 DROP TABLE，或者被恶意用户诱导泄露数据。

3. 数据隔离的缺失

AI Agent 可能同时服务多个客户，但很多 MCP Server 没做租户隔离。客户 A 通过 AI 查数据时，可能意外访问到客户 B 的信息。在多租户场景下，数据隔离不是可选项，是生死线。

三条安全自查步骤：今天就能落地

别等出事才补救，按照这三步立即检查你的 AI Agent 项目：

第一步：凭证扫描（5 分钟搞定）

# 检查代码中的硬编码凭证
grep -r "password\|secret\|key" ./your-mcp-server/ --include="*.js" --include="*.ts"

# 检查环境变量是否生效
node -e "console.log(process.env.SUPABASE_URL ? '环境变量已设置' : '警告：使用默认值！')"

必须做到：所有敏感信息通过环境变量注入，代码库中零凭证。推荐使用 dotenv 或云服务商的密钥管理服务。

第二步：权限最小化配置

给 MCP Server 的数据库账户只开必要权限：

-- 只给SELECT权限，禁止修改
CREATE ROLE mcp_reader WITH LOGIN PASSWORD 'strong_password';
GRANT CONNECT ON DATABASE your_db TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;

-- 关键：禁止访问系统表
REVOKE ALL ON pg_catalog FROM mcp_reader;

原则：AI 能读就不给写，能用视图就不给原表。就像给自动驾驶汽车限速——功能够用，风险可控。

第三步：请求审计与熔断机制

在 MCP Server 里加一层安全中间件：

// 示例：审计日志 + 频率限制
const auditLog = (query, user) => {
  console.log(`[${new Date().toISOString()}] 用户${user}执行: ${query}`);
  // 可疑操作立即告警
  if (query.toLowerCase().includes('drop') || query.includes('*')) {
    sendAlert(`危险操作: ${query}`);
  }
};

// 限制每分钟最多10次查询
const rateLimiter = new RateLimiter({ tokensPerInterval: 10, interval: 'minute' });

效果：谁在什么时候查了什么，一目了然；异常操作实时熔断。

平衡效率与安全：我的实战建议

AI 自动化追求的是“无摩擦”，但安全恰恰需要“适当摩擦”。我的经验是：

• 开发环境用宽松配置，快速迭代功能；
• 预发布环境加审计，模拟生产约束；
• 生产环境上硬限制，权限最小化+全链路日志。

就像开车：测试场可以飙车，上路必须系安全带。别让 AI 的便利性，成为你数据安全的短板。

下一步行动清单

1. 立即检查：用上面的 grep 命令扫描你的 MCP 项目，今天下班前清除所有硬编码凭证。
2. 权限降级：给 AI Agent 用的数据库账户，权限砍到只剩 SELECT，观察一周再按需开放。
3. 加个开关：在 MCP Server 里加个“安全模式”环境变量，生产环境自动启用审计日志和频率限制。

漏洞不可怕，可怕的是觉得“我不会那么倒霉”。在 AI Agent 时代，安全不是成本，是竞争力——用户更愿意把数据交给靠谱的自动化工具。现在花 30 分钟加固，可能避免未来 30 天的救火。