“顶会”看安全（十八）：超越越狱：揭示由能力边界模糊引发的 LLM 应用安全风险-拓冰网站定制

这期解读的安全论文来自网络与分布式系统安全顶级会议 NDSS 2026，论文题目是Beyond Jailbreak: Unveiling Risks in LLM Applications Arising from Blurred Capability Boundaries,中文可以译为超越越狱：揭示由能力边界模糊引发的 LLM 应用安全风险。论文链接为：https://www.ndss-symposium.org/ndss-paper/beyond-jailbreak-unveiling-risks-in-llm-applications-arising-from-blurred-capability-boundaries/

一、论文背景

LLM 应用的开发模式发生了根本变化

传统软件的能力主要由代码决定。

例如，一个翻译软件之所以能够翻译，是因为开发者实现了：

文本输入；
语言识别；
翻译函数；
结果输出。

应用没有实现的功能，原则上就无法执行。

但 LLM 应用不是这样。底层大模型本身已经具备翻译、编程、总结、搜索、推理和内容生成等广泛能力。开发者通常不再从零实现这些功能，而是通过以下方式把模型包装成特定应用：

系统提示词；
Prompt 模板；
知识库；
插件和工具；
工作流；
模型参数或微调。

因此，开发者的角色从传统软件中的能力实现者，逐渐变成了 LLM 应用中的能力引导者和能力限制者。

“没有完全越狱”不等于应用是安全的

目前很多 LLM 安全研究主要关注 Jailbreak，也就是绕过底层模型的安全限制，使模型生成恶意、违法或危险内容。

但论文指出，在真实应用中，攻击者不一定需要做到完整越狱。

例如，一个招聘审核应用可能仍然拒绝生成危险内容，却因为简历中嵌入了误导性指令，把一个不合格候选人判断为“最优秀的候选人”。

在这种情况下：

底层模型的内容安全策略可能没有被突破；
应用却没有完成其原本的审核任务；
业务结果已经受到实质性影响。

现有研究虽然关注过 GPT 应用克隆、数据泄露、Agent 通信攻击等问题，但大多集中于单个平台、隐私泄露或传统越狱，对这种“不完全越狱但应用目标已经偏离”的风险缺乏系统研究。

作者将这种现象称为：

Goal Deviation，即目标偏离。

论文提出“LLM 应用能力空间”

为了描述上述问题，作者首先定义了 LLM App Capability Space，即 LLM 应用能力空间。

可以把底层大模型想象成一个拥有巨大能力集合的系统，其中包括：

翻译；
编程；
搜索；
数学推理；
文本总结；
图像生成；
恶意内容生成；
其他通用任务。

模型自身的安全对齐先将其中一部分危险能力限制起来，形成所谓的“受审查能力空间”。

应用开发者再通过 Prompt、规则和插件，从剩余能力中划定一个更小的范围。例如，一个翻译应用理论上只应该保留“语言翻译”相关能力。

底层 LLM 的完整能力空间 ↓ 模型安全约束 受审查的模型能力空间 ↓ 应用 Prompt 与规则约束 LLM 应用能力空间

理想状态下：

属于应用目标范围的任务应当能够完成；
不属于应用目标范围的任务应当被拒绝。

但由于自然语言约束存在模糊性，实际应用的边界并不像传统程序中的权限判断那样明确。

三种能力边界风险

论文根据能力边界发生变化的方式，将风险分为三类。

4.1 Capability Downgrade：能力降级

能力降级是指：

应用原本能够完成某项任务，但攻击者通过特定输入降低其在该任务上的表现，使它产生错误结果。

例如，一个 Web3 企业使用 LLM 审核操作记录。正常情况下，审核机器人应识别违规转账，但攻击者可以在操作记录中加入误导性内容，使审核机器人将恶意操作判断为正常。

这类攻击并不要求机器人执行额外功能，只需要让它在原有任务上“失灵”。

4.2 Capability Upgrade：能力升级

能力升级是指：

