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

这项研究成果已被软件工程领域顶会 ASE 2026 接收。论文第一作者为港科大 CSE 博士生刘泽森，通讯作者为佘东冬教授。

在大语言模型 Agent 走向真实部署后，一个越来越常见的问题是：上下文太长了。

现在的 AI Agent 动辄需要处理超长上下文，既要看系统提示词、工具说明，又要翻阅历史对话和检索文档。为了省钱、省算力并降低延迟，很多开发者会给系统加上 “提示词压缩”（Prompt Compression）模块，把冗长的上下文浓缩后再喂给大模型。

但这招真的安全吗？

香港科技大学的一项最新研究给出了否定答案。他们发现，这个原本用来 “提效” 的组件，竟然会悄悄重写系统的安全边界，成为大模型应用中的全新攻击面。

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

研究背景：压缩不只是省 token，而是在重写安全边界

传统针对 LLM Agent 的攻击，如 prompt injection、jailbreak 或 RAG poisoning，通常默认一个前提：攻击内容必须进入后端 LLM 的有效上下文，并被模型当作恶意指令执行。

但在 prompt-compressed pipeline 中，情况发生了变化。

后端 LLM 看到的并不是原始 prompt，而是经过压缩器处理后的 compressed prompt。换言之，压缩器决定哪些系统规则、任务证据和上下文信息会被保留，哪些会在预算限制下被丢弃。

这带来一个新的安全问题：攻击者不一定需要让恶意指令穿过压缩器，也不一定需要让攻击 payload 在压缩后仍然可读。攻击者只需要在压缩前扰动非可信输入，例如用户请求或外部文档，就可能改变压缩器的保留决策，使关键安全规则或任务证据在后端推理前被删除。

一个直观的例子是：系统提示词中包含「must never use shell」这样的安全约束。攻击者无法直接修改系统提示词，但可以在用户请求后添加一段短扰动。压缩后，安全约束中的关键否定词可能被丢失，后端 LLM 最终看到的是一个被削弱的规则，从而执行本应拒绝的请求。

核心概念：Adversarial Information Loss

为了量化这种风险，研究团队提出了 “对抗性信息损失”（AIL）的概念。简单来说，就是看攻击者能不能通过微小的扰动，故意放大压缩过程中的信息流失，把不该丢的关键内容挤掉。它不是简单地问压缩质量好不好，而是问：在攻击者存在时，压缩后的 prompt 是否会诱导后端 Agent 做出与正常压缩明显不同、且安全相关的错误行为。

技术核心：COMA 如何攻击黑盒压缩 Agent？

在真实系统中，攻击者通常不知道压缩器参数、压缩预算，也看不到真实 compressed prompt。因此，论文提出了一个 transfer-based black-box attack 框架：COMA。

COMA 的核心思想是两阶段优化。

第一阶段，COMA 在压缩空间中寻找一个会诱导后端错误行为的目标 compressed prompt。例如，它会定位哪些关键 token 或关键证据一旦被删除，就会导致工具选择错误、问答错误，或系统安全规则失效。

第二阶段，COMA 在压缩前输入中搜索一个扰动，使得经过 surrogate compressor 压缩后，输出尽可能接近第一阶段找到的目标压缩结果。最后，候选扰动会被放到真实黑盒 Agent pipeline 中进行端到端验证。

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

研究团队在三类任务上评估了 COMA：Agent Tool Selection、Question Answering 和 System Prompt Corruption，覆盖六种常见 prompt compressors，包括 extractive 与 abstractive 两类压缩方式。

实验结果显示，COMA 在全部 18 个设置中都取得最高攻击成功率，平均 ASR 达到 0.71，而最强的非压缩感知攻击 baseline 仅为 0.21。与此同时，无攻击设置和移除压缩器后的 COMA 设置都接近 0.01，说明该攻击并不是普通恶意提示词导致的，而是确实来自 prompt compression 引入的攻击面。

COMA 也表现出较强泛化性。在不同压缩预算下，即使正常压缩几乎不会造成错误，攻击仍能显著放大失败率。在不同后端 LLM 家族和模型规模上，COMA 的平均 ASR 仍达到 0.69，说明后端模型更换并不能根本解决问题：一旦关键上下文已经在压缩阶段被删除，后端模型往往无法恢复。

论文进一步分析了攻击机制。结果显示，COMA 的 Critical Token Removal Rate 与 ASR 高度一致：它并不是简单添加噪声，而是在可控地引导压缩器删除少量行为关键内容。对于系统提示词破坏任务，一旦安全规则中的关键 token 被移除，拒绝条件就会直接消失。

真实案例：从 VSCode Cline 到 LangChain Agent

为了验证风险是否能迁移到真实 Agent pipeline，论文构建了两个案例。

第一个案例来自 VSCode Cline。正常情况下，Agent 会拒绝读取 workspace 外部的敏感文件；但加入 COMA 扰动后，压缩器削弱了系统提示词中的关键约束，后端模型最终触发了对敏感文件的读取行为。

第二个案例来自 LangChain + Ollama 的 ReAct Agent。正常情况下，Agent 会为代码特征抽取任务选择正确工具；攻击后，压缩后的工具描述发生偏移，Agent 被诱导选择错误工具。

这两个案例说明，prompt compression 的风险并不局限于离线 benchmark，而可能影响真实软件工程 Agent 和工具调用 Agent。

如何防御：隔离是关键

面对这种新型攻击，现有的防御手段（如基于困惑度的检测）往往会大打折扣。为此，研究团队给出了一个非常务实且有效的缓解方案：隔离压缩（Isolated Compression）。

核心思路很简单：别把系统提示词、可信上下文和用户输入的不可信内容混在同一个预算池里压缩。系统应该将可信与非可信输入分开处理，并在重组拼接时加上明确的边界标记。实验证明，这种结构性防御在保护系统提示词方面非常有效，防御成功率能达到 96%。因为非可信内容不再与系统护栏共享压缩预算，攻击者就很难通过外部输入去 “挤占” 安全规则的生存空间了。

这项工作提醒了什么

这项研究揭示了 LLM Agent 部署中的一个关键问题：很多为了效率引入的系统组件，并不是简单的工程优化，而会改变模型最终看到的信息，从而改变整个 pipeline 的安全边界。

因此，对于未来的 LLM Agent 系统，安全分析不能只盯着后端 LLM 本身，也需要覆盖缓存、检索、压缩、工具编排等中间层。尤其是在长上下文和 agentic workflow 越来越普遍的场景下，如何在效率与安全之间建立更可靠的系统边界，将成为 Trustworthy Agentic AI 的核心问题之一。