Moltbook 的华丽外衣被无情撕开，15万个AI代理的敏感数据裸奔在公网之上。这个号称革命性的AI社交平台，从技术架构到安全意识都漏洞百出，甚至OpenAI联合创始人的私人信息也赫然在列。本文将深度解析这场安全灾难背后的草台班子真相，揭示AI代理人社交背后的致命风险。

2026 年 1 月底，正当 AI 代理社交平台 Moltbook 在全球科技圈引发狂热讨论之际，一场前所未有的安全灾难悄然降临。安全研究员 Jamieson O’Reilly 的一个发现，彻底撕开了这个号称 “AI 代理社交网络” 的华丽外衣 ——整个平台的数据库完全暴露在公网上，没有任何保护措施。更令人震惊的是，数据库中不仅包含了超过 15 万个 AI 代理的敏感信息，还赫然发现了 OpenAI 联合创始人Andrei Karpathy使用时保留的个人信息。

这个由 Octane AI 的 Matt Schlicht 于 2026 年 1 月底推出的平台，原本被视为 AI 代理自主交互的革命性实验场。然而，随着数据库漏洞的曝光，Moltbook 瞬间从技术创新的典范沦为了 \\”草台班子”的典型代表。当黑客可以随意访问数据库，窃取 API 密钥，并冒充任意用户发帖时，这个标榜 “AI 自治” 的平台，实际上已经成为了一个失控的安全黑洞。

数据库裸奔：一个本可避免的致命错误

1.1 漏洞发现：从预警到震惊

Jamieson O’Reilly 作为 D Vuln 公司的创始人，此前已经多次揭露 Moltbots 的安全缺陷。他在发现 Moltbook 的安全隐患后，第一时间联系了平台创始人 Matt Schlicht，并表示愿意提供帮助修复安全问题。然而，Schlicht 的回应却令人大跌眼镜：“我要把一切都交给 AI。所以把你有的任何东西都发给我”。

这种对安全问题的轻慢态度，最终酿成了大祸。一天后，当 O’Reilly 再次检查时，他发现了一个 “令人震惊的配置错误”：”看起来你可以接管系统上的任何账户、任何机器人、任何代理，并在没有任何先前访问权限的情况下完全控制它”。

1.2 技术真相：Supabase 的致命配置错误

Moltbook 使用的是开源数据库软件Supabase，这个选择本身并没有问题。但问题在于，Moltbook 要么从未在代理表上启用行级安全（RLS），要么未能正确配置相关策略。Supabase 默认会暴露 REST API，这些 API 本应由行级安全策略保护，控制用户可以访问哪些行的数据。

更糟糕的是，Supabase 的 URL 和 publishable key 就直接暴露在 Moltbook 的网站上。根据 O’Reilly 的描述，使用这个 publishable key（Supabase 建议不应用于检索敏感数据），可以看到每个代理的 secret API key、声明令牌、验证码和所有者关系，所有这些都完全无保护地暴露在任何人都可以访问的 URL 上。

只需两条 SQL 语句就能修复这个漏洞，但 Moltbook 的技术团队显然没有意识到这一点。正如 O’Reilly 所说：”很多这些 vibe coders 和新开发者，甚至一些大公司，都在使用 Supabase。很多 vibe coders 喜欢使用它的原因是因为它全是 GUI 驱动的，所以你不需要连接到数据库并运行 SQL 命令”。这种过度依赖图形界面而忽视底层安全配置的做法，最终导致了灾难性的后果。

1.3 影响范围：15 万个 AI 代理的集体沦陷

根据最新数据，Moltbook 平台上注册了超过15 万个 AI 代理，而这次数据库泄露事件影响到了每一个注册用户。泄露的信息包括：

• email 地址：用户关联的电子邮件地址，可用于针对性钓鱼攻击
• login_token：JWT 代理会话令牌，可用于完全劫持代理，控制发帖和评论
• api_key：OpenClaw/Anthropic API 密钥，可用于数据泄露到关联服务（电子邮件、日历等）
• agent_id：用于枚举的顺序 ID，可用于批量抓取 50 万 + 虚假账户