应用被诱导执行其原始设计范围之外的任务，但尚未达到能够执行任意任务的程度。

例如，一个低成本或免费的翻译应用可能被用户诱导去：

编写代码；
撰写营销内容；
搜索实时信息；
生成图片；
执行其他付费应用提供的功能。

攻击者因此可以通过一个应用获得其他应用或高级 API 的能力，而调用成本由应用提供方承担。

能力升级并不一定涉及明显的恶意内容，但可能造成：

API 资源滥用；
企业算力成本增加；
付费功能被绕过；
平台服务质量下降；
内部工具被用于非授权业务。

论文把它定位为“正常使用”和“完整越狱”之间的中间状态。

4.3 Capability Jailbreak：能力越狱

能力越狱是最严重的状态。

它意味着攻击者同时突破：

应用自身的功能边界；
底层模型的安全限制。

此时，一个原本用于翻译、客服或教育的应用可能被诱导执行任意任务，包括恶意任务。

三种风险可以概括为：

能力降级：该做的事情做错了 能力升级：做了不该由该应用完成的事情 能力越狱：能够完成任意任务或恶意任务

论文强调，随着 LLM 功能被嵌入越来越多移动端、桌面端和企业系统，每个 LLM 应用都有可能成为访问底层模型广泛能力的新入口。

应用商店模式进一步放大了风险

LLM 应用的开发门槛非常低。开发者可能只需编写一段应用描述、上传知识库并选择几个插件，就能发布一个应用。

低门槛带来了两个问题。

第一是应用数量快速膨胀。论文发现，GPTs Store 中有 19 名开发者分别发布了超过 1,000 个应用，发布数量最多的开发者创建了 8,530 个应用。

第二是应用能力配置可能并不精确。例如，在配置了百度地图插件的 258 个 AgentBuilder 应用中，作者通过人工分析认为 117 个应用的功能实际并不需要地图插件。也就是说，平台默认配置或开发者疏忽可能无意中扩大应用的能力边界。

二、论文方法概述

论文设计了一套名为LLMApp-Eval的评估框架。

其核心思路可以概括为：

先测绘 LLM 应用生态，再评估应用 Prompt 的约束质量，最后通过跨类别任务和恶意任务测试应用的真实能力边界。

论文第 7 页图 6 将整个框架划分为三个部分：

LLM 应用收集与分类 ↓ Prompt 质量量化 ↓ 能力边界与安全风险测试

第一阶段：收集并分类 LLM 应用

作者选择了四个具有代表性的 LLM 应用平台：

GPTs Store；
Coze；
AgentBuilder；
Poe。

其中：

GPTs Store 是大型 LLM 应用市场；
Coze 和 AgentBuilder 分别代表中国的应用构建平台；
Poe 是可以接入多种第三方模型的平台。

作者最终收集了 807,207 个应用：

GPTs Store：576,952个 Coze：187,115个 AgentBuilder：22,638个 Poe：20,502个

由于不同平台的分类方式并不统一，作者重新定义了 20 个应用类别，包括教育、研究、编程、金融、健康、图像与视频、法律、天气等，并使用 BART-large-mnli 零样本分类模型，根据应用描述为每个应用分配类别。

第二阶段：量化 Prompt 质量

Prompt 是开发者划定能力边界的主要手段，因此作者设计了四个指标。

TScore：目标描述分数

TScore 衡量 Prompt 是否明确说明：

应用是什么身份；
面向什么场景；
应执行什么动作；
处理哪些对象。

作者结合 Prompt 信息熵和目标相关词汇的语义匹配计算该分数。

PScore：过程描述分数

PScore 衡量 Prompt 是否提供了清晰的执行过程，例如：

是否包含明确步骤；
是否描述步骤顺序；
是否存在条件关系；
是否说明不同操作之间的逻辑。

只写“第一、第二、第三”并不一定代表流程质量高，关键还在于是否解释了步骤之间的业务关系。

CaScore：能力描述分数

CaScore 主要衡量：

