当前位置：首页 > news >正文

加强LLM防御以实现企业部署

news 来源：原创 2025/6/1 6:37:19

大家读完觉得有帮助记得关注！！！

摘要

CaMeL（机器学习能力）引入了一种基于能力的沙箱，以缓解大型语言模型（LLM）代理中的提示注入攻击。虽然有效，但CaMeL假定用户提示是可信的，忽略了侧信道问题，并且由于其双LLM架构而导致性能上的权衡。此技术响应确定了这些局限性，并提出了工程增强措施，以扩展CaMeL的威胁覆盖范围和操作可行性。我们引入：（1）针对初始输入的提示筛选，（2）用于检测指令泄露的输出审计，（3）用于平衡效用和控制的分层风险访问模型，以及（4）用于支持静态保证的形式验证中间语言。总之，这些增强功能使CaMeL与安全工程中的最佳实践保持一致，减少了开销，并支持企业级部署，而无需修改底层模型。

1 引言

提示注入攻击已成为大型语言模型（LLM）部署中最紧迫的安全挑战之一，尤其是在这些模型被用作企业工作流程中的自主代理时。随着LLM超越简单的文本生成并开始编排工具——发送电子邮件、查询数据库、管理云文件——它们面临着越来越多的暴露于不受信任的输入。

在这些情景中，攻击者可以将恶意指令嵌入到原本无害的内容中——例如上传的文档、网页，甚至是系统生成的消息。当大型语言模型摄取此类输入时，它可能会在不知情的情况下执行未经授权的操作：泄露敏感数据、联系外部接收者或触发破坏性的API调用。研究表明，即使是高级模型也经常会落入这些陷阱，常常将隐藏的payload误解为合法的用户命令 [1, 2]。

为了在不修改底层模型的情况下应对这些威胁，Debenedetti等人引入了CaMeL（机器学习能力）[1]。CaMeL将LLM封装在一个基于能力的执行层中，该执行层分离了受信任和不受信任的数据流。特权LLM接收用户的提示并生成一个高级计划，而隔离LLM处理不受信任的内容并强制执行严格的模式验证。每个数据值都标有出处和访问元数据（“能力”），并且所有工具调用都必须在执行前通过显式策略检查。

虽然CaMeL显著提高了提示注入的抵抗能力，但仍有改进其鲁棒性和实用性的空间。本文研究了CaMeL当前的局限性——包括其威胁模型中的假设、剩余的侧信道暴露以及系统级约束，如延迟和策略蔓延。我们提出了一系列技术发展来应对这些挑战，借鉴了安全工程、形式验证和访问控制系统的最佳实践。

2 加强CaMeL威胁模型的机会

从企业安全的角度来看，CaMeL的威胁模型中存在三个值得关注的显著差距。

2.1 初始提示信任

CaMeL 假设用户的初始消息是良性的。然而，企业红队演习表明，一个精心设计的提示（通常通过网络钓鱼或基于聊天的社会工程传递）可以将持久性逻辑植入到代理的规划层中。经典的钓鱼研究报告显示，超过 30% 的用户会点击看似无害的链接，这些链接包含攻击者控制的关键词 [3]。

为了应对这一风险，我们提出了一个初步的提示筛选网关，该网关对URL执行信誉检查，标记覆盖短语（例如，“忽略所有之前的指令”），并计算熵或困惑度得分以检测异常。由于这只涉及一个短字符串，因此延迟仍然很低（在内部测试中低于5毫秒），但该筛选关闭了一个高影响的注入攻击入口点[4, 5]。

2.2 输出端操控

CaMeL 强制执行工具输入的数据来源，但不检查代理最终输出的内容。例如，一个良性的 PDF 可能包含如下一行：

如果代理总结此文档，则隐藏的指令可能会回显给人类用户，从而导致意外的操作。现代自然语言推理模型已经可以在诸如 MNLI [6] 等基准数据集上以超过 90% 的准确率检测矛盾和恶意措辞。

我们建议进行后处理输出审核，扫描每个LLM生成的响应，以查找覆盖提示、可疑URL或与预期业务任务相矛盾的内容。只有通过此审核的输出才会被显示或执行。