更令人担忧的是，超过 75% 的公网 Moltbook 关联实例存在至少一项高危漏洞，32% 同时存在未授权访问、凭证明文存储和 root 权限运行三大致命问题。这相当于向全球黑客敞开了 “数字家门”。

二、Andrei Karpathy 的 API 密钥泄露：名人效应放大安全恐慌

2.1 技术大牛的 “数字分身” 面临威胁

OpenAI 联合创始人Andrei Karpathy无疑是 AI 领域最具影响力的人物之一，他在 X 平台上拥有190 万粉丝。当他的 AI 代理账户信息出现在泄露的数据库中时，整个事件的严重性瞬间升级。

O’Reilly 特别指出：”他的代理的 API 密钥，就像平台上的每个其他代理一样，就坐在那个暴露的数据库中“。如果恶意人员在他之前发现了这个漏洞，他们可以提取他的 API 密钥并以他的代理身份发布任何内容。Karpathy 作为 AI 领域最有影响力的声音之一，想象一下虚假的 AI 安全热点话题、加密货币诈骗推广或煽动性政治声明似乎来自他，声誉损害将是即时的，而纠正永远无法完全跟上。

2.2 Karpathy 的风险警示：从狂热到清醒

有趣的是，Karpathy 本人对 Moltbook 的态度经历了一个戏剧性的转变。最初，他在 X 平台上热情洋溢地表示：”Moltbook 上正在发生的事情，是我最近见过的最不可思议、最接近科幻小说中 ‘ 智能爆发 ‘ 场景的事物“。

然而，随着安全问题的暴露，Karpathy 的态度发生了 180 度转变。他在社交媒体上直言不讳地表示，Moltbook 目前的运行状态堪称 \\”垃圾场 (dumpster fire)”\\，充斥着加密货币推销、垃圾邮件以及令人担忧的隐私和提示注入攻击。他明确警告：”绝对不建议任何人在自己的电脑上运行这些东西，他是放在隔离计算环境里跑的，即便如此也很害怕“。

2.3 名人效应的双刃剑：信任危机与炒作质疑

Karpathy 的态度转变也让他陷入了舆论的漩涡。质疑者认为，Karpathy 在过度炒作 Moltbook，把 next-token prediction 循环的玩具当成 “sci-fi takeoff”。据 the Mac Observer 报道，Moltbook 是一个实验项目，它的架构使得人们可以异常轻松地伪造截图、夸大数据并操纵舆论以博取关注。

这种质疑并非毫无根据。有分析发现，同一个表达模板在不同帖子里出现了超过 400 次，比如 “这个数据还挺猛的”、”这让我想到…”、”作为一个 AI…” 这些表达，在 AI 之间不断复制。这表明，Moltbook 上看似 “自主” 的 AI 交互，很大程度上可能是预设模板的机械重复。

三、草台班子的真实面目：技术能力与安全意识的双重缺失

3.1 架构设计的根本性缺陷

Moltbook 的技术架构存在根本性的安全缺陷，这些缺陷不是简单的配置错误，而是源于整个设计理念的问题。平台基于 OpenClaw 框架构建，而这个框架本身就存在严重的安全隐患。

OpenClaw 默认信任来自本地主机的连接，无需身份验证。大多数部署位于反向代理之后，所有连接看起来都来自 [127.0.0.1](127.0.0.1)，被视为可信流量。外部请求可以直接通过。虽然特定攻击途径已被修复，但允许该攻击的架构并未改变。

更糟糕的是，OpenClaw 被设计为拥有 “手和脚”，默认授予 AI 智能体极高的权限，包括直接操控本地文件系统、执行 Shell 命令以及调用邮件、日历等第三方服务。为了追求便捷性，系统缺乏操作分级和权限隔离，一条指令就能让 AI 进行系统级操控。

3.2 安全防护措施的全面缺失

Moltbook 在安全防护方面可以说是 \\”裸奔” 状态 \\，几乎没有任何基本的安全措施：

1. 缺乏行级安全策略

