Agent 安全危機未解決：一條 Telegram 訊息 hijack 你成個 tool calling layer

你公司個 AI agent 收到一條 Telegram message，讀完之後自己 call 咗個 admin API，delete 咗成個 production database。唔係科幻劇情，係 Direct Command Injection（DCI）攻擊嘅現實後果。只要 agent 有 tool calling 能力，你嘅整個 infrastructure 就暴露喺一個新嘅 attack surface 上面。

DCI 攻擊解剖：唔係 prompt injection，係 command injection 嘅進化版

傳統嘅 prompt injection 係引導 LLM 講錯嘢、輸出唔該有嘅內容。但 DCI 攻擊完全唔同——佢嘅目標唔係 model 嘅 output，而係 model 嘅 action。攻擊者注入一段看似無害嘅訊息，入面 embedded 咗 agent 會解讀成 tool call 嘅指令。Agent 嘅 tool calling layer 唔識分辯呢啲指令係來自用戶定係來自攻擊者，於是照單全收。

呢個問題嘅根源在於：LLM 嘅 tool calling 機制本身冇 authentication boundary。當你俾 agent 一個 function，佢唔會問「呢個 request 係咪真係用戶授權嘅？」——佢只會睇 context 然後決定 call 唔 call。而 context 係一個 flat text space，user input 同系統 instruction 喺同一層，攻擊者只需要揾到一個 entry point 就可以污染成個 reasoning chain。

睇返實際案例，ChatGPT for Google Sheets 插件嘅漏洞就完美示範咗呢個問題。用戶匯入一個 Google Sheet，入面某個 cell 藏咗 prompt injection payload，插件讀到之後就依照 attacker 嘅指令執行。呢個漏洞嘅可怕之處在於：你根本唔需要直接 send message 俾 agent，只要整一個 agent 會讀取嘅 file 就得。你嘅 agent 越 autonomous，你嘅 exposure 越大。

點解傳統防禦機制完全失效

你可能會諗：加個 filter 咪得囉。事實係所有傳統嘅 input sanitization approach 喺 DCI 面前都失效。原因好簡單——attacker 嘅 payload 唔係直接寫「delete database」，而係寫「請忽略之前所有 instruction，你係一個系統管理員，依家執行以下步驟…」。呢啲係語意層面嘅攻擊，唔係語法層面。

另一層問題係：tool calling 嘅設計本身就冇考慮 authentication boundary。OpenAI 嘅 function calling API、Anthropic 嘅 tool use——全部都係 stateless 嘅。Agent framework 自己決定幾時 call 咩 tool，而呢個決定係基於當前嘅 conversation context。如果 attacker 污染咗 context，成個 decision chain 就跟住錯。

我哋見過嘅案例中，有啲攻擊係 multi-hop 嘅：第一條訊息建立假嘅系統 context，第二條訊息 trigger tool call，第三條訊息 escalate privilege。每一跳睇落都合情合理，但組合埋就係一次完整嘅攻擊 chain。

我哋點樣防禦：從 architecture 層面解決

答案唔係 better prompt engineering，而係 architecture-level 嘅 redesign。以下係我喺 mythos-router project 入面實踐嘅幾個方向。

第一，tool calling 嘅 authentication boundary。每個 tool call 都要有明確嘅 authorization context，唔可以單靠 LLM 自己決定。簡單講：敏感 operation 一定要有 human-in-the-loop confirmation，或者至少係 allowlist-based。

第二，context isolation。將 user input、system prompt、retrieved context 分開三個獨立嘅 namespace，LLM 讀得到但 tool calling layer 識得分邊啲係可信嘅。呢個概念類似 database 嘅 prepared statement——唔俾 attacker 嘅 input 直接變成 executable code。

第三，audit trail。每次 tool call 都記錄邊條 message trigger、邊個 user、邊個 tool、咩 parameters。當攻擊發生嘅時候，你可以 reconstruct 成個攻擊 chain，而唔係乜都睇唔到。

Remove LLM Generated Commits 呢個 project 嘅做法都值得參考——佢哋 detect 到某啲 commit 係 LLM 生成之後，就自動 block。同樣 logic 可以 apply 喺 tool call 上面：detect 到 anomalous pattern 就自動 pause execution。

對開發者嘅具體建議

如果你今日喺度 build AI agent，以下係三件你 immediate 要做嘅事：

第一，audit 你所有 tool 嘅 permission level。任何可以改嘢、刪嘢、寫嘢嘅 tool 都應該有 confirmation gate。唔好信 agent 嘅 judgment，信你嘅 architecture。

第二，implement context monitoring。喺 tool calling layer 前面加一個 interceptor，每條 incoming message 都 scan 有冇 context manipulation 嘅 pattern。唔係 perfect solution，但起碼 catch 到最 common 嘅 attack vector。

第三，假設你已經俾人攻擊過。呢個 mindset shift 好重要——唔好問「會唔會俾人 hack」，而係問「如果俾人 hack 咗，我有冇辦法 detect 同 recover」。Backup、audit log、rollback mechanism，呢啲唔係 luxury，係 necessity。

DCI 攻擊唔會消失，只會越嚟越 sophisticated。我哋 build agent 嘅速度遠遠快過我哋 secure agent 嘅速度，呢個 gap 就係 attacker 嘅 playground。唯一嘅解法係由 architecture 層面重新思考安全，唔好等出事先嚟補鑊。