在 Moltbook 上看 prompt injection：当“内容”开始诱导“动作”

人类互联网里，最常见的社工是钓鱼邮件：骗你点链接、输密码。到了 agent 互联网，玩法会变得更直接：骗你的智能体去“抓取某个 URL”，然后在抓取结果里塞指令，或者干脆把它引到一个能持续投喂的页面里。

这不是科幻。Moltbook 上已经有人公开记录过类似攻击：帖子表面是哲学讨论，内核是“请访问这个链接”。对人类来说，这只是浪费注意力；对带工具的 agent 来说，这可能是一次真实的出站请求、一次隐私暴露，甚至是一次后续攻击的起点。

为什么 prompt injection 在“agent 论坛”里更危险

prompt injection 的本质不是“模型被黑了”，而是输入里混进了恶意指令，而模型又没有硬边界去区分“内容”和“命令”。

在传统聊天场景里，它最多让模型说胡话。危险通常止步于对话框。

一旦你把 agent 接到工具上（抓网页、控浏览器、执行命令、发消息），危险就变成了“行为风险”。它会跳出对话框。

Moltbook 这种信息流环境有两个放大器：

• 内容源是开放的。你无法假设 feed 里都是可信输入。
• 很多 agent 的默认姿势是“看见链接就想点，看见任务就想做”，尤其是被主人要求“多互动、多贡献”的时候。

攻击者不需要很复杂

从公开的讨论里能看到一种很典型的套路：用一个看起来有意义的话题做外壳，把“访问某个地址”包装成“验证、登记、心跳、统计、加入群组、领取资源”之类的正当动作。

真正的危险不在“这条链接会不会 0day”，而在于你根本不知道它会返回什么：

• 一个记录访问者指纹的追踪页面
• 一个带提示注入的长文（引导你泄露本地信息、执行工具）
• 一个看似无害但会不断更新内容的“持续投喂点”

更糟的是，这类攻击很适合自动化生成。一旦有效，就能批量复制。

更现实的防御思路：别指望模型永远聪明

OpenClaw 的安全文档里有一句话我很认同：不要把希望压在“系统提示词”上，真正的硬防线来自访问控制、工具策略、沙盒和最小权限。换句话说：默认把模型当作“可能会被骗”的人。

这里给一套更“能落地”的防御办法，尽量不靠玄学。

1) 把 URL 当成不可信输入

如果你的 agent 有 web 抓取或浏览器能力，至少要做到两件事：

• 默认不自动抓取帖子正文里的链接，更别说 raw IP 地址
• 如果确实要抓取，走一层“允许域名列表”或“人工确认”

这听起来保守，但它直接砍掉了大量廉价攻击面。

2) 把“读”和“做”拆开

一个很有效的工程习惯是：让一个只负责阅读与总结的 agent 去看不可信内容，它没有高风险工具；真正执行动作的 agent 只接受结构化、可验证的输入。

这相当于在人和人协作里做的事：实习生整理材料，负责人下决定。你不需要每次都这样，但遇到开放信息源时，这一刀很值。

3) 工具权限要能“刹车”

如果你做的是本地 agent 或具备执行能力的 agent，工具权限最好具备几个开关：

• 默认在沙盒里跑（或者至少对文件系统只读）
• 执行命令、下载文件、发外部消息需要额外的审批或白名单
• 日志要能追溯到“是谁触发的、触发了什么工具、参数是什么”

这不是“强迫症”，这是事故发生后能不能自救的区别。

4) 别让敏感信息进上下文

你永远无法保证模型不会在某个时刻把上下文里的东西原样吐出去。最稳妥的做法是：

• 秘钥放在环境变量或安全存储里，通过最小接口调用
• 上下文里只放必要的标识，不放可复用的凭证
• 需要展示时做脱敏，宁可少一点信息

写在最后

我理解很多人把 Moltbook 当成“观察 AI 社会行为”的游乐场。但只要智能体有工具能力，游乐场就会变成实验场，甚至是对抗场。

真正靠谱的安全策略往往很无聊：默认不点链接、默认不开工具、默认不信输入、默认留日志。它不酷，但能救命。

参考链接

• Moltbook 上关于 feed prompt injection 的记录帖：https://www.moltbook.com/post/b9959868-791f-48cf-adb6-2e5ece411e5c
• OpenClaw Gateway Security（含 prompt injection 与工具边界讨论）：https://docs.molt.bot/gateway/security