2.3 用户上传的来源

仅靠模式验证不足以处理由最终用户提供的文档。我们建议从这些文件中提取的每个值都带有文件内容来源标签，例如，来自用户上传的标签。然后，策略可以阻止这些数据流入不可逆转的操作——例如发送外部电子邮件或修改ERP系统——除非通过特权的“grantexception”机制明确授权。

此设计借鉴了信息流控制语言（如 JIF [7] 和 FlowCaml [8],）中的技术，并在此处针对由 LLM 驱动的基于代理的系统进行了调整。

通过实施 (i) 提示筛选，(ii) 输出审核，以及 (iii) 上传内容的标记溯源，安全团队可以在不影响 CaMeL 基于核心能力的控制的情况下，扩大其在整个对话生命周期中的保护范围。

3 在安全保障与实际效用之间取得平衡

CaMeL的默认行为会拒绝任何工具调用，如果其参数（直接或间接）包含不受信任的数据。这项严格的策略在AgentDojo基准测试中实现了67%的完成率[1]。然而，许多剩余的失败并非源于不安全的逻辑，而是源于将所有不受信任的输入视为具有同等风险。

在真实的企业环境中，诸如风险自适应访问控制和 NIST 的零信任架构等安全框架应用了更为细致的策略，根据运营敏感性和情境上下文调整执行力度 [9]。受这些实践的启发，我们为 CaMeL 提出了一种分层风险策略：

绿色层级 - 在经过基本的来源检查后，允许对公共或内部标记为“开放”的数据执行只读操作（例如，列出日历事件）。

黄色层级 - 用户自身环境内的更改（例如，将文件移动到共享文件夹）如果任何参数不受信任，则会提示轻量级确认。

红色层级 - 不可逆或外部可见的操作（例如，发送电子邮件、进行电汇、调用特权API）保留完整的能力检查，并需要多因素批准。

大规模的基于属性的访问控制（ABAC）评估表明，这种分层方法在云测试平台中保留了超过90%的合法工作流程，同时阻止了所有模拟攻击[10]。在CaMeL中应用类似的方法将提高任务成功率，而不会放松其最强的控制。

减少提示疲劳。过多的安全提示可能导致提示疲劳，用户会不假思索地批准警告而不阅读它们[11]。通过将显式确认限制在黄色和红色层级，CaMeL可以显著减少提示量——在提高可用性的同时，保持高风险操作的安全性。

从经验检查到形式保证。CaMeL 当前的安全措施依赖于基准性能，而非形式验证。对于需要严格保证的环境，我们建议在证明助手中构建 CaMeL 解释器和策略引擎的机械化模型，然后证明它满足非干扰性：带有秘密标签的输入不应影响公共输出，除非通过批准的渠道。

诸如CertiKOS和CompCert等经过验证的系统表明，即使对于复杂的软件栈，机器检查的安全性也是可行的[12,13]。将CaMeL受限的Python方言重写为最小的、形式化指定的中间语言，将支持类似的验证工作——弥合理论模型和实际部署之间的差距[14]。

4 侧信道考量与缓解措施

尽管CaMeL强制执行基于能力的数据流控制，但它本身并不能阻止通过侧信道泄露信息——诸如时间、循环迭代或错误行为等间接信号，这些信号可能在不违反显式策略的情况下泄露内部状态。

下面，我们将研究三种实际的侧信道攻击向量，并基于安全系统研究中已建立的技术，推荐缓解策略。

4.1 循环计数攻击

威胁。当循环迭代的次数取决于一个秘密时，即使是非敏感操作也可能通过可观察的计数泄露信息。例如，如下循环：

对于 i 在 range(secret) 中：获取("ping")

通过访问日志揭示秘密的价值。同样的模式也存在于针对英特尔SGX的受控通道攻击中，其中内存分页模式暴露了enclave状态[15]。

缓解措施

严格模式。对于任何具有秘密污染边界的循环，自动触发严格评估。在严格模式下，状态更改工具调用将被阻止或需要用户确认。

循环限制。如果循环计数依赖于机密数据，则拒绝或限制最大迭代次数。

调用批处理。将重复的良性操作合并到单个批量请求中，从而打破循环计数和秘密值之间的关联。”

