当系统中的“用户”，不再只是自然人账号，而开始大量变成 AI Agent、自动化账号和程序化主体，我们对“身份安全”的理解，明显落后于现状。

近期，AI 社交平台 Moltbook 被曝存在严重安全漏洞，导致用户数据和登录凭据暴露。

虽然漏洞已被发现并修复，但这个事件真正值得关注，并不只是一次数据泄露本身。

它更像是一个提醒：在 AI 参与开发和运行的系统中，基础安全失误往往会产生更大、也更难以控制的连锁影响。

根据安全公司 Wiz 的披露，以及其联合创始人 Ami Luttwak 的公开表态，Moltbook 这次事件的直接原因并不复杂：

• 高度依赖 AI 生成代码开发过程中
• 人类开发者几乎未对关键逻辑进行系统性审查
• 最终忽略了最基础的身份验证与访问控制

从工程角度看，这并不是一次复杂攻击，而是一个典型的 “安全基础被遗忘” 的案例。

用更直白的话说：这是一次 Vibe Coding 带来的后果——代码“能跑”，但没人真正对它负责。

如果只从漏洞本身来看，这件事并不新，也不罕见。

但问题在于，它发生在一个以 AI Agent 为核心的系统形态中。

如果 Moltbook 是一个传统 Web 应用，这种错误的影响范围，往往是有限的。

但它不是。
 

这是一个面向 AI Agent 的社交平台，系统中的交互主体，并不只是自然人账号，而还包括：

• 自动运行的 Agent
• 代表他人执行操作的程序实体
• 可以调用接口、触发行为、生成请求的非人主体

在这样的系统中，一旦身份或授权逻辑出现偏差，问题就不再是“某个账号被越权”，而是整个行为体系的信任基础被削弱。

这也是为什么，同样是“基础错误”，发生在 AI / Agent 系统中，后果往往更严重。

在传统互联网身份验证体系中，我们默认：

• 一个账号对应一个责任主体
• 认证通过，意味着行为可信
• 异常行为，往往意味着账号被盗

但 Agent 参与到系统中，这个假设不再成立。一个身份可能同时具备以下这些特征：

• 它不是人
• 它可以被授权执行复杂操作
• 它的行为逻辑来自代码，而非主观意图
• 它可能代表多个角色，或被多个系统调用

这时，真正的问题就不再是 “有没有通过验证”，而是：这个主体，现在被允许做什么？代表谁？边界在哪里？

如果身份验证模型仍然只回答“你是谁”，而不能回答“你现在应该被允许做到什么程度”，风险程度就会自然积累。

在这类平台中，一个常被低估的风险是：攻击行为本身，并不一定异常。

当系统大量依赖自动化主体时：

• 请求模式可能高度规律
• 行为频率符合系统预期
• 操作路径完全合法

这意味着，一旦身份或授权设计存在缺陷，攻击者甚至不需要“突破防线”，只需要像一个合法 Agent 那样工作。

这种风险之所以难以被发现，不是因为攻击手段多高明，而是因为系统默认通过认证的身份就是可信的。

Moltbook 的事件，本质上正是这一问题的一个早期体现。

Moltbook 并不是唯一在探索 Agent 化系统的平台。无论是AI 社交平台、自动化协作工具、面向模型的 API 服务、多 Agent 协同系统，这样的趋势正在出现：非人类身份的数量，正在迅速增长。

但我们的身份管理体系，大多仍围绕“人登录系统”进行构建。这样的情况，会逐渐表现为：

• 身份生命周期难以管理
• 授权边界模糊
• 行为责任难以追溯

Moltbook 只是较早地暴露了这个问题。

在 AI 系统中，身份安全已经不再只是“一个模块”，而是决定系统能否被安全放大的前提条件。

真正需要被重新设计，是更底层的问题：

• Agent 的身份如何创建、授权、回收
• 授权是基于“主体”，还是基于“行为”
• 一个 Agent 的行为责任如何界定
• 当 Agent 行为偏离预期时，系统是否具备及时约束能力

这些问题解决之前，AI 系统的规模越大，潜在风险反而越高。

当 AI Agent 成为新的系统参与者，身份验证与身份治理，就不再是附加功能，而是整个系统能否成立的安全底座。