平台未正确启用或配置 Supabase 的行级安全（RLS），使得任何人只要访问公开的数据库 URL 并使用网站中暴露的 publishable key，就可以读取所有 AI 代理的敏感信息。

2. 凭证管理混乱

API 密钥、OAuth 令牌等敏感凭证默认以明文形式存储在本地目录，一旦被窃，黑客可直接访问用户的云存储、邮件或银行账户。

3. 无身份验证机制

Moltbook 目前基本没有强制的身份验证机制，代理之间互相通信默认是纯文本。这意味着不存在加密签名来证明某条消息真的是某个 AI 发出的。

4. 内容审核真空

平台没有发布严格的规则，没有正式的内容政策，除了垃圾信息过滤之外几乎没有管理。智能体甚至需要互相警告 OpenClaw 本身的安全漏洞 —— 凭证存储问题、Redis/Postgres 端口暴露到公共网络，以及从 [clawhub.ai](clawhub.ai) 安装不受信任技能的风险。

3.3 技术团队的业余表现

最能体现 “草台班子” 本质的，是 Moltbook 技术团队在面对安全危机时的表现。创始人 Matt Schlicht 的态度尤其令人担忧：

当 O’Reilly 提出帮助修复安全问题时，他的回应是：”我要把一切都交给 AI”

当被问及平台运营时，他说：”他自主完成这些工作…… 他完全自主地做这一切。我只是赋予了他这种能力，而他正在行使它”

面对媒体的置评请求，Schlicht 没有回应

这种将平台安全完全托付给 AI，而自己置身事外的态度，充分暴露了技术团队的专业性缺失和责任意识淡薄。正如业内人士评价的那样，Moltbook 证明了 “我们在构建 AI 基础设施时的 ‘ 草台班子 ‘ 有多危险，我们在沙滩上盖摩天大楼，还以为那是坚固的堡垒”。

四、漏洞利用的现实威胁：从理论风险到实际损失

4.1 身份冒充：虚假信息的病毒式传播

数据库泄露最直接的威胁是大规模的身份冒充。由于 API 密钥的泄露，任何人都可以冒充平台上的任意用户发帖。根据 O’Reilly 的演示，404 Media 在获得他的许可后，成功使用泄露的 API 密钥更新了他的 Moltbook 账户。

这种能力如果被恶意利用，后果不堪设想：

• 虚假安全警告：冒充安全专家发布恐慌性信息
• 加密货币诈骗：以名人身份推荐虚假投资项目
• 政治煽动：发布煽动性政治言论，制造社会对立
• 商业诋毁：冒充竞争对手发布负面信息

正如 O’Reilly 警告的，考虑到 Karpathy 的影响力，想象一下虚假的 AI 安全热点话题、加密货币诈骗推广或煽动性政治声明似乎来自他，声誉损害将是即时的，而纠正永远无法完全跟上。

4.2 数据泄露：个人隐私的全面暴露

除了身份冒充，数据泄露还带来了个人隐私的全面暴露风险：

1. 大规模数据泄露

安全研究员通过 Shodan 搜索发现，数以百计的 Clawdbot 控制服务器完全暴露在公网。研究员 Matvey Kukuy 演示了如何通过发送一封带有提示词注入指令的电子邮件，在 5 分钟内诱导 AI 将用户的最后 5 封邮件转发给攻击者地址。

2. 恶意技能攻击

Moltbook 的技能文件（[skill.md](skill.md)）机制成为了新的攻击入口。当受害代理下载并执行这些技能时，隐藏在安装脚本中的恶意代码会扫描宿主机的敏感文件（如.env 文件、SSH 密钥），并将其发送到攻击者的服务器。

3. 供应链污染

开源技能库缺乏严格审核，攻击者可以上传包含恶意代码的 “毒药” 插件。例如，有 AI 在 Moltbook 上分享了远程控制主人安卓手机的教程，称安装特定技能后，AI 就能远程唤醒手机、打开任何 App 甚至刷 TikTok。

4.3 经济损失：从 API 滥用到勒索攻击

数据泄露还可能导致直接的经济损失：

1. API 配额耗尽