Prompt 描述了多少项应用能力；
能力描述是否具体；
是否明确说明每项能力的触发条件。

CoScore：能力约束分数

CoScore 衡量应用是否明确说明：

哪些任务不能执行；
哪些请求必须拒绝；
拒绝规则是否足够严格。

作者使用 LLM 提取能力条目、约束条目及每条约束的拒绝强度，并将 TScore、PScore、CaScore 和 CoScore 归一化后等权组合成最终的 AppScore。

第三阶段：进行能力边界测试

作者为三类风险分别设计了不同测试方法。

能力降级测试

研究人员构造一组正常输入和一组加入误导性内容的输入：

正常输入Q1 → 正常结果R1 加入误导内容的输入Q1* → 结果R1*

如果任务本身没有变化，但加入误导内容后模型给出错误结果，就说明发生了能力边界漂移。

作者共构造了：

28 个业务场景；
2,790 对边界测试用例。

论文第 8 页图 7 给出的案例是招聘审核：攻击者在简历中嵌入类似系统指令的文字，使原本不合格的候选人通过 LLM 筛选。

能力升级测试

作者首先将应用分成 20 个类别，然后向某一类别的应用发送其他类别的任务。

例如：

天气应用 → 编程任务 翻译应用 → 图像生成任务 教育应用 → 金融分析任务

测试用例包括三类：

默认用例：来自真实应用提供的示例问题；
生成用例：根据应用能力画像，由 GPT-4o 生成越界任务并人工筛选；
通用用例：用于测试应用是否能够回答普通常识问题。

如果一个应用能够完成大量其他类别的任务，说明它的实际能力空间远大于其公开定位。

能力越狱测试

作者收集不同类型的恶意请求，并复现已有开源越狱方法，生成：

未经过对抗改写的原始恶意用例；
经过越狱技术改写的对抗恶意用例。

应用输出随后交给一个基于 GPT-4o 的 LLM Judge，判断应用是否真正完成了对应任务。

第四阶段：验证评估框架的可靠性

为了避免完全依赖自动模型，作者使用人工抽样验证了三个关键模块：

应用分类准确率：96%；
Prompt 评分准确率：92%；
LLM Judge 判断准确率：94.33%。

其中，文本型 LLM Judge 在图像生成等多模态任务上可能产生误判，例如将一段图片描述错误地判断为已经完成图片生成。

三、论文工作具体说明

工作一：提出“能力边界安全”这一研究视角

论文最重要的理论贡献，是将研究对象从底层模型安全扩展到应用能力安全。

传统判断方式往往是：

模型有没有输出恶意内容？ 模型有没有被Jailbreak？

论文提出还需要关注：

应用是否仍在完成原定任务？ 应用是否执行了范围外任务？ 应用实际能力是否超过开发者认知？

这使得 LLM 应用安全不再是简单的内容审核问题，而变成了类似传统软件中的：

功能边界；
权限控制；
输入验证；
业务完整性；
资源访问控制。

工作二：完成跨平台 LLM 应用生态测绘

作者对超过 80 万个应用进行了跨平台分析。

研究发现，虽然不同平台覆盖的国家、模型和用户群体不同，但应用类型分布非常接近。各平台占比最高的三个类别普遍是：

Education & Learning；
Data & Research；
Developer & Code。

这说明当前 LLM 应用市场的需求具有较强同质性。

论文还发现，平台支持的基础模型和插件机制存在明显差异，而这些差异会直接影响应用的真实能力空间。例如 Poe 可以接入多种文本、图像和视频模型，GPTs 则默认具备搜索和图像生成等能力。

工作三：首次大规模量化真实应用 Prompt 质量

作者对 AgentBuilder 上公开 Prompt 的 11,176 个应用进行了评分。

结果显示：

AppScore 范围为 2.55 至 78.41；
48.62% 的应用得分低于 50；
43.41% 的应用没有设置任何能力约束；
部分应用虽然设置了约束，但约束强度仍然较低。