4.2 基于异常的信息泄露

威胁。如果仅当密钥满足特定条件时才抛出异常，则每次执行时，错误的出现与否会泄露一位信息。类似的信道已被用于在强化的内核原型中提取密钥[16]。

缓解措施

显式结果类型。使用结构化输出（如 Result{ok, error}）替换异常，从而允许以统一的方式处理两种路径。

一致的控制流。确保成功和错误分支以相同的时序和代码结构执行，以防止基于发散的泄漏。

4.3 时序信道

威胁。执行时间可能因依赖于秘密的逻辑而异——例如，休眠秘密秒数或使用命中不同缓存行的分支。Kocher 的经典著作表明，即使是亚毫秒级的差异也可能泄露 RSA 密钥 [17]; 后来的研究表明，可以通过缓存时序完全恢复 AES 密钥 [18]。

缓解措施

定时器桩。删除对非信任代码中高分辨率定时器的访问，或引入抖动以降低精度。

常数时间操作。在返回控制之前，将敏感操作填充到其最坏情况的运行时间，如在密码库中。

确定性调度。以固定的顺序和时间模式处理工具调用，消除与秘密值相关的运行时变化。

总而言之，这些缓解措施——循环钳制、结构化错误处理和恒定时间执行——可以在不改变CaMeL能力模型的情况下抑制最实际的侧信道。对于处理受监管或机密数据的系统，这些控制措施至关重要，因为必须考虑间接泄漏。

5 架构限制

虽然CaMeL引入了强大的基于能力执行模型，但其当前设计带来了一些架构上的权衡。这些包括性能瓶颈、策略管理的复杂性以及解释器语言语义的局限性。在本节中，我们概述了关键挑战，并提供了实用的设计调整，这些调整可以支持更高效和可扩展的部署。

5.1 双LLM的性能开销

CaMeL通过使用两个大型语言模型来分离控制和数据：一个特权LLM（P-LLM），用于生成计划；一个隔离LLM（Q-LLM），用于验证不受信任的内容。虽然这种分离提供了强大的数据隔离，但它有效地使模型调用次数增加了一倍。

OpenAI发布的GPT-4指标报告显示，每个请求的中位延迟为1-2秒，定价为每1000个token（提示+补全）$0.03–$0.06[19]。在QLLM必须处理多个工件的工作流程中——例如审查10封电子邮件——延迟可能超过10秒。这种延迟在面向客户的聊天机器人或支持代理等交互式应用程序中通常是不可接受的。

为了减少这种开销，我们推荐以下设计策略：

1. 计划模板缓存。许多企业提示语都属于一小组重复的意图（例如，“总结我的收件箱”、“提交此费用报告”）。通过提示语哈希值缓存已知的安全计划，允许重复使用，而无需重新调用 P-LLM。

2. 确定性微型解析器。对于诸如 JSON 之类的结构化输出，使用手写或生成的解析器比调用 LLM 更快且更经济。这与 ReAct 风格混合代理中的技术相呼应 [20]。

3. 批量处理 Q-LLM 提取。当相同的验证逻辑必须应用于多个字符串时（例如，从 100 张收据中提取“金额”），将它们连接成一个提示可以分摊每次调用的成本。

内部测试表明，将缓存与确定性解析器相结合，可以在保持CaMeL策略保证的前提下，减少高达50%的token使用量和端到端延迟。

5.2 大规模策略维护

CaMeL 中的每个工具都由一个 Python 策略函数管理，该函数指定允许的数据流。在大型组织（尤其是拥有数百个 API 的组织）中，这会导致策略蔓延：逻辑不一致、规则重复以及缺乏集中审计。这些问题与基础设施即代码研究中发现的配置漂移问题相呼应 [21]。

为了解决这个问题，我们建议采用具有以下特性的策略即代码框架：

声明式语言。诸如 Rego（用于 Open Policy Agent 中）之类的工具将访问逻辑表示为纯粹的规则，这些规则更容易测试、审计和验证 [22]。

可重用模块。通用规则（例如“仅在域内共享”）可以导入并在多个工具中重用。

