Moltbook 泄露深度分析：150 万 API 密钥因 Supabase 配置错误暴露

Moltbook 的上线就像是一场 AI 社区的狂热梦境。它被定位为一个专门为 AI 智能体（Agents）设计的类 Reddit 社交网络。在短短几天内，互联网见证了超过 100 万个自主机器人在这里发帖、评论，甚至形成了奇怪的数字亚文化——最著名的是对“螃蟹表情包”的莫名崇拜。人类被挤到了边缘，只能在一旁观察这些智能体如何自主交流。然而，这场狂欢在安全研究机构 Wiz 披露了一个灾难性漏洞后戛然而止。由于 Supabase 数据库的一个简单配置错误，整个平台的内部数据完全暴露在了公网之下。

这并不是一次复杂的高级持续性威胁（APT）或零日漏洞攻击。相反，这是现代 Web 开发中最基础安全原语的失效。由于 Moltbook 的创建者过度依赖“氛围编程”（Vibe Coding）——即在没有严格人工审查的情况下，让 AI 快速生成大量代码——诸如行级安全性（Row-Level Security, RLS）之类的基础防护被完全忽视了。结果是：超过 150 万个 API 令牌、6000 多个真实人类用户的电子邮箱以及智能体之间的私密对话，任何能够访问浏览器的人都可以轻易获取。在构建复杂的 AI 基础设施时，开发者往往会忽略底层数据层的安全性。使用像 n1n.ai 这样强大的 LLM API 聚合器可以帮助通过集中化密钥管理来降低部分风险，但它无法修复从根本上损坏的数据库架构。

技术失效：到底发生了什么？

Moltbook 使用了 Supabase，这是一个基于 PostgreSQL 的流行开源 Firebase 替代品。Supabase 的强大之处在于它允许开发者使用发布密钥直接从客户端与数据库交互。然而，这种便利伴随着一个关键要求：你必须启用行级安全性（RLS）。

在标准配置中，Supabase 的 anon 密钥允许任何人向你的数据库端点发送请求。如果没有 RLS 策略，这些请求可以读取每个表中的每一行数据。Moltbook 未能在其核心数据表上启用 RLS。这意味着任何用户只需打开浏览器控制台，运行一个简单的 fetch 命令，就可以下载整个 agents 或 messages 表的内容。

此次泄露的影响范围：

• 150 万个 API 令牌：这不仅包括 Moltbook 的内部令牌，还包括更危险的第三方凭据，如 OpenAI 和 Anthropic 的密钥。
• 6000 多个真实人类邮箱：与这些机器人关联的真实身份信息，为网络钓鱼攻击提供了完美的名单。
• 私密 DMs：智能体之间原本被认为是私密的对话内容完全透明化。
• 完全的读写权限：攻击者不仅可以读取数据，还可以修改智能体的行为，冒充其他用户发帖，甚至接管整个网络。

如何为 AI 智能体加固 Supabase 安全性

如果你正在使用 DeepSeek-V3 或 Claude 3.5 Sonnet 等模型构建智能体平台，必须确保后端经过加固。以下是防止 Moltbook 式灾难的步骤指南：

1. 为每个表启用 RLS

在 Supabase 中创建表时，RLS 默认是禁用的。你必须显式启用它：

ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
ALTER TABLE messages ENABLE ROW LEVEL SECURITY;

2. 定义细粒度的访问策略

启用了 RLS 但没有策略会阻止所有访问。你需要定义谁可以查看什么。对于智能体社交网络，用户应该只能读取他们发送或接收的消息。

CREATE POLICY "用户只能查看自己的智能体"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

CREATE POLICY "智能体只能读取自己的私信"
ON messages FOR SELECT
USING (
  auth.uid() IN (sender_id, receiver_id)
);

3. 绝不在客户端可访问的表中存储密钥

这是 Moltbook 犯下的最大错误。他们将 API 密钥存储在一个可以通过客户端 SDK 访问的表中。秘密信息应始终存储在单独的模式（如 vault）中，该模式绝不应暴露给 anon 或 authenticated 角色。当你需要调用 LLM 时，应使用服务端函数（Edge Function）来检索密钥并发起请求。

为了简化这一过程，许多企业正在转向 n1n.ai。通过使用 n1n.ai，你可以通过一个统一且安全的端点路由所有 LLM 调用。这消除了在自己的数据库中管理数十个独立供应商密钥的需求，显著缩小了发生泄露时的潜在损失范围。

深度分析：“氛围编程”的陷阱

Moltbook 事件凸显了 AI 时代一个日益增长的趋势：“氛围编程”（Vibe Coding）。这指的是开发者使用 Cursor 或 GitHub Copilot 等工具，根据高层级的提示词生成大量代码。虽然这加速了原型的开发，但往往跳过了软件工程中“枯燥”的部分——安全性、测试和架构设计。

当你要求 AI “帮我用 Supabase 构建一个智能体社交网络”时，它可能会生成 UI 和基础数据库模式，但很少会主动提醒你配置 PostgreSQL 策略或安全地管理 service_role 密钥。随着我们向更具自主性的智能体迈进——即机器人有权消费资金或访问 RAG（检索增强生成）数据库——这些错误带来的代价将是毁灭性的。

给 AI 开发者的专业建议

1. 激进的密钥轮换：如果你怀疑发生了泄露，请立即轮换密钥。如果你使用 n1n.ai，你可以从单一仪表板管理密钥轮换和使用限制。
2. 审计智能体技能：在部署可以执行代码或访问互联网的智能体之前，请审计其“技能”或工具。一个伪装成简单工具的恶意插件可能会窃取你的环境变量。
3. 对提示词输入进行脱敏：使用中间层检查提示词注入（Prompt Injection）。即使数据库安全，智能体也可能被诱导通过聊天界面泄露数据。
4. 使用环境变量：在任何情况下，都不要将 API 密钥提交到 Git 仓库，或存储在会被打包进前端的客户端 .env 文件中。

智能体基础设施的未来

Moltbook 的数据泄露是一个警钟。“智能体互联网”正在到来，但它目前非常脆弱且依赖于人类的严谨性。行业需要从幼稚的实现转向鲁棒、安全的架构。我们正在看到专门针对 LLM 的安全层的兴起，包括更好的 RAG 安全性和为每次智能体交互提供审计日志的代理服务。使用 n1n.ai 等聚合器不仅是为了方便，更是为了在模型层和应用层之间建立一道安全屏障。

当你扩展 AI 应用时，请记住：速度不应以牺牲安全为代价。无论你是使用 LangChain 构建复杂的链式调用，还是直接调用 DeepSeek-V3 的 API，地基必须稳固。Moltbook 的案例告诉我们，当“氛围”消失时，剩下的只有暴露在外的原始数据和破碎的信任。

在 n1n.ai 获取免费 API 密钥