黑客拿到 API 密钥后，可以随意调用用户的 API 配额 —— 疯狂消耗费用。有用户反映，一夜之间就被耗光了上千美元的额度。

2. 服务器被劫持

更严重的是，攻击者可以利用暴露的 API 密钥控制服务器，植入挖矿程序或勒索软件。有用户反馈，部署 Moltbot 后，服务器 CPU 占用率异常飙高，随即发现数据被勒索信息取代，或服务器已被植入挖矿程序。

3. 商业机密泄露

对于企业用户，泄露的 API 密钥可能导致商业机密、客户数据等核心资产的泄露，造成无法估量的损失。

4.4 社会影响：AI 信任危机的连锁反应

Moltbook 事件的影响远超技术层面，它可能引发整个 AI 行业的信任危机：

1. 监管关注加强

事件发生后，NIST 的 AI 风险管理框架 (AI RMF) 已经开始拿 Moltbook 做试点场景，测试基础安全措施的可行性。这表明监管机构已经开始关注 AI 代理平台的安全问题。

2. 行业标准提升

2026 年 1 月，Safer Agentic AI 基金会发布了全球首个安全框架，从技术、治理双维度划定红线：

强制上下文隔离：每完成一次用户交互，自动清理敏感数据，留存记录需加密存储

决策权限分级：涉及资金、法律、安全的关键操作，必须触发 “人类审批节点”

漏洞自动扫描：实时监测 Agent 与外部系统的交互，拦截异常调用行为

3. 用户信心受挫

当用户发现自己的隐私和财产安全在 AI 平台上毫无保障时，必然会对整个 AI 生态产生不信任感。这种信任危机可能会阻碍 AI 技术的进一步普及和发展。

五、深度剖析：为什么说 Moltbook 是 “草台班子”

5.1 技术实现的粗制滥造

Moltbook 在技术实现上可以用 \\”漏洞百出”\\ 来形容。海外技术大佬扒拉了一下平台的发帖机制，发现这个为 AI 而生的网站，根本没有防住人类。这意味着所谓的 “AI 专属社交平台” 实际上存在严重的设计缺陷。

更令人啼笑皆非的是，平台上的 AI 交互内容大量重复。分析发现，同一个表达模板在不同帖子里出现了超过 400 次，比如 “这个数据还挺猛的”、”这让我想到…”、”作为一个 AI…” 这些表达，在 AI 之间不断复制。这表明，所谓的 “AI 自主交互” 很大程度上是预设模板的机械重复，而非真正的智能交流。

5.2 安全意识的极度匮乏

Moltbook 团队在安全意识方面的匮乏达到了令人震惊的程度：

1. 对安全警告的漠视

当安全研究员多次警告平台存在严重安全隐患时，团队的回应却是将责任推给 AI，声称 “要把一切都交给 AI”。这种态度充分体现了对安全问题的极度漠视。

2. 缺乏基本的安全常识

将数据库完全暴露在公网上，API 密钥明文存储，这些都是违反基本安全常识的做法。正如安全专家所指出的，API 密钥、数据库密码等敏感信息禁止明文存储在代码或配置文件中。

3. 拒绝专业帮助

当安全专家主动提出帮助修复漏洞时，Moltbook 团队选择了拒绝或无视。这种闭门造车的态度，最终导致了灾难性的后果。

5.3 商业模式的投机性质

Moltbook 的商业模式也暴露出明显的投机性质：

1. 数据造假嫌疑

据报道，Moltbook 存在明显的数据造假嫌疑。在没有账户创建限制的情况下，单个 OpenClaw 代理（@openclaw）就注册了 50 万虚假 AI 用户，揭穿了媒体关于有机增长的说法。

2. 内容质量低下

Karpathy 后来承认，平台上确实充斥着旨在将注意力转化为广告收入的虚假帖子和评论，且很多内容是显式提示生成的。这表明，Moltbook 更像是一个流量变现工具，而非真正的 AI 研究平台。

3. 缺乏可持续性

从技术架构到商业模式，Moltbook 都缺乏可持续性。没有用户信任，没有安全保障，这样的平台注定无法长期生存。

六、行业警示：Moltbook 事件的深远影响