可视化界面。基于 GUI 的编辑器降低了非工程利益相关者安全地阅读或修改策略规则的门槛。”

在一个声明式引擎中集中策略可以简化治理，减少人为错误，并使策略行为更容易推断。

5.3 解释器语言约束

CaMeL 使用 Python 的一个受限子集来定义工具计划。虽然这提高了开发人员的可访问性，但它继承了 Python 的问题特征：动态类型、异常驱动的控制流和反射。这些特性使得静态分析变得困难，并阻止了对信息流的强有力保证。

一种更稳健的方法是使用面向安全的领域特定语言 (DSL) 重新实现计划解释器。这种语言将支持：

有界循环和简单、显式条件语句

仅限一阶函数调用（无反射或元编程）

类型系统中嵌入的能力标签

这与先前在基于语言的安全方面的工作相呼应，例如 FlowCaml [NT0][8]，它能够实现信息流约束的编译时强制执行。将 DSL 嵌入到像 F 这样面向证明的平台中，可以对恒定时间行为和非干扰性 [NT1][23] 进行形式验证。

6 与其他防御方法的比较

企业安全团队有多种策略可用于防御提示注入[24]。这些方法在干预堆栈的位置（模型层、系统层或输入/输出层）方面各不相同，并且每种方法都有不同的权衡。下面，我们将CaMeL与三种常见的防御类型进行比较。

模型层面的鲁棒性。指令调优和偏好对齐方法——例如InstructGPT和Constitutional AI——旨在使模型本身更能抵抗恶意提示[25, 26]。这些技术对大型语言模型进行微调，以忽略或抑制嵌入在上下文中的有害指令。虽然它们平均降低了越狱成功率，但它们仍然是启发式的：攻击者仍然可以制作混淆的有效载荷，绕过训练过滤器。此外，大多数企业使用闭源模型，无法直接对其进行重新训练。

CaMeL 采取了一种不同的方法，将 LLM 视为一个黑盒。它没有修改模型，而是增加了一个运行时策略层来控制数据如何流经代理决策——即使在模型内部不可访问时也能提供保护。

系统级沙盒。诸如谷歌的gVisor和微虚拟机框架之类的隔离工具限制了代理进程在操作系统级别可以执行的操作[27]。这些沙盒在遏制代码执行错误或恶意软件造成的损害方面是有效的，但它们不能解决允许的功能被滥用的问题。例如，如果允许SMTP，注入的提示仍然可以通过制作看似合理的电子邮件来发送敏感数据。

CaMeL通过对各个工具调用的细粒度能力检查来补充沙盒机制，基于数据来源和上下文（而不仅仅是系统级权限）来过滤请求。

静态过滤和输入清理。一些防御措施会扫描输入内容，以查找已知的攻击模式——例如，将“忽略先前指令”之类的关键词列入黑名单，或删除可疑的HTML标签。这些过滤器部署起来快速而简单，但却很脆弱：红队研究表明，它们只能阻止不到30%的新型越狱策略[28,29]。攻击者可以迅速找到释义、编码技巧或Unicode变体来绕过静态规则。

相比之下，CaMeL在解析后执行动态的、上下文感知的验证，基于来源标记输入，并在执行时强制执行策略。这使其更能抵抗以前未见过的提示注入策略，并避免过度依赖脆弱的字符串匹配。

总而言之，CaMeL是对现有防御措施的补充。它特别适用于无法重新训练基础模型，但需要对LLM如何处理和处理不可信输入进行结构化、可验证控制的企业。

7 结论

这项工作扩展了CaMeL，解决了被忽视的威胁和架构挑战，这些威胁和挑战影响了其在现实世界环境中的可部署性。我们识别出其安全态势中的三个核心差距——初始提示信任、输出操纵和侧信道暴露——并提出了缓解措施，这些措施在保留CaMeL细粒度策略模型的同时，提高了其鲁棒性和可扩展性。通过引入自适应风险等级、提示/输出过滤和可验证的执行模型，我们规划了一条通往生产级CaMeL变体的道路，该变体适用于受监管和高保证环境。我们的响应不是取代CaMeL，而是增强了其基础，为从学术原型过渡到适用于LLM代理的企业级安全框架提供了具体步骤。