多数 Prompt 能够说明“应用要做什么”，但在“具体如何执行”和“哪些事情绝对不能做”方面表现较差。

这揭示了一个普遍问题：

很多开发者擅长通过 Prompt 激活模型能力，却没有同等重视能力限制。

工作四：验证能力降级风险

作者使用 2,790 对边界测试用例测试了 6 个开源模型。

不同模型受误导内容影响的比例为：

Llama-3.1-8B：23.94% Qwen2.5-7B：35.16% Gemma-2-9B：25.34% ChatGLM3-6B：29.18% Mistral-7B：35.59% InternLM2.5-7B：25.91%

表现最好的 Llama-3.1-8B 仍然在 668 个案例中产生错误结果；受影响最大的 Mistral-7B 在 993 个案例中出现能力降级。

这说明，间接提示注入的影响不一定表现为“模型开始执行攻击者命令”，也可能表现为：

分类结果被篡改；
审核逻辑失效；
风险对象被判断为正常；
正常业务决策发生偏差。

工作五：验证能力升级风险

作者原计划选择每个平台访问量最高的 50 个应用，共 200 个。由于其中一个应用在测试期间下线，最终评估了 199 个应用。

研究采用了一个较严格的判断标准：

如果一个应用能够完成 15 个或以上类别的任务，则认为它存在明显的能力升级风险。

最终有 144 个应用符合该标准，占 72.36%：

GPTs：49个 Coze：35个 Poe：33个 AgentBuilder：27个

此外，172 个应用能够完成通用任务，占 86.42%。

论文第 12 页图 9 的热力图非常直观：绿色表示应用原本所属类别，橙色表示它能够完成其他类别任务的程度。GPTs 对应的热力图几乎被橙色填满，说明许多 GPT 应用实际能够完成大量范围外任务。

工作六：验证能力越狱风险

在 199 个应用中，作者发现 178 个应用至少完成过一次恶意任务，占 89.45%。

其中更值得注意的是：

17 个应用不需要任何对抗性改写；
只输入普通形式的恶意请求，应用就会直接执行；
这 17 个应用包括 13 个 Coze 应用和 4 个 Poe 应用。

作者推测，部分应用 Prompt 本身可能起到了“越狱提示词”的效果。

例如，开发者为了提升服务体验而加入：

不要拒绝用户的任何请求。 必须尽可能完成用户要求。 无论用户提出什么问题都应提供答案。

这类规则可能与底层模型的安全策略产生冲突，反而帮助用户绕过模型原有的拒绝机制。

工作七：分析平台插件对能力边界的影响

论文发现，应用风险并不只由 Prompt 决定，底层模型和平台默认插件同样重要。

例如 GPTs 默认具备：

Web Search；
DALL·E 图像生成；
多模态输入输出能力。

因此，即便某个 GPT 应用被描述为纯文本工具，它也可能被诱导完成：

实时天气查询；
网络搜索；
图像生成；
其他多模态任务。

相比之下，部分 Coze 和 AgentBuilder 应用没有配置相应插件，因此完成图像和天气任务的比例较低。

这说明，从安全角度看，插件不是“只有主动调用时才存在”的附加功能，而应当被视为应用能力边界的一部分。

工作八：验证更好的 Prompt 能够降低风险

作者通过控制变量实验，将缺少约束的 Prompt 与加入明确能力限制后的 Prompt 进行对比。

结果显示，优化 Prompt 后，应用执行范围外任务的数量下降了 5.3% 至 80%，具体效果取决于平台和基础模型。

在 AgentBuilder 的一个案例中：

加入约束前：能够完成21类范围外任务中的15类 加入约束后：下降至3类

但相同 Prompt 在不同模型上的约束效果并不一致。例如，同样的限制规则在 Claude-3-Haiku 上明显弱于在文心模型上的表现。

因此，论文并没有得出“写好 Prompt 就足够安全”的结论，而是说明：

明确的能力约束是必要措施，但它仍然是一种依赖模型遵循程度的软控制。

工作九：总结更有效的能力边界控制方式