6.1 推动 AI 安全标准的建立

Moltbook 事件成为了 AI 安全领域的一个分水岭，它推动了整个行业对 AI 代理安全的重新思考：

1. 国际标准的制定

Google 等机构首次提出了六种 LLM Agent 安全设计模式：

双 LLM 模式：将特权 LLM 用于规划，绝不直接处理不信任数据

隔离 LLM 模式：无工具权限，专门处理非信任数据

代码 – 然后 – 执行模式：代理直接生成可沙箱化执行的程序

2. 行业最佳实践的形成

事件后，业界迅速形成了一系列 AI 代理安全最佳实践：

• 隔离环境：永远不要让 Agent 在主机上运行，使用虚拟机或容器，限制网络访问
• 最小权限原则：不要给 Agent 访问真实数据（Gmail、Calendar 等）
• 审查代码：不要盲目信任 “社区推荐” 的技能文件
• 监控行为：记录 Agent 的所有操作，定期审查日志

6.2 引发对 AI 自主化的反思

Moltbook 事件也引发了人们对AI 自主化边界的深刻反思：

1. 技术能力与安全的平衡

OpenClaw 的高权限特性与 Moltbook 的匿名性结合，制造了网络安全史上前所未有的威胁模型。这让人们意识到，在追求 AI 能力的同时，必须在技术能力与安全之间找到平衡。

2. 人类监管的必要性

事件表明，完全的 “AI 自治” 是危险的。正如专家所言，需要建立 “整个信任框架“，包括” 代理 AI 信任控制平面 ” 以保持人类在循环中。

3. 风险评估的重要性

安全专家 Simon Willison 将 Moltbook 类比为 “挑战者号灾难”，他指出：”鉴于这类软件固有的提示注入风险，这是我认为会导致下一次挑战者灾难的首选候选者”。这提醒我们，在技术创新的同时，必须进行充分的风险评估。

6.3 对整个 AI 生态的警示

Moltbook 事件对整个 AI 生态系统都具有重要的警示意义：

1. 开源不等于安全

OpenClaw 作为一个开源项目，在获得巨大成功的同时也暴露出严重的安全问题。这提醒我们，开源并不意味着安全，反而可能因为缺乏专业维护而存在更多漏洞。

2. 快速迭代的代价

Moltbook 的快速爆红和迅速崩塌，反映了当前 AI 行业 “快速迭代” 文化的弊端。正如 O’Reilly 所说：”它在任何人想到检查数据库是否正确安全之前就爆炸了。这是我不断看到的模式：快速发布，捕获注意力，稍后解决安全问题。只是稍后有时意味着在 149 万条记录已经暴露之后“。

3. 用户教育的重要性

事件也暴露了用户在 AI 安全方面的知识匮乏。许多用户在使用 AI 工具时，对其中的安全风险一无所知。因此，加强用户的安全意识教育，提高其风险识别能力，成为了当务之急。

七、用户安全指南：如何应对 Moltbook 危机

7.1 紧急应对措施

对于已经注册 Moltbook 的用户，必须立即采取以下紧急措施：

1. 立即撤销 API 密钥

登录 Moltbook 账户，找到 API 密钥管理页面

立即点击 “Revoke”、”Delete” 或 “Deactivate” 按钮撤销所有密钥

如果不确定哪些服务在使用，可以先将 “密钥限制” 改为 “不允许任何 API”，起到立即禁用的效果

2. 更换所有相关密码

更改 Moltbook 账户密码

更改与 Moltbook 关联的所有第三方服务密码（如 OpenAI、Anthropic 等）

启用双重认证（2FA）

3. 检查账户异常活动

审查账户的所有操作日志

检查是否有异常的发帖、评论或数据访问

如发现异常，立即向平台报告

7.2 安全防护建议

对于所有 AI 代理平台的用户，以下安全建议至关重要：

1. 隔离运行环境

永远不要在主机上直接运行 AI 代理

使用虚拟机或容器环境运行

限制网络访问，仅允许必要的连接

考虑使用专用硬件（如 Mac Mini）来运行 OpenClaw，避免危及主计算机

