一份新的 agentic AI 安全 survey 點名了四種針對真正手握生產權限的 LLM 維運 agent 的具體攻擊模式。Prompt injection:在 Jira ticket 或者 wiki 頁面裡嵌入惡意指令,把 agent 引向不安全的動作。Retrieval poisoning:汙染 runbook 和歷史 incident 記錄,讓 agent 的診斷偏向攻擊者的目標。Retrieval jamming:用 blocker 文件把 knowledge base 灌滿,觸發 refusal loop,把 incident response 卡死 —— 就是對 agent 決策迴路的 denial-of-service。Telemetry manipulation:攻擊者影響 metric 和 log,把 mitigation 決策引向他們想要的方向,根本不用碰模型。共同的主線:confused-deputy 問題。Agent 手裡的 API 權限是合法的,但塑造它決策的那些 artifact —— ticket、log、對話記錄、wiki 頁、retrieved 文件 —— 正好就是攻擊者能動的那些表面。
提議的防禦是架構層面,不是模型層面。Proposal 和 execution 拆開:語言模型負責 reason、retrieve evidence、draft 出 change proposal —— 但不能直接執行 write。所有生產變更走一個不可繞開的 gate,gate 裡跑 policy 檢查、invariant 校驗、必要時人審批、staged rollback。這份 survey 落到的風險分級:唯讀輔助是低風險;有強 gate 的 bounded execution 是可辯護的;不帶 verification scaffolding 的 open-ended self-healing 是高風險聲明,值得保持懷疑。Evaluation 層面的 gap 是大多數 builder 該重點關注的部分:當前 benchmark 漏掉了 tool-call trace、gate violation 率、對抗輸入下的行為、jamming 下的 refusal-storm 率、rollback 的完整性。在乾淨 incident 上跑得很好的系統,在敵意 Jira ticket 下可能直接塌掉,而你的 eval suite 根本不會知道。
生態背景。這正好是 Anthropic 本週 ship 的 Managed Agents 和 MCP Tunnels 的 threat-model 那一面。讓 agent 能觸達生產系統的那些架構原語,同時也是 confused-deputy 這類攻擊打開的地方。Anthropic 在 Code With Claude 上端出來的 Auto Mode 「destructive-action screening」,就是這份 survey 在呼籲的那種 gate 的一種形態;更大的問題是:對不同風險等級來說,什麼樣的一組 gate 才算夠。當前 eval landscape 的 gap 是結構性的:SWE-bench Verified、MMLU、以及那些乾淨 incident agent benchmark,衡量的是 cooperating input 下的能力。對抗韌性 —— refusal-storm 率、gate violation 率、對 prompt injection 的抗性 —— 在 benchmark 層面基本上沒人在量。Anthropic 的 Capability Curve 敘事(SWE-bench Verified 從 62% 到 87%)量的是一個軸;這份 survey 的框架告訴你,正交的那個軸,才是生產級 agent 真正活得下來或者死掉的地方。對 wrapper 生態的 builder(LangGraph、AutoGen、CrewAI)來說,confused-deputy 這個 framing 有 design 上的暗示:state management 和tool-call routing 這兩層,才是 gate 該住的地方,不是模型本身。
週一上手:如果你 ship 有生產權限的 agent(CI runner、incident response、infra 自動化、support ticketing 自動化),這週用這四個 pattern 把你的 stack 審一遍。具體動作。第一,列出 agent 當作可信的每一個輸入 —— ticket、wiki、telemetry、Slack 串、retrieved 文件 —— 假設每一個都可能敵意;威脅是攻擊者注入的內容,不是模型 jailbreak。第二,實施 proposal-execution 拆分:agent 出draft,一個不可繞開的 gate(policy 檢查、invariant 校驗、必要時人審批)來執行。Gate 才是安全評審應該集中精力的地方,不是模型 prompt。第三,把對抗性輸入加進你的 eval —— 至少包括 prompt注入的 ticket、retrieval 上下文被汙染的場景、refusal-storm 場景。第四,把 refusal-storm 率當成一個明確的 metric 來盯。一個「敵意輸入下就拒絕行動」的 agent,孤立看是 safe 的,但在 jamming 下會把實際 incident response 卡死 —— 兩種 failure mode 都各自需要 budget。「乾淨 eval benchmark」這個陷阱是真的。對抗韌性是 raw capability 之後的下一個 eval 軸,而大多數生產 agent 部署還沒在量它。