这期解读的安全论文来自网络与分布式系统安全顶级会议 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 StoreCozeAgentBuilderPoe。其中GPTs Store 是大型 LLM 应用市场Coze 和 AgentBuilder 分别代表中国的应用构建平台Poe 是可以接入多种第三方模型的平台。作者最终收集了 807,207 个应用GPTs Store576,952个 Coze187,115个 AgentBuilder22,638个 Poe20,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 LearningData ResearchDeveloper Code。这说明当前 LLM 应用市场的需求具有较强同质性。论文还发现平台支持的基础模型和插件机制存在明显差异而这些差异会直接影响应用的真实能力空间。例如 Poe 可以接入多种文本、图像和视频模型GPTs 则默认具备搜索和图像生成等能力。工作三首次大规模量化真实应用 Prompt 质量作者对 AgentBuilder 上公开 Prompt 的 11,176 个应用进行了评分。结果显示AppScore 范围为 2.55 至 78.4148.62% 的应用得分低于 5043.41% 的应用没有设置任何能力约束部分应用虽然设置了约束但约束强度仍然较低。多数 Prompt 能够说明“应用要做什么”但在“具体如何执行”和“哪些事情绝对不能做”方面表现较差。这揭示了一个普遍问题很多开发者擅长通过 Prompt 激活模型能力却没有同等重视能力限制。工作四验证能力降级风险作者使用 2,790 对边界测试用例测试了 6 个开源模型。不同模型受误导内容影响的比例为Llama-3.1-8B23.94% Qwen2.5-7B35.16% Gemma-2-9B25.34% ChatGLM3-6B29.18% Mistral-7B35.59% InternLM2.5-7B25.91%表现最好的 Llama-3.1-8B 仍然在 668 个案例中产生错误结果受影响最大的 Mistral-7B 在 993 个案例中出现能力降级。这说明间接提示注入的影响不一定表现为“模型开始执行攻击者命令”也可能表现为分类结果被篡改审核逻辑失效风险对象被判断为正常正常业务决策发生偏差。工作五验证能力升级风险作者原计划选择每个平台访问量最高的 50 个应用共 200 个。由于其中一个应用在测试期间下线最终评估了 199 个应用。研究采用了一个较严格的判断标准如果一个应用能够完成 15 个或以上类别的任务则认为它存在明显的能力升级风险。最终有 144 个应用符合该标准占 72.36%GPTs49个 Coze35个 Poe33个 AgentBuilder27个此外172 个应用能够完成通用任务占 86.42%。论文第 12 页图 9 的热力图非常直观绿色表示应用原本所属类别橙色表示它能够完成其他类别任务的程度。GPTs 对应的热力图几乎被橙色填满说明许多 GPT 应用实际能够完成大量范围外任务。工作六验证能力越狱风险在 199 个应用中作者发现 178 个应用至少完成过一次恶意任务占 89.45%。其中更值得注意的是17 个应用不需要任何对抗性改写只输入普通形式的恶意请求应用就会直接执行这 17 个应用包括 13 个 Coze 应用和 4 个 Poe 应用。作者推测部分应用 Prompt 本身可能起到了“越狱提示词”的效果。例如开发者为了提升服务体验而加入不要拒绝用户的任何请求。 必须尽可能完成用户要求。 无论用户提出什么问题都应提供答案。这类规则可能与底层模型的安全策略产生冲突反而帮助用户绕过模型原有的拒绝机制。工作七分析平台插件对能力边界的影响论文发现应用风险并不只由 Prompt 决定底层模型和平台默认插件同样重要。例如 GPTs 默认具备Web SearchDALL·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 资产和组件清单。
