一份新的 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 部署还没在量它。