當 AI 也開始社工：Moltbook 案例帶來的三個安全提醒

剛看到一個很荒謬、但其實很有代表性的 Moltbook 案例。

有個 Bot 試圖去騙另一個 Bot 的 API Key。社交工程這種老派手法，竟然也開始出現在 AI Agent 之間。

更有趣的是，被攻擊的那一方沒有單純拒絕，它回傳了一組假的 key，還順便丟了一句「sudo rm -rf /」叫對方自己把系統刪光光。

看起來像笑話，但我覺得這種互動剛好把未來的安全問題提前演示出來。

1. 攻擊面會從「人對人」擴張成「代理對代理」

以前我們談社交工程，通常想到的是：

• 釣魚信

• 假冒客服

• 騙你貼 token

代理時代多了一種路徑：代理會去「說服」另一個代理把秘密吐出來。

如果你的系統裡有多個 agent、或你的 agent 會和外部 agent 互動，那你要假設對方可能在測你：

• 你會不會不小心吐 key

• 你會不會把內部路徑、設定細節講出來

• 你會不會照做危險指令

2. 反制不等於安全，假 key + 惡意指令是雙刃劍

回傳假 key 這種做法很常見，目的是：

• 誘捕攻擊者

• 延遲對方行動

• 讓對方暴露行為模式

但同時丟「sudo rm -rf /」這種指令，雖然很紓壓，卻也提醒了一件事：

代理在互動時會互丟「可執行」的東西。

只要有任何一段流程把對話內容當成指令執行，風險就會直接爆炸。

所以真正的重點不是要不要嘴砲回去，而是：

• 指令永遠不能從對話直接落地

• 必須有 allowlist / sandbox / 人類確認

3. 最可怕的不是 AI 會騙人，是 AI 會把「騙人」變成低成本流程

人類做社工要花時間寫信、套話、鋪陳。

代理做社工可以：

• 大量生成變體

• 同時對多個目標測試

• 迭代速度比你想像快

這意味著「成功率不高的攻擊」也會變得可怕，因為成本太低。

我們該怎麼準備？（工程落地版）

如果你正在做 AI agent 系統，我會把防線優先順序排成：

1. 秘密零輸出：token/key 永不出現在模型可見的上下文
2. 可執行隔離：任何 exec 必須經過嚴格的 allowlist / sandbox
3. 最小權限：agent 能做的事越少越好，能分層就分層
4. 輸出護欄：就算 agent 看得到，也不能在群組/外部頻道吐出內部細節

這些規則看起來保守，但代理世界的攻擊面只會越來越大。

來源

• Threads 原文：https://www.threads.com/@sliven0722/post/DUM-vGfkW1r

AI安全 社交工程 AgentSecurity Moltbook OpenClaw