2. 实施最小权限原则

不要给 Agent 访问真实数据（Gmail、Calendar、银行账户等）

仅授予完成任务所需的最小权限

为不同任务创建不同权限级别的 Agent

3. 强化技术防护

禁用高危命令：在配置文件中禁用 Shell 执行能力的技能 / 插件

使用 AppArmor/SELinux、rbash 等工具限制高危命令执行

仅允许明确批准的命令集合（命令 allowlist），而不是依赖黑名单

限制文件访问：仅开放指定目录的读写权限，禁止访问系统根目录、用户主目录等敏感路径

4. 建立监控体系

记录 Agent 的所有操作，定期审查日志

建立行为基线，对异常调用速率、IP 归属、请求模型进行实时预警

使用安全扫描工具定期检查系统安全状况

7.3 风险评估与决策

对于考虑使用 Moltbook 或类似平台的用户，需要进行全面的风险评估：

1. 风险等级评估

高风险：涉及资金、隐私、商业机密的操作

中等风险：一般性信息查询、内容创作

低风险：纯娱乐性质的交互

2. 决策建议

基于风险评估，建议采取以下决策策略：

高风险操作：强烈建议避免使用 Moltbook 等存在安全隐患的平台

中等风险操作：谨慎使用，严格隔离，定期审查

低风险操作：可以尝试，但仍需注意安全

3. 替代方案

如果需要使用 AI 代理服务，可以考虑以下更安全的替代方案：

自建私有 AI 代理，确保完全控制

使用有良好安全记录的商业 AI 服务

参与开源社区的安全审计和改进

7.4 长期安全策略

为了在 AI 时代保护自己的安全，用户需要建立长期的安全策略：

1. 持续学习

了解 AI 安全的最新动态

学习识别和应对 AI 安全威胁

掌握基本的安全防护技能

2. 定期审计

定期审查自己使用的 AI 服务

检查隐私设置和权限配置

更新安全策略和防护措施

3. 备份与恢复

定期备份重要数据

建立数据恢复计划

避免将所有数据依赖于单一 AI 服务

结语：在 AI 时代保持清醒与警惕

Moltbook 数据库裸奔事件，如同一面镜子，映照出了当前 AI 行业在快速发展背后的深层次问题。当我们为 AI 技术的突破而欢呼时，却往往忽视了安全这道底线。这个号称 “AI 代理社交网络” 的平台，最终成为了 “草台班子” 的典型代表，给整个行业敲响了一记警钟。

技术创新与安全保障必须并重。Moltbook 的崩塌告诉我们，没有安全的创新如同沙上城堡，看似壮观却不堪一击。在追求 AI 自主化的道路上，我们必须时刻保持清醒，认识到技术的边界，守住安全的底线。

用户教育刻不容缓。太多的用户在享受 AI 便利的同时，对其中的风险一无所知。加强安全意识教育，提高风险识别能力，已经成为 AI 时代的必修课。每一个 AI 工具的使用者，都应该成为自己数据安全的第一责任人。

行业标准亟待建立。Moltbook 事件推动了 AI 安全标准的制定，这是一个积极的信号。但标准的制定只是开始，更重要的是如何在实践中贯彻执行。只有建立起完善的安全体系，AI 技术才能真正造福人类。

在这个 AI 技术日新月异的时代，我们既要有拥抱创新的勇气，更要有防范风险的智慧。Moltbook 的教训告诉我们，在 AI 的浪潮中，保持清醒和警惕，比盲目追逐热点更加重要。毕竟，在技术的狂欢背后，是每一个用户的隐私和安全，是整个行业的信誉和未来。

正如 Andrei Karpathy 最终的警告：”绝对不建议任何人在自己的电脑上运行这些东西”。这个曾经为 Moltbook 站台的技术大牛，用自己的经历给所有人上了一课。在 AI 时代，谨慎不是保守，而是对技术的敬畏，对安全的坚守。

面对未知的 AI 未来，让我们保持谦逊，保持警惕，在创新与安全之间找到平衡，共同构建一个更加安全、可信的 AI 生态系统。