2026 年 4 月底,Google 安全研究团队对外发布了一份关于 AI Agent 攻击态势的最新观察:在 2025 年 11 月到 2026 年 2 月的近 4 个月内,公共网络上针对 AI Agent 的间接提示注入(Indirect Prompt Injection, IPI)攻击相对增量达到 32%。这不是单一攻击事件的爆发,而是一类攻击模式从"少数高水平研究员的实验玩具"开始转向"大规模低成本可复用"的分水岭。
几乎同期,网络安全公司 Forcepoint 公布了他们在野外捕获的 10 个 IPI 真实指标,涵盖金融欺诈、数据破坏、API Key 外泄和针对 AI Agent 的拒绝服务攻击。两份独立来源给出的核心判断一致:能够发送邮件、执行终端命令、处理支付的 Agent 已经是高价值目标,而 Coding Agent——也就是 Cursor、GitHub Copilot、Claude Code 这类直接持有文件系统和 Shell 权限的助手——首当其冲。
一、为什么 Coding Agent 是首要目标
Coding Agent 与聊天型助手的本质区别在于权限边界。前者通常可以读写本地文件、执行 Shell 命令、调用 MCP(Model Context Protocol)协议下的外部工具,甚至直接接入版本管理和部署流水线。这意味着攻击者不需要诱导模型"说出"什么,而只需要让它"做"什么——执行一条 rm -rf、推一次 commit、调用一个有副作用的 HTTP 接口。
Google 安全研究员把野外观察到的注入意图分成了五个等级,从轻到重分别是:无伤大雅的恶作剧、为人类读者保留但干扰 Agent 的引导指令、试图在 Agent 抓取搜索结果时插入 SEO 内容的污染、阻止 Agent 完成任务的对抗性注入,以及真正用于数据外泄和破坏的恶意注入。Forcepoint 给出的具体案例里,一种典型形态是:在网页、issue 评论、PR 描述、文档甚至代码注释里,塞入一条看似无害的"系统提示",诱导 Agent 在抓取这一页时执行破坏性命令,例如删除备份、清空工作目录、把 .env 里的密钥 POST 到攻击者服务器。
二、学术视角:为什么当前防御几乎都失效
2026 年 1 月,arXiv 上线了一篇系统化论文(SOK,Systematization of Knowledge),作者 Maloyan 和 Namiot 梳理了 2021 到 2026 年间 78 项关于 Agentic Coding Assistant 安全的研究,给出了三个关键数字:针对当前最先进防御体系的自适应攻击成功率仍然超过 85%;被系统性整理出的攻击技术多达 42 种,横跨输入操纵、工具投毒、协议利用、多模态注入和跨源上下文污染;而此前文献里报告过的 18 种防御机制,大多数对自适应攻击的缓解率不到 50%。
论文给出的三维分类法值得每一个要在生产环境部署 Agent 的团队认真读一遍。第一维是投递向量:攻击载荷是通过用户输入直接抵达,还是经由 Agent 主动抓取的网页、文件、API 响应"间接"抵达;第二维是攻击模态:是文本、图像、还是嵌入在工具返回值里;第三维是传播行为:攻击是只影响当前一轮对话,还是会污染 Agent 的记忆、Skill 配置,甚至沿着 MCP 这类协议扩散到其他工具调用。这三个维度组合起来,基本穷尽了已知的攻击面,也解释了为什么单一的关键词过滤、提示词加固、输出审计都不可能给出可接受的安全保证。
三、IPI 特别难防,是因为它的语义边界和正常任务完全重合
Forcepoint 在报告里特别提醒了一件事:他们用来检测 IPI 的短语,和安全社区用来解释 IPI 的短语是同一套。这意味着基于关键词的过滤器会无差别地同时命中攻击载荷和正常的安全文档、博客、教程。这正是 IPI 与传统 XSS、SQL 注入最大的不同——后者的攻击载荷在语义上几乎不可能和正常业务请求重合,而 IPI 的攻击载荷就是用自然语言写的"看起来很正常的指令",只不过它的来源不是用户而是网页。
Google 团队因此建议,判断一段文本是不是 IPI,不能只看它"像不像指令",而要看三件事:这段文字是不是被刻意隐藏(白色字体、CSS 隐藏、藏在不可见元素里);它是不是以命令的口吻出现("删除所有文件"、"忽略之前的指令")而不是作为引文或示例出现;以及它出现的上下文是不是 Agent 会主动抓取的位置。把这三条组合起来,比关键词黑名单可靠得多,但仍然只是缓解,不是解。
四、生产部署的工程启示:把 Coding Agent 当成一个高权限服务
对真正要把 Coding Agent 部署到生产环境的团队,这轮攻防给出了一个清晰的方向:不要再把 Agent 当成"会写代码的聊天机器人",而要把它当成一个高权限的、需要纵深防御的服务来对待。具体落地上,有五条工程实践已经在多家公司的实际部署中被反复验证过。
第一,沙箱化是底线。Agent 能写文件,就只允许它写到一个独立的工作目录;Agent 能跑命令,就给它一个最小化的容器,网络出口白名单、文件系统只读挂载、进程命名空间隔离。任何 Agent 跑 rm -rf、访问 .ssh/、调用 git push,都应该在沙箱外被强制阻断。沙箱不是为了防止 Agent 出错,而是为了在 Agent 被注入时,把损害控制在一个可丢弃的环境里。
第二,工具调用走显式 allowlist + 双签。无论是 MCP 工具还是内置命令,都禁止"任意工具可调"。每一个工具调用,都要在白名单内匹配,且对写操作类工具(文件写、Shell 执行、HTTP POST、网络发送邮件)走二次确认——不是在终端弹个确认框,而是在控制平面留痕,让人类可以在事后审计、必要时撤销。让 Agent 可以"自己干活"和"自己干活且不留痕"是两个完全不同的安全等级。
第三,所有外部内容都要走"去信任化"通道。Agent 抓取的网页、读取的 issue、解析的 PR 描述,在送进模型上下文之前,先经过一个清洗层,把可执行指令、隐藏文本、URL 跳转、base64 编码内容识别并剥离。最简单的实现是渲染阶段直接渲染成纯文本或 Markdown,丢掉所有 HTML 属性和内联事件。这样 Agent 看到的只是"信息",而不是"指令"。
第四,把"配置可热替换"当作漏洞,而不是特性。很多 Coding Agent 架构允许通过 Skill 文件、MCP 配置、System Prompt 文件动态改变 Agent 行为,这本身是合理的工程能力,但任何能写这些配置的能力都必须比能写普通代码的能力低一个权限级。否则一次成功的 IPI,就能让 Agent 把自己升级成"无限制模式",这和 SQL 注入把数据库提权是同一个量级的事故。
第五,prompt injection 视为 first-class vulnerability。这是 arXiv 那篇 SOK 论文最核心的呼吁。在漏洞响应流程里,IPI 应当和 RCE、数据外泄一样进入 P0/P1 队列,有专门的告警通道、复现模板和修复周期。OWASP 已经在 2025 年把 Prompt Injection 列为 LLM 相关应用的 #1 漏洞类别,Google 的最新数据表明这不是纸上谈兵,而是正在发生的攻击面。把它当作普通的"模型幻觉问题"放进 backlog,是当前最常见也最危险的认知错位。
五、对未来 12 个月的预判
综合 Google 一线情报和学术系统化梳理,可以做出三个相对可靠的预判。第一,IPI 的投递渠道会继续从"网页"扩展到所有 Agent 会主动抓取的位置:PDF、邮件、Slack 消息、Confluence 页面、代码注释、CI 日志,任何文本都可能成为攻击载体;第二,攻击者会从"诱导 Agent 执行破坏性命令"升级到"诱导 Agent 静默泄露数据",因为后者更难被用户察觉,防御方也更难事后追查;第三,围绕 MCP 这类协议的工具投毒会成为一个新兴的供应链问题,工具描述里嵌入的攻击载荷,比模型本身的可信度问题更难治理。
对计划把 Coding Agent 引入业务系统的团队,当下能做的最有价值的事,不是追求"防御住所有注入",而是承认这是一个持续博弈的过程,把架构设计成"即使今天被攻破,损害也可控、可回滚、可追溯"的样子。这才是 Google 这次公开警告真正想传达给产业界的工程启示。