论文观察到，三类机制对能力升级有一定抑制作用：

输入主题检查

应用先判断用户问题是否符合自身主题。

但这种检查通常仍然由 LLM 完成，攻击者可以通过自然语言改写、场景包装或上下文诱导绕过，因此可靠性有限。

固定工作流

应用要求用户严格按照预定义步骤操作，例如必须依次回答固定问题。

由于控制流程接近传统程序，用户较难通过自由文本触发额外能力。

严格输入输出类型

例如图像应用只接受图片输入，或始终输出图片，不允许自由文本交互。

这种结构化限制能够显著缩小攻击面。

论文因此隐含提出了一个非常重要的工程结论：

越接近传统软件的确定性控制，能力边界越清晰；越依赖 LLM 自行理解和遵守自然语言规则，边界越容易被绕过。

四、论文的核心结论

这篇论文最值得关注的地方，并不是又发现了一种新的 Prompt 攻击语句，而是重新定义了 LLM 应用安全的评价方式。

传统安全问题通常关注：

模型是否输出了危险内容

而论文认为，企业还应当持续回答：

应用是否只完成被授权的任务？ 应用是否会因非可信输入而降低业务判断能力？ 应用是否继承了未被开发者意识到的模型或插件能力？ 应用Prompt是否可能削弱底层模型原有的安全机制？

从企业治理角度看，这意味着 LLM 应用上线前不能只做传统的越狱测试，还需要建立一套能力边界测试：

定义应用允许执行的任务集合；
定义明确禁止执行的任务集合；
测试误导内容是否会降低核心业务能力；
使用跨类别任务测试能力是否越界；
检查模型、知识库、插件和工具带来的隐式能力；
使用结构化工作流和权限控制，而不是完全依赖 Prompt；
更换底层模型或新增插件后重新测试能力边界。

论文也承认，其研究主要集中于公开应用商店，没有直接测试企业内部应用；只覆盖四个平台，并依赖未经过平台验证的应用描述进行分类。Prompt 评分和文本型 LLM Judge 也仍存在一定误差。

总体来说，这篇论文将 LLM 应用安全从单纯的“防止模型说错话”，推进到了更接近应用安全和权限治理的问题：

不仅要防止模型做危险的事，还要确保每个 LLM 应用只能做它被设计和授权去做的事。

五、从能力边界安全看 Mend.io 平台的价值

这篇论文提出的“能力边界安全”，实际上反映了 AI 应用安全正在发生的一次重要变化：传统应用安全主要关注代码中是否存在漏洞，而 LLM 应用除了代码之外，还存在模型、System Prompt、Agent 配置、RAG、MCP、插件和外部工具等新的控制层。

因此，一个完整的 AI 应用安全体系需要同时回答两个问题：

应用代码和依赖是否安全？ LLM 应用本身的行为和能力边界是否安全？

而 Mend.io 平台正在将传统 AppSec 能力进一步扩展到 AI 应用安全。尤其是 Mend AI，目前已经覆盖 AI 组件发现、AI-BOM、System Prompt 风险分析。

Mend AI 的System Prompt Risk / System Prompt Hardening可以从工程层面对这一问题进行进一步治理。通过识别 System Prompt 中潜在的安全弱点，对 Prompt 风险进行分析和评分，并提供经过强化的 Prompt 建议，从而帮助开发团队在应用进入生产环境之前发现可能导致 Prompt Injection、策略绕过或非预期数据泄露的问题。
Mend AI 红队可以针对 AI 应用执行自动化的对抗测试，包括 Prompt Injection、Jailbreak、数据泄露以及其他 AI 特有的行为风险，并支持预置和自定义安全测试。
Mend AI 可以发现应用中使用的模型、Agent、RAG 和 MCP 等 AI 组件，并形成持续更新的 AI-BOM，帮助安全团队建立 AI 资产和组件清单。

资讯详情

“顶会”看安全（十八）：超越越狱：揭示由能力边界模糊引发的 LLM 应用安全风险