跳转至

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

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

📊 Level ⭐⭐ | 8.7KB | entities/提示词压缩竟成大模型新漏洞港科大提出黑盒攻击框架coma-ase-2026.md

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

摘要

香港科技大学的一项研究发现，大语言模型 Agent 系统中用于降低成本和延迟的提示词压缩（Prompt Compression）模块，实际上引入了一个全新的攻击面。攻击者可以通过微小的输入扰动，刻意放大压缩过程中的信息流失，导致系统的安全规则被削弱、关键上下文被删除，从而诱导后端模型执行本应拒绝的请求。该论文已被软件工程顶会 ASE 2026 接收，并提出了一个名为 COMA 的黑盒攻击框架。

核心要点

  • 新攻击面发现：提示词压缩器改变了模型最终看到的信息——压缩器决定哪些系统规则和安全约束会被保留，哪些会在预算限制下被丢弃。攻击者可以在压缩前扰动非可信输入（如用户请求或外部文档），改变压缩器的保留决策。
  • 对抗性信息损失（AIL）：研究团队提出 AIL 概念来量化攻击风险——攻击者能否通过微小扰动，故意放大压缩过程中的信息流失，把系统安全规则中的关键内容"挤掉"。
  • COMA 攻击框架：两阶段优化——先在压缩空间中寻找能诱导后端错误行为的目标压缩结果，再在压缩前输入中搜索扰动使压缩输出接近该目标。采用 Transfer-based 黑盒攻击策略。
  • 广泛有效性：在 6 种压缩器、3 类任务（Agent Tool Selection、QA、System Prompt Corruption）上，COMA 平均攻击成功率（ASR）达 0.71，而最强非压缩感知基线仅为 0.21。
  • 真实案例验证：在 VSCode Cline 和 LangChain + Ollama ReAct Agent 上验证——攻击后 Agent 读取了 workspace 外部的敏感文件，或被诱导选择了错误的工具。
  • 隔离压缩防御：将系统提示词、可信上下文与不可信内容分开压缩，并在重组时加边界标记，防御成功率达 96%。

深度分析

效率组件如何打开安全缺口

提示词压缩（Prompt Compression）原本是为解决 LLM Agent 的超长上下文问题而引入的效率优化手段。在典型的 Agent pipeline 中，系统提示词、工具说明、历史对话和检索文档共同构成了超长上下文，压缩器需要将其浓缩到预设的预算范围内。

问题的根源在于：压缩器是一个有损的信息漏斗，而攻击者可以控制"哪些信息被漏掉"。攻击者通过在用户请求后添加精心设计的扰动文本，可以引导压缩器优先丢弃安全约束中的关键 token（如否定词、"must never"等），而对恶意指令本身的影响微乎其微。这种不对称性使得看似无害的效率优化组件成为了 Agent 安全链中最薄弱的一环。

黑盒攻击的两阶段优化策略

COMA 的技术创新在于两阶段的解耦设计。第一阶段，攻击者在一组替代压缩器（surrogate compressors）上寻找目标压缩结果——即在保持扰动文本内容不被检测的同时，诱导压缩器删除特定的关键信息。第二阶段，在原始输入空间中搜索能使真实压缩器输出接近该目标的扰动。

这种设计使得 COMA 具备以下特性： 1. 黑盒可用：攻击者不需要知道目标系统的压缩器参数、压缩预算或真实的 compressed prompt 2. 跨压缩器可迁移：在 surrogate 上训练的扰动可以迁移到多种 extractive 和 abstractive 压缩器上 3. 跨模型可迁移：攻击成功后，即使更换后端 LLM 也无法恢复安全状态——因为关键上下文已经在压缩阶段被删除

安全边界从 LLM 前移到中间件

这项研究揭示了一个更深刻的趋势：LLM Agent 的安全边界正在从前端模型扩展到整个 pipeline 中间件层。传统思路认为安全防护只需要关注 LLM 本身（prompt injection、jailbreak），但 COMA 证明缓存、检索、压缩、工具编排等组件同样可以被武器化。

对于实际部署的 LLM Agent 系统，这意味着：

  • 安全审计不能止于模型层面，需要覆盖所有中间件
  • 组件间的边界和信任假设需要显式定义
  • "提效"功能组件需要重新评估其安全影响

隔离压缩的结构性防御价值

研究团队提出的"隔离压缩"方案之所以有效（96% 防御成功率），关键在于它从结构性上切断了攻击路径。当系统提示词与不可信输入被分配不同的压缩预算池时，攻击者就无法通过外部输入去"挤占"安全规则的生存空间。

这种结构性防御的思路值得推广到其他中间件组件——与其依赖检测攻击内容的边缘防御，不如从架构层面将可信与不可信数据流分离。

实践启示

  1. 对使用 Prompt Compression 的系统进行安全审计：如果你的 LLM Agent 系统使用了任何形式的提示词压缩，应评估其安全影响。特别是系统提示词中包含安全约束的场景（如拒绝执行 shell 命令、禁止读取敏感文件）。

  2. 采用隔离压缩架构：将系统提示词、可信上下文与用户输入/外部文档分开压缩，确保安全规则不会被不可信内容"挤占"预算。这是最有效的缓解措施。

  3. 监控压缩后的信息损失：在 Agent 系统中添加日志记录——对比压缩前后的关键安全 token 保留率，可以作为攻击检测的早期信号。

  4. 关注中间件安全：在进行 Agent 系统的威胁建模时，不要仅关注 LLM 本身的安全，应将所有中间件组件（压缩、缓存、检索、工具编排）纳入安全审计范围。

  5. 优先使用不改变语义的压缩方法：如果必须使用压缩，优先考虑 extractive（抽取式）而非 abstractive（生成式）压缩方法，因为前者在保留关键安全约束方面更可控。

相关实体

→ 原文存档 → 机器之心补充报道