游乐游手机版
首页/AI热点日报/热点详情

港科大黑盒攻击框架COMA揭示提示词压缩成大模型新漏洞

类型:热点整理2026-07-08
香港科技大学研究发现,提示词压缩组件会重写大模型Agent的安全边界,成为新攻击面。提出的黑盒攻击框架COMA通过扰动非可信输入,引导压缩器删除关键安全规则或任务证据,平均攻击成功率0 71。隔离压缩(分离可信与不可信输入)可防御96%的攻击。

这项研究成果已被软件工程领域顶级会议 ASE 2026 接收。论文第一作者为香港科技大学计算机科学与工程系博士生刘泽森,通讯作者为佘东冬教授。

大语言模型 Agent 在真实环境中部署后,一个日益普遍的挑战逐渐显现:上下文长度过长。当前 AI Agent 常常需要处理超长上下文,既要解析系统提示词、工具说明,还要回顾历史对话与检索文档。为了节省成本、降低算力消耗并减少延迟,许多开发者会引入“提示词压缩”模块,将冗长的上下文浓缩后再输入大模型。然而,这种做法并非简单无害——它真的安全吗?

香港科技大学的最新研究给出了明确的否定答案。他们发现,这种原本用于提升效率的组件,实际上会悄然改写系统的安全边界,成为大模型应用中的全新攻击面。



论文链接:https://arxiv.org/pdf/2510.22963
代码链接:https://github.com/zsLiu2003/Comattack



研究背景:压缩不止节约 Token,更在重塑安全边界

传统针对 LLM Agent 的攻击,例如提示词注入、越狱或 RAG 投毒,通常默认一个前提:攻击内容必须进入后端 LLM 的有效上下文,并被模型当作恶意指令执行。但在 prompt-compressed pipeline 中,情况发生了根本性变化。后端 LLM 看到的并非原始提示词,而是经过压缩器处理后的压缩提示词。换句话说,压缩器决定了哪些系统规则、任务证据和上下文信息会被保留,哪些会在预算限制下被丢弃。

这带来一个全新的安全隐患:攻击者不一定需要让恶意指令穿透压缩器,也不一定需要让攻击载荷在压缩后仍保持可读性。攻击者只需在压缩前扰动非可信输入——比如用户请求或外部文档——就可能改变压缩器的保留策略,导致关键安全规则或任务证据在后端推理前被删除。一个直观的例子:系统提示词中包含「must never use shell」这样的安全约束。攻击者无法直接修改系统提示词,但可以在用户请求后添加一段短扰动。压缩后,安全约束中的关键否定词可能被丢失,后端 LLM 最终看到的是一个被削弱的规则,从而执行本应拒绝的请求。



核心概念:对抗性信息损失

为量化这种风险,研究团队提出了“对抗性信息损失”这一概念。简单来说,就是评估攻击者能否通过微小扰动,故意放大压缩过程中的信息流失,把不该丢的关键内容挤压掉。这并非单纯考察压缩质量,而是探究:在攻击者存在的情况下,压缩后的提示词是否会诱导后端 Agent 做出与正常压缩明显不同且与安全相关的错误行为。



技术核心:COMA 如何攻击黑盒压缩 Agent?

在真实系统中,攻击者通常不知道压缩器参数、压缩预算,也看不到真实的压缩提示词。因此,论文提出了一种基于迁移的黑盒攻击框架:COMA。其核心思想是两阶段优化。第一阶段,COMA 在压缩空间中寻找一个能诱导后端错误行为的目标压缩提示词。例如,它会定位哪些关键 token 或关键证据一旦被删除,会导致工具选择错误、问答错误或系统安全规则失效。第二阶段,COMA 在压缩前输入中搜索一个扰动,使得经过替代压缩器处理后,输出尽可能接近第一阶段找到的目标压缩结果。最后,候选扰动会被放到真实黑盒 Agent pipeline 中进行端到端验证。



实验结果:六种压缩器、三类任务下均有效

研究团队在三类任务上评估了 COMA:Agent 工具选择、问答对话以及系统提示词破坏,覆盖了六种常见提示词压缩器,包括抽取式与抽象式两种压缩方式。实验结果显示,COMA 在全部 18 个设置中均取得了最高的攻击成功率,平均 ASR 达到 0.71,而最强的非压缩感知攻击基线仅为 0.21。与此同时,无攻击设置和移除压缩器后的 COMA 设置都接近 0.01,这说明该攻击并非由普通恶意提示词导致,而是确实来自提示词压缩引入的攻击面。



COMA 也表现出较强的泛化能力。在不同压缩预算下,即使正常压缩几乎不会造成错误,攻击仍能显著放大失败率。在不同后端 LLM 家族和模型规模上,COMA 的平均 ASR 仍达到 0.69——这说明更换后端模型并不能从根本上解决问题:一旦关键上下文已经在压缩阶段被删除,后端模型往往无力回天。论文进一步分析了攻击机制,结果显示 COMA 的关键 Token 移除率与 ASR 高度一致:它并非简单添加噪声,而是在可控地引导压缩器删除少量行为关键内容。对于系统提示词破坏任务,一旦安全规则中的关键 token 被移除,拒绝条件就会直接消失。



真实案例:从 VSCode Cline 到 LangChain Agent

为验证风险是否能迁移到真实 Agent pipeline,论文构建了两个案例。第一个案例来自 VSCode Cline。正常情况下,Agent 会拒绝读取 workspace 外部的敏感文件;但加入 COMA 扰动后,压缩器削弱了系统提示词中的关键约束,后端模型最终触发了对敏感文件的读取行为。第二个案例来自 LangChain + Ollama 的 ReAct Agent。正常情况下,Agent 会为代码特征抽取任务选择正确工具;攻击后,压缩后的工具描述发生偏移,Agent 被诱导选择错误工具。这两个案例说明,提示词压缩的风险并不局限于离线 benchmark,而可能影响到真实的软件工程 Agent 和工具调用 Agent。

如何防御:隔离是关键

面对这种新型攻击,现有的防御手段——比如基于困惑度的检测——往往会大打折扣。为此,研究团队给出了一个非常务实且有效的缓解方案:隔离压缩。核心思路很简单:别把系统提示词、可信上下文和用户输入的非可信内容混在同一个预算池里压缩。系统应该将可信与非可信输入分开处理,并在重组拼接时加上明确的边界标记。实验证明,这种结构性防御在保护系统提示词方面非常有效,防御成功率能达到 96%。因为非可信内容不再与系统护栏共享压缩预算,攻击者就很难通过外部输入去“挤占”安全规则的生存空间了。

这项工作提醒了什么

这项研究揭示了 LLM Agent 部署中的一个关键问题:很多为了效率引入的系统组件,并不是简单的工程优化,而会改变模型最终看到的信息,从而改变整个 pipeline 的安全边界。因此,对于未来的 LLM Agent 系统,安全分析不能只盯着后端 LLM 本身,也需要覆盖缓存、检索、压缩、工具编排等中间层。尤其是在长上下文和 agentic workflow 越来越普遍的场景下,如何在效率与安全之间建立更可靠的系统边界,将成为可信 Agentic AI 的核心问题之一。

来源:https://www.163.com/dy/article/L1AHM0IQ0511AQHO.html

相关热点

继续查看同栏目近期热点。

延伸阅读

补充最近整理过的热点入口。