deepseek总结

摘要

随着ChatGPT等大语言模型（LLM）扩展为系统化平台，已开始支持第三方应用。这些LLM应用采用基于自然语言的自动化执行范式：即应用及其交互通过自然语言定义，可访问用户数据，并允许彼此及与系统进行自由交互。这种LLM应用生态与早期计算平台的环境相似——彼时应用与系统之间缺乏充分隔离。由于第三方应用可能不可信，加之自然语言接口存在不精确性，当前的设计方案给用户带来了安全与隐私风险。本文旨在探讨能否通过执行隔离解决这些问题，以及在基于LLM的系统中（系统组件之间、LLM与应用之间、应用之间存在任意自然语言交互的背景下）隔离机制应如何实现。为此，我们提出ISOLATEGPT架构设计，该方案证明了执行隔离的可行性，并为在基于LLM的系统中实施隔离提供了实现蓝图。我们针对多种攻击场景对ISOLATEGPT进行了评估，证明其能在不损失功能的前提下，有效防御非隔离LLM系统中存在的安全、隐私及可靠性问题。在四分之三的测试查询中，ISOLATEGPT为提升安全性带来的性能开销低于30%。

一、引言

大语言模型正被逐步扩展为独立的计算系统（通常称为代理系统）[1-5]。其中部分基于LLM的系统，如ChatGPT[1]和Gemini[2]，已开始支持第三方应用。这些LLM应用及其交互通过自然语言定义，被授权访问用户数据，并允许与其他应用、系统及在线服务进行交互[6-7]。例如，某航班预订应用（通过LLM指令）可能利用用户在系统对话中共享的个人数据，并联系外部服务完成预订流程。
这种基于自然语言的自动化执行范式虽然提升了LLM应用的实用性和系统能力，但也引入了多重安全与隐私风险。具体而言：基于自然语言的应用和交互缺乏传统编程接口的精确性，导致审查难度显著增加；同时，为实现自动化而向应用开放用户数据、其他应用访问权限及系统能力，由于第三方开发者可信度存疑，带来了严重风险。若某航班预订应用不可信，可能会窃取用户个人信息或暗中预订最昂贵机票。鉴于这种新型执行范式固有的风险，基于LLM的系统在设计时必须将安全与隐私作为核心考量。

本文通过提出一种旨在保障应用执行安全的LLM系统架构来解决上述问题。借鉴传统计算系统的经验[8-12]，我们的核心思想是隔离应用执行环境，仅允许应用通过经用户授权的明确定义接口与系统交互。该设计从根源上减少了LLM系统的攻击面——应用在受限环境中运行，其对外交互均受管控。尽管执行隔离在传统计算系统中早已存在，但将其理念应用于LLM系统仍面临特殊挑战：隔离环境需要安全地接入更广泛的系统上下文，同时需要为基于自然语言的交互定义安全的接口。
我们通过实现ISOLATEGPT来践行这一理念，该系统通过隔离机制保障应用执行安全。为在确保安全性的前提下提供与非隔离LLM系统同等的功能，ISOLATEGPT需克服三大挑战：其一，需要实现用户与隔离环境中应用的无缝交互。对此，ISOLATEGPT开发了名为"中枢"的可信中央接口，该模块感知所有隔离应用的存在，能可靠接收用户查询并路由至相应应用。其二，需要确保隔离环境中的应用能完整解析用户查询。对此，ISOLATEGPT为每个应用配备专用LLM实例（即应用拥有独立LLM），并在名为"辐条"的独立模块中向隔离环境提供历史上下文，使应用能精准处理用户请求。其三，需要实现互不信任应用间的安全协作。对此，ISOLATEGPT提出辐条间通信协议，通过中枢路由在无感知的辐条间传递明确定义的请求。这些模块构成了ISOLATEGPT设计的核心，即"中枢-辐条"架构。
我们通过与自主开发的基准非隔离系统VANILLAGPT对比，从安全效益、功能完整性和性能三个维度评估ISOLATEGPT。安全评估中，我们实施多个案例研究，采用基准测试集[13]中的攻击场景，模拟攻击者试图篡改其他应用行为、窃取应用数据及系统数据的行为。同时考虑因自然语言歧义导致用户数据意外泄露和系统行为异常的场景。实验表明，ISOLATEGPT的执行隔离架构既能抵御恶意攻击，也能规避语言歧义引发的安全问题。
功能与性能评估基于LangChain[14]基准测试集[15]，该测试模拟多种用户请求类型：无需调用应用、需调用单个应用、需调用多个应用、需多应用协作。结果显示，ISOLATEGPT在所有测试中均实现了与基准系统VANILLAGPT相同的功能，同时提供了额外的安全保障。性能方面，相较于非隔离系统，ISOLATEGPT因处理用户查询需要额外步骤而产生开销。在75.73%的测试查询中，ISOLATEGPT的性能开销低于30%。

主要贡献如下：
1.论证了在LLM系统基于自然语言的自动化执行范式中，执行隔离机制在缓解第三方应用引发的安全隐私问题上的可行性，并提出AI/LLM系统中实施执行隔离的架构蓝图。
2.通过开发ISOLATEGPT实现所提架构，证明其在无功能损失前提下能防御多种安全隐私问题。在75.73%的测试查询中，为提升安全性带来的性能开销低于30%。
3.开源ISOLATEGPT源代码¹以促进后续研究。除基于LangChain[14]的实现外，还与LlamaIndex[16]合作将其整合为Llama包²。

展望未来，ISOLATEGPT旨在帮助研究界理解执行隔离在保障LLM系统安全中的可行性、优势与局限。我们期待该工作为后续研究奠定基础，例如通过权限模型实施访问控制，或将执行隔离作为LLM系统安全机制的补充方案。

【个人总结】
研究背景：
1、LLM正演变为Agent系统
ChatGPT、Gemini等已支持第三方应用，通过自然语言定义功能，可访问用户数据、相互协作并调用外部服务（如自动订票、邮件附文件）。
2、自动化执行带来安全危机
恶意攻击：不可信应用可窃取数据、篡改其他应用行为（如提示注入）。
自然语言模糊性：指令冲突、意外数据泄露（如旅游应用误获医疗隐私）。
3、传统方案难以直接套用
传统计算系统靠“执行隔离”保障安全，但LLM系统需在隔离环境中接入丰富上下文，且交互基于自然语言，定义安全接口更具挑战。
主要贡献：
1、提出将执行隔离应用于LLM Agent系统，并论证其可行性。
2、设计并实现ISOLATEGPT架构——一套基于“中枢-辐条”模型的隔离方案，为LLM系统安全提供实现蓝图。
3、证明安全与功能可兼得：
（1）能有效防御恶意攻击和自然语言模糊性问题（在扩展攻击测试中，所有潜在恶意请求均被标记警告）。
（2）与非隔离系统相比，功能完全无损，且 75.73%的查询性能开销低于30%。
4、开源代码（基于langchain实现），并与LlamaIndex集成，推动后续研究。

二、动机

A. 基于LLM的系统

大语言模型正被逐步扩展为具备多种能力的系统，例如连接在线服务、保持持久化记忆以及执行程序等[6-7]。这些能力极大地拓展了LLM的实用性，使其能够胜任各类任务。事实上，已有研究者预见这类基于LLM的系统将提供堪比操作系统的效用[17]。LLM供应商已认识到这一潜力，并正在部署独立的LLM系统（如ChatGPT[1]）以及基于LLM的计算设备（如Alexa智能音箱[3]）。近期，LLM供应商还开始支持第三方应用[18-19,3]，这进一步增强了LLM的能力，从而提升了基于LLM的系统的实用性。
1）LLM应用架构：不同系统之间，甚至同一系统内部（对于支持多种应用类型的系统），LLM应用的具体架构可能存在差异，但其核心组件在各类LLM和基于LLM的系统中是通用的³。第三方应用（LLM应用⁴）的核心包含两部分：一组面向LLM的自然语言功能描述（即指令集），以及在大多数情况下的API端点，用于发送和接收数据与指令[22,18]。
为了利用应用响应用户查询，基于LLM的系统会将应用的功能描述和API端点加载到其内存（即上下文窗口）中，以便LLM能够构建必要的上下文（例如，在不同应用的API之间交换信息），从而借助应用解决用户请求[22,18]。此外，用户与应用之间、用户与LLM之间交换的消息（例如，先前的对话历史）也保存在内存中，以便为后续用户请求提供与上下文相关的响应[24]。为了展示不同应用与系统组件之间的交互，我们在图1中描绘了通过两个LLM应用处理查询的执行流程。
这种执行模型使得基于LLM的系统能够无缝处理多个实际用例，而这些用例在传统计算系统中需要用户明确付出努力，或者此前根本不存在。下文通过几个案例研究展示基于LLM的系统的实用性。我们将在第II-B节和III-D节回顾这些场景以引出本文工作和安全目标，并在第V节评估我们系统提供的保护。

案例研究A. 数据访问：预订航班。 用户希望使用在线旅游预订服务预订航班。在传统系统中预订航班，用户需要咨询旅游预订服务，选择适合自己的航班，然后提供个人信息和支付详情完成预订。在基于LLM的系统中，用户可以通过安装旅游预订应用来自动化此任务。基于内存中应用的功能描述和API端点，基于LLM的系统将构建上下文，调用相关API（携带适当数据）来搜索和预订航班。LLM可能无需请求用户获取预订所需的所有数据，而是利用其内存（包括从先前用户对话中提取的数据）自动提供预订航班所需的信息（例如，用户姓名、出生日期、护照信息、商务舱或经济舱偏好以及信用卡详细信息）。
案例研究B. 应用协作：邮件文件附件。 用户希望在回复邮件时附加云盘中的文件。传统上完成此任务，用户需要打开云盘，手动搜索文件，然后将其附加到邮件中。在基于LLM的系统中，用户可以通过安装邮件和云盘应用来自动化此任务的多个流程。基于内存中两个应用的功能描述和API端点，基于LLM的系统将构建上下文，调用这两个应用的API并在它们之间交换信息。本质上，如果用户查询要求基于LLM的系统在回复邮件时附加文档，基于LLM的系统将知道调用哪些API从云盘应用检索文件，以及调用哪些API在邮件应用中附加该文件。
案例研究C. 信息综合：预订最低车费车辆。 用户希望从提供最低车费的网约车服务中预订车辆。传统上完成此任务，用户需要咨询几个网约车服务，向这些服务提供其出发地和目的地，比较车费，然后选择车费最低的服务。在基于LLM的系统中，用户可以安装几个网约车应用并自动化此流程。具体来说，基于LLM的系统可以调用网约车应用的API，向它们提供相关信息（其中一些信息系统可能已经拥有，例如用户的位置），将它们的响应加载到内存中，比较响应，然后选择提供最低车费的应用为用户进行预订。
案例研究D. 改变系统行为：小说写作。 用户需要帮助创作小说（例如，构思创意、故事反馈）。在没有LLM的情况下完成此任务，用户可能需要联系同事、朋友或家人，讨论想法并得出结论。在基于LLM的系统中，用户可以安装一个小说写作助手应用。该应用可以通过指令改变系统行为，以协助用户进行小说写作（例如，在响应用户查询时发挥想象力）。安装了此类应用的基于LLM的系统可以从小说的写作视角来解读用户查询。

B. 安全与隐私风险

尽管在共享内存空间中执行应用有助于基于LLM的系统无缝处理复杂的用户请求，但这引入了严重的安全与隐私风险。在最高层面上，应用可以访问数据并影响其他应用及LLM的执行/行为[25-27]。这些风险既存在于存在攻击者的情况下，也存在于没有攻击者时。
攻击者可能部署恶意应用或向应用发送恶意指令，以引导LLM窃取敏感用户数据[28-29]。例如，在案例研究B中，一封包含恶意指令的邮件可能引导LLM从用户的云盘中窃取敏感文档。类似地，攻击者可能覆盖另一个应用的功能描述以控制其行为[25]。例如，在案例研究C中，每当用户要求基于LLM的系统比较应用车费时，一个网约车应用可能引导LLM抬高另一个应用的车费。此外，现有计算系统中的攻击也可能适用于基于LLM的系统，因为它们支持类似的组件（例如内存、代码执行）。例如，先前的研究表明，当基于LLM的系统通过基于SQL的数据库管理其内存时，SQL注入攻击可以迁移到这些系统上[30]。同样，执行任意代码的能力使得基于LLM的系统易受远程代码执行攻击[31]。
即使在不存在攻击者的情况下，LLM对自然语言指令的不精确和模糊解释与应用，也可能无意中给用户带来与攻击者类似的风险[25]。在多种情况下，指令的解释可能不精确和模糊，例如当存在来自应用的冲突指令时。例如，在案例研究D中，如果用户安装了一个症状诊断应用（该应用指示LLM要客观），同时已经安装了指示LLM要富有想象力的小说写作助手应用，就可能产生冲突。在解释这些指令时，LLM可能做出模糊的解释，从而影响两个应用的行为。类似地，自然语言策略的应用在多种情况下也可能不精确和模糊，例如当存在定义不一致时。例如，旅游预订应用和症状诊断应用可能都需要个人数据，但所需个人数据的性质不同。在解决用户请求时，LLM可能（错误地）将与症状诊断应用最初收集的相同的个人数据分享给旅游应用（类似于案例研究A中讨论的自动数据共享）。

C. 保障基于LLM的系统安全

基于LLM的系统中存在的安全与隐私问题，与以往的计算系统相似，这些系统在发展过程中，在支持多应用执行与协作方面也曾面临困境。例如，随着Web生态系统的发展，网站从简单的HTML文档转变为复杂的应用程序，浏览器要安全地执行并支持多站点协作并非易事。例如，浏览器最初提出了同源策略[32]等访问控制机制，但当这些对策被证明不充分后，又引入了沙箱化和进程隔离机制，最近期的例子是Chrome的站点隔离[33,12]。与传统的桌面操作系统（应用程序以用户权限运行）不同，移动操作系统（以及后来的桌面操作系统）同样将应用程序与系统隔离、应用程序之间相互隔离，并定义了清晰的跨应用通信接口[34-35]。
基于LLM的系统仍处于起步阶段，目前尚未为多应用的安全执行与协作提供任何实质性的保护措施。为此，本文提出了一种基于LLM的系统架构，旨在通过执行隔离来保障应用的安全执行。借鉴先前系统的经验教训[8-12]，我们的核心思想是隔离应用的执行，并仅允许通过一个可信的中介（具备用户授权的明确定义接口）进行应用与系统之间的交互。这种执行模型显著减少了基于LLM的系统的攻击面，因为应用的活动被限制在其执行空间内，且它们与其他应用及系统的交互都受到管控。
尽管应用隔离的思想借鉴了先前系统的设计，但这里的应用场景是全新的。随着新计算系统的出现，它们带来了独特的挑战，需要解决复杂的问题来适应这种设计。正如浏览器和移动平台安全仍然是活跃的研究领域一样，基于LLM的系统具有独特的特点，值得特别关注。将基于LLM的系统与其他计算系统区分开来的两个关键特点是：在基于LLM的系统中：(i) 应用及其彼此之间、以及与系统之间的交互基于自然语言而非明确定义的接口；(ii) 应用与系统之间存在大量的自动化交互。
由于应用与系统之间的交互基于自然语言指令，与通过清晰定义的编程接口（正如其他计算系统的情况[30-31]）进行交互的净化相比，自动净化这些自然语言交互更具挑战性。
同样，由于应用与系统之间存在大量交互，因此不能简单地将应用在沙箱中执行并限制其对外部资源的访问。相反，基于LLM的系统中，应用需要感知系统能力（例如，存在其他可用于协作的应用）、需要访问超出应用自身范围共享的用户数据（例如，如果完成查询所需）、以及先前的用户交互（例如，以提供上下文相关和个性化的响应），从而在最小化用户参与的情况下有效执行任务。
这些差异要求我们重新思考传统的隔离和协作接口。具体而言，在基于LLM的系统中，需要为沙箱提供丰富的用户数据和上下文信息，并且需要为第三方应用与LLM之间（它们之间可能没有预先存在的关系）基于自然语言的协作定义安全的接口。

三、威胁模型

A. 系统模型

我们考虑一个支持第三方应用的基于LLM的系统。与现有流行的基于LLM的系统（例如ChatGPT）类似，该系统通过在共享执行环境中执行多个应用来支持应用间的协作[25,36]。为处理用户请求，应用可以连接到在线服务以发送和接收数据。基于LLM的系统负责促进用户与应用之间的交互，例如使用合适的应用来处理用户请求。系统维护并管理一个持久化内存，其中包含用户与应用之间、用户与LLM之间的原始及经过处理的交互信息。基于LLM的系统利用其内存中的数据和上下文来处理用户查询。

B. 攻击者能力与目标

我们假设攻击者能够在基于LLM的系统应用商店中部署恶意应用，诱骗用户从应用商店外部安装恶意应用，并且能够向良性应用暴露恶意内容。攻击者的目标可能包括：(i) 影响或控制其他应用和/或LLM的执行，(ii) 窃取存在于基于LLM的系统内存中或其他应用中的敏感数据。如第II-B节所述，即使在没有攻击者的情况下，自然语言的不精确性和模糊性也可能无意中引发安全风险。例如，当存在冲突指令或自然语言定义不一致时。

C. 信任关系

我们假设LLM及其宿主系统是可信且未被攻破的，并且没有直接意图伤害用户（尽管它们仍然容易受到攻击，例如提示注入）。我们认为应用是不可信的，并且可以实现上述攻击目标。我们还假设应用处理的内容可能是恶意的（例如，恶意电子邮件或网站），并可能使外部攻击者（即与应用无直接关联）实现上述目标。最后，我们假设自然语言指令的解释和应用存在模糊性和不精确性[37]。

D. 我们的范围

1)范围内：我们旨在防止恶意应用的对抗行为以及恶意内容通过良性应用传播到系统。我们观察到，恶意应用可能试图控制或改变其他应用和/或LLM的行为。例如，在案例研究C中，恶意网约车应用可能试图操纵彼此报告的车费。恶意应用还可能试图窃取系统内存中或存在于其他应用中的数据。例如，在案例研究B中，恶意邮件应用可能试图从云盘应用中访问任意文档。保护系统免受攻击者试图控制其他应用或LLM，或从它们那里窃取数据的攻击，属于我们的范围。
我们还观察到，自然语言的不精确性和模糊性可能带来安全风险，例如导致应用/LLM意外受损或用户数据泄露。例如，在案例研究D中，小说写作应用对LLM行为的改变可能持续存在于使用该应用的上下文之外。类似地，当案例研究A中的旅游预订应用需要访问个人数据时，LLM可能泄露之前为安排医生预约而收集的个人数据，而没有意识到每种应用所需的个人数据性质不同。在多应用执行环境中，由于自然语言的不精确性和模糊性而导致应用/LLM意外受损或用户数据泄露的安全问题，属于我们的保护范围。

2)范围外：我们观察到，对抗行为也可能发生在应用内部。例如，在案例研究B中，邮件应用在处理恶意邮件文本时可能遭到入侵。此类攻击可能利用基于自然语言的恶意技术，例如提示注入[26]。在单一应用范围内防范此类攻击不在我们的范围内，但是，阻止此类攻击传播到系统中的其他应用属于我们的范围。例如，在案例研究B中，我们的目标是防范恶意邮件指示云盘应用共享敏感文档的攻击。

【个人总结】
1、系统模型
支持第三方应用的LLM系统，应用在共享执行环境中协作，系统维护持久化内存（存储用户与应用/LLM的交互信息），用于处理查询。
2、攻击者能力与目标
可部署恶意应用、诱骗安装、向良性应用注入恶意内容。
目标：①控制/影响其他应用或LLM；②窃取系统内存或其他应用中的敏感数据。
此外，自然语言的模糊性本身也会引发风险（如指令冲突、数据意外泄露）。
3、信任关系
LLM及宿主系统可信（但易受攻击如提示注入）。
第三方应用不可信，处理的内容可能恶意。
自然语言存在固有的模糊性和不精确性。
4、保护范围
范围内：①阻止恶意应用控制/窃取其他应用或系统；②防止自然语言模糊性导致的应用受损或数据泄露。
范围外：不防范单个应用内部的攻击（如恶意邮件入侵邮件应用本身），但会阻止其传播到其他应用（如邮件指示云盘窃取数据）。

四、ISOLATEGPT：系统架构

我们提出ISOLATEGPT，这是一个基于LLM的系统，它通过在独立的隔离环境中执行应用来保障应用执行的安全。ISOLATEGPT的目标是提供与非隔离系统相同的功能，同时减轻恶意应用对其他应用或系统的攻击。为此，ISOLATEGPT必须克服三个主要挑战：(i) 允许用户与在隔离环境中执行的应用无缝交互，(ii) 使用隔离环境中的应用解决用户查询而不损失功能，(iii) 允许互不信任的应用安全地协作。

为了解决第一个挑战，需要一个可信的中央接口，该接口感知隔离应用的存在，并能可靠地接收用户查询并将其路由到合适的应用。我们在ISOLATEGPT中将此接口称为中枢。为了解决第二个挑战，每个应用需要配备其专用的LLM，并且需要为该LLM提供先前的上下文，以便其能恰当地处理用户查询。ISOLATEGPT将这些任务划分到一个称为辐条的组件中。为了解决第三个挑战，ISOLATEGPT需要能够在互不知晓对方存在的辐条之间，可靠地路由可验证的请求（即通过像中枢这样的可信权威）。ISOLATEGPT通过提出一种称为辐条间通信协议的协议来处理此任务。ISOLATEGPT通过构成其"中枢-辐条"架构的模块来应对这些挑战。图2详细描述了查询在ISOLATEGPT中枢-辐条架构中的生命周期。

我们使用LangChain[14]和LlamaIndex[16]这两个广泛使用的开源LLM框架来实现ISOLATEGPT。为了隔离中枢和辐条的执行，我们采用了进程隔离，这是已部署系统中的标准做法，例如Chrome[12,38]。由于实现细节对于理解ISOLATEGPT的架构并非关键，我们将其讨论推迟到附录A。

A. 中枢目标与设计

由于ISOLATEGPT中的应用执行是隔离的，需要一个接口来管理用户与隔离应用之间以及隔离应用之间的交互，类似于操作系统中的内核。中枢在ISOLATEGPT中充当该接口。中枢的职责包括：拦截用户请求，判断请求是否需要调用应用或LLM，将带有适当上下文和数据的用户请求路由到应用或LLM，调解应用间的协作，以及维护系统级的上下文和数据。为了履行这些职责，中枢维护了一个操作器、一个规划器和一个内存模块。

1)中枢操作器：操作器是一个非LLM模块，具有明确定义的执行流程，用于管理中核内其他模块之间、与辐条之间以及辐条之间的交互。我们将操作器设计为非LLM模块，以确定性地控制与中枢其他模块及辐条的交互，并减少可能危及操作器的基于自然语言的攻击（例如提示注入）[26]。至关重要的是，操作器不易受到已知自然语言攻击的影响，因为它与不可信模块（即在辐条中运行的应用）交换基于自然语言的消息。

2)中枢规划器：为了处理每个用户请求，基于LLM的系统会借助一个定制的LLM（称为规划器）来创建计划（即顺序工作流程）。基于先前的工作[39-41]，中枢规划器有两个目的：(i) 确定用户请求是否需要应用还是仅需LLM；(ii) 如果需要应用，则识别其执行所需的必要资源（包括数据）。为了创建计划，规划器需要用户查询、先前的对话上下文（由内存模块提供，将在下文第IV-A3节讨论）以及可用和已安装应用的列表及其功能描述。
计划包括解决用户查询的主要应用，以及可能协助主要应用的次要应用（如果适用）。如果有多个应用可以解决用户查询，规划器可能返回多个主要应用。规划器还根据应用所需的资源，确定主要应用和次要应用之间是否存在任何依赖关系。如果没有依赖关系（例如，网约车案例研究C中的情况），中枢不允许应用之间交互，而是使用一个空的普通辐条（第IV-B4节）分别合成它们的输出。

3)中枢内存：ISOLATEGPT在中枢中维护并利用一个中央内存模块来保存系统级上下文。为了构建该上下文，内存模块管理并记录用户与ISOLATEGPT在所有应用上的所有交互，包括从这些交互中提取的数据。内存模块有两个主要目的：为规划器模块提供上下文（第IV-A2节），并决定和提供应用解决用户查询所需的数据。由于内存管理架构的细节对于理解设计中与安全相关的部分并非必要，我们将其讨论推迟到附录A-C。

4)查询生命周期：中枢模块间的交互：
1)中枢操作器拦截用户查询，并利用规划器模块选择解决查询所需的主应用，以及可能协助主应用的次应用。
2)如果规划器返回多个主应用，操作器会提示用户决定选择其中一个应用，类似于移动平台的做法[42-43]。
3)然后，操作器利用内存模块访问应用解决用户查询所需的数据。
4)接着，操作器为选定的应用创建一个辐条（如果已存在则直接调用），并在获得用户许可后，将用户查询和所需数据传递给它。
我们将在下一节第IV-B5部分继续介绍查询在辐条中执行时的剩余生命周期步骤。

【个人总结】

B. 辐条目标与设计

ISOLATEGPT需要一个接口，以便在隔离环境中借助应用解决用户查询。该接口的一个实例在ISOLATEGPT中称为辐条。辐条的职责包括执行应用、为应用提供解决查询所需的数据、与其他应用辐条协作，以及管理应用的内存。为了履行这些职责，辐条维护了一个操作器、一个LLM和一个内存模块。

1)辐条操作器：操作器是一个非LLM模块，具有明确定义的执行流程，用于管理辐条内其他模块之间的交互以及与中枢的通信。与中枢的操作器类似，我们将辐条的操作器设计为不依赖LLM，以便确定性地控制与辐条其他模块的交互，并减少基于自然语言的攻击（例如提示注入）的攻击面[26]。至关重要的是，操作器不易受到基于自然语言攻击的影响，因为它直接与不可信的应用交互，并将其自然语言消息传递给中枢。

2)辐条LLM：由于LLM应用包含自然语言描述和API端点，执行它们需要LLM的支持。为了发挥这一作用，辐条部署了一个支持应用的专用LLM，例如GPT-4[44]和LLaMA[45]。辐条还会微调此LLM，使其充当规划器[39-41]。为了创建计划，规划器需要访问用户查询（由中枢操作器共享）、解决查询所需的数据（由中枢操作器和辐条的内存模块提供，见第IV-B3节）、与应用先前对话的上下文（由辐条的内存模块提供），以及ISOLATEGPT上可用应用支持的功能列表（由ISC协议暴露，将在第IV-C节讨论），辐条可能利用这些功能来解决查询。创建的计划包括LLM的分步指令、需要从用户处获取的额外数据，以及解决用户请求所需的其他应用提供的功能。辐条LLM还负责执行生成的计划。
我们系统的一个关键区别在于，每个应用都配有一个专用的LLM实例，而在已部署的系统（如ChatGPT[1]）中，在共享环境中执行的多个应用使用同一个LLM实例。除了隔离之外，这种设计选择还使得不同的应用可以使用不同的LLM，例如，一个应用可以针对其用例使用微调后的LLM。

3)辐条内存：为了向LLM提供上下文和数据以解决用户查询，辐条也维护一个持久化内存。内存模块记录用户与应用之间的交互，包括从这些交互中提取的数据。中枢还会在用户同意的情况下，将从用户与系统及其他辐条的交互中获取的数据提供给辐条的内存模块，这些数据是辐条自身不具备但解决用户查询所需的。与中枢类似，我们将细节推迟到附录A-C。

4)专用辐条：除了运行专用应用的辐条外，我们还引入了另一类辐条，称为普通辐条，它们拥有标准辐条的所有组件，但不包含应用。这些辐条处理那些仅需使用标准LLM或专用LLM（例如，用于回答医疗问题的微调LLM，如Med-PaLM[46]）的用户查询。对于标准LLM的情况，查询也可以直接由中枢处理，但我们引入一个专用辐条来隔离查询的执行和管理。我们还可以支持类似于网络浏览器中隐私浏览模式[47]的用例：辐条可以在隐私模式下启动，在此模式下，它们不会获得先前的上下文来解决用户查询。

5)查询生命周期：辐条模块间的交互：
1)在从中枢接收到用户查询和相关数据后，辐条操作器将此信息以及从其自身内存模块中获取的额外相关数据传递给辐条LLM，以便生成处理查询的计划。
2)根据计划，如果需要额外数据，辐条操作器将此消息中继给中枢操作器。
3)如果中枢拥有该数据，它会在用户同意后与辐条共享。具体来说，它会向用户显示数据，并询问用户是否同意共享。
4)如果中枢不拥有该数据，它会将请求传达给用户，并将用户提供的数据中继给辐条操作器。
5)然后，辐条操作器使用辐条LLM处理请求，并将输出传递给中枢操作器，中枢操作器将其中继给用户。请注意，我们要求在应用执行任何不可逆操作（例如应用发送电子邮件或进行购买）之前获得明确的用户同意，这与已部署的基于LLM的系统（如ChatGPT[48]）类似（更多细节见附录A-D）。
6)如果用户就同一主题提出后续请求，中枢操作器只需将用户请求传递给辐条操作器，就像处理第一个查询一样。
7)如果辐条需要另一个应用提供的额外功能来解决查询，它会利用ISOLATEGPT的辐条间通信协议。
我们将在下一节第IV-C4部分继续介绍查询在与其他辐条协作时的剩余生命周期步骤。

【个人总结】

C. 辐条间通信

到目前为止，ISOLATEGPT的设计决策已经消除了许多隐私和安全风险，但 consequently 也消除了辐条间的自然协作。具体来说，辐条在隔离环境中执行，并且彼此不知道对方的存在。然而，辐条间的协作对于充分利用基于LLM的系统所实现的新功能至关重要。

ISOLATEGPT提出了一种辐条间通信协议，以允许辐条在隔离执行的同时安全地相互协作。在高层，ISC协议是辐条通过中枢相互交换消息的一套程序。这本质上允许ISOLATEGPT通过将信息流经可信实体（中枢）来控制不可信实体（辐条）之间的信息流。当此信息通过中枢时，我们的关键目标是筛查并终止攻击者发送复杂恶意指令（例如提示注入）的交换，或者自然语言的模糊性可能导致风险的交换（第II-B节）。ISC协议通过限制可交换的消息，并让用户参与消息筛查环节，帮助我们实现这一目标。

为了支持辐条消息交换，ISC协议需要向辐条广播可用应用及其功能，并提供一种机制，让辐条之间通过中枢发送和接收数据。

1)广播功能： 为了利用其他应用的功能，辐条（应用）在创建计划以解决用户查询时需要了解这些功能（第IV-B2节）。为此，ISC协议维护一个列表，其中包含ISOLATEGPT支持的所有预定义功能（例如，来自LLM应用商店中的所有应用），例如网页浏览和会议安排，并在辐条启动时将其暴露给辐条。ISC协议不会向辐条透露具有该暴露功能的应用是否已安装在ISOLATEGPT上，以减少用户数据的暴露和潜在滥用，例如，避免攻击者可以创建已安装应用指纹的情况[49-50]。然而，此信息会透露给中枢，中枢可能会安装应用，并在用户同意的情况下使其功能对辐条可用。

2)支持消息交换： 为了协作，辐条需要能够相互交互。基于LLM的系统中事实上的交互模式是基于自然语言的；然而，如果我们允许辐条交换自然语言消息，它们可能能够通过恶意指令（例如提示注入）相互危害。ISC协议通过定义一个协作工作流来约束辐条之间的自然语言消息流，从而帮助ISOLATEGPT避免此问题。
作为第一步，ISC协议限制辐条之间直接通信，只允许它们与中枢之间发送和接收消息。此外，ISC协议只允许辐条和中枢操作器之间交换消息，不允许LLM直接发送或接收任何消息，以确定性地控制消息流。具体流程包括：辐条LLM确定其需要帮助的功能（即通过规划，在第IV-B2节讨论），将该信息传递给辐条操作器，辐条操作器将此信息传递给中枢操作器，中枢操作器分享可以发送协作请求的格式以及预期响应的格式，然后交换实际消息。通过中枢路由消息的关键优势在于，可以在不信任的实体（即包含第三方应用的辐条）之间交换消息之前对其进行筛查。

3)消息筛查与辅助筛查： ISOLATEGPT要求用户手动筛查辐条之间交换的消息，因为目前没有万无一失的方法来自动检测恶意的自然语言指令。然而，ISOLATEGPT采取了多种措施来减轻用户的负担。

首先，当一个辐条向中枢请求某项功能的帮助时，中枢会将其与自己为解决该查询而生成的计划进行交叉引用，从而自动验证该请求（回顾第IV-A2节，中枢规划器也会推断出可能协助主应用的次要应用）。中枢将此信息传达给用户，以协助他们筛查消息。

其次，ISC协议要求应用为其所有功能提供明确定义的请求和响应格式，这些功能可供协作使用。⁵ 在高层，该格式要求应用提供其支持的功能名称以及可交换消息的数据类型（即 <功能, 请求|响应消息>）。

ISC协议还要求中枢为应用分配临时标识符，并将该信息嵌入请求/响应格式中。这些临时标识符使中枢能够通过避免应用可能试图编造不存在的协作的情况，来维护通信的完整性。临时标识符还有一个额外的好处，即不会直接透露应用的名称或其他提供的功能。

格式的其余部分允许发送方和接收方操作器自动验证交换的消息，即验证它们是否符合要求的格式。如果请求格式错误，它们将被直接丢弃，不会传达给用户。需要注意的是，对于某些数据类型的请求和响应，例如日期、整数和URL，辐条可能无需用户参与即可自动验证。此外，最近的研究提出了控制器，例如微软的AICI[51]和Guidance[52]，它们允许控制和验证LLM生成的内容，辐条也可以使用这些工具。

虽然这些措施可以可靠地为大量交互实现自动验证，但它们并不能覆盖所有交互，例如需要共享原始字符串的交互。为了协助处理此类情况，我们引入了一个权限模型。事实上，权限模型在现有计算系统（例如Android[53]）和新兴的基于LLM的系统（例如ChatGPT[48]）中都是标准做法，它让用户参与决策过程以规范应用的行为。我们的权限模型允许用户向基于LLM的系统传达他们的偏好，然后系统会自动执行这些偏好，而不是每次都询问用户。由于用户可能有不同的偏好和风险容忍度，我们使权限管理可配置，以便用户可以为不同场景设置不同的有效时间（详见附录A-D）。图4提供了一个示例权限对话框，在允许协作之前向用户显示以征求其同意。需要注意的是，我们不仅仅是让用户独自做出决定，实际上我们在权限对话框中包含了中枢对协作请求是恶意还是良性的评估（见图4中的警告）。考虑到中枢在处理请求之前，基于（非恶意的）用户查询、（经过审查的）应用描述以及其内存中（经过审查的）数据，在其自身（可信的）隔离环境中做出此评估，中枢的评估很难被操纵，因此相当可靠。

虽然我们提出了一个初步的权限模型来调节应用、用户和基于LLM的系统之间的交互，但我们相信，为了实现基于LLM的系统中更自动化的行为监管，需要一个全面的权限模型。然而，构建这样一个自动化的权限模型——以及其相关的用户体验设计——是一个正交问题，不在本文的讨论范围之内。我们还认为，（我们在本文中提出的）执行隔离是通过权限模型可靠地实施访问控制的必要前提。

4)辐条间协作的生命周期： 图3展示了通过ISC协议在两个辐条之间的协作。具体来说：
1)在确定自身无法独立完成请求后，辐条通知其操作器，操作器向中枢操作器请求，指定其需要帮助的功能。
2)中枢操作器确定可以满足请求功能的应用。如果有多个应用，或者需要安装应用来协助辐条，中枢操作器会请用户做出决定。然后，中枢操作器将请求和响应格式信息传递给请求辐条的操作器。
3)请求辐条的操作器随后格式化其请求（借助其LLM），并与中枢操作器共享。
4)然后，中枢操作器在获得用户同意后，将其中继给想要协作的目标辐条的操作器。
5)目标辐条的操作器验证请求格式，并将请求传递给其LLM（验证细节见第IV-C2节）。然后，其LLM利用应用处理请求，并将响应传递给辐条操作器，辐条操作器验证响应格式并将其发送给中枢操作器。
6)然后，中枢操作器在获得用户同意后，将其中继给发起调用的辐条操作器。发起调用的辐条操作器验证响应格式，然后将其传递给其LLM，LLM利用响应中的信息来完成请求。

为了支持需要使用多个应用，但应用之间无需相互共享数据的用户查询（如网约车案例研究C中的情况），我们依靠一个普通辐条来综合来自这些非数据依赖型应用的信息。具体来说，普通辐条充当主辐条，并向非数据依赖型辐条请求协作。这使得ISOLATEGPT能够在共享内存中综合来自多个应用的数据，同时确保应用不会篡改彼此的数据。请注意，数据交换仍然要接受恶意消息的筛查。

【个人总结】
总述：>广播功能：
消息交换功能

消息筛查功能

五、评估：保护效果分析

我们现在评估：
(i) ISOLATEGPT 是否能抵御我们威胁模型中概述的威胁和风险（本节）；
(ii) ISOLATEGPT 是否能提供与非隔离系统相同的功能（第六节）；
(iii) ISOLATEGPT 带来的性能开销（第七节）。

为了进行直接比较，我们开发了 VANILLAGPT，一个提供与 ISOLATEGPT 相同功能但不隔离应用执行的基于 LLM 的系统。在所有评估中，我们为 ISOLATEGPT 和 VANILLAGPT 配置了 OpenAI 的 GPT-4 API。我们在运行 Ubuntu（版本 20.04.6 LTS）的系统上运行这两个系统，该系统配备 AMD Ryzen 9 3900X 12 核处理器和 32GB 内存。

【个人总结】

A. 大规模应用危害与数据窃取评估

回顾我们的威胁模型（第三节），ISOLATEGPT 的目标是：(i) 保护应用免遭其他应用的危害；(ii) 防止应用数据被其他应用窃取；(iii) 避免自然语言的模糊性和不精确性意外危害应用功能；(iv) 避免数据意外泄露。由于这些问题主要源于应用在共享执行环境中执行，ISOLATEGPT 能够通过设计消除它们。为了展示对这些攻击的防护能力，我们首先使用先前工作[13]的基准测试（在其增强设置下）评估 ISOLATEGPT。

该基准测试用于评估支持应用的 LLM 系统的安全性，包含了我们在威胁模型中假设的大量攻击变种，但未包含应用试图从系统窃取数据的攻击。因此，我们首先通过增加攻击者可能针对的系统内存存储数据的场景来扩展该基准测试。这一增强增加了 544 个攻击，使总数达到 1,598 个，包括：应用试图相互危害、窃取彼此数据以及窃取系统中存储的数据。为了评估每个攻击场景，我们在应用或系统中配置相应的应用及其相关数据，然后执行提示以实施攻击。提示执行后，我们刷新系统并重复该过程进行下一个攻击，直到执行完所有攻击。

对于 VANILLAGPT，我们计算攻击成功率，即所有已执行攻击中成功利用系统的攻击比例。在 ISOLATEGPT 中，攻击要成功，需要能够请求其他辐条和/或访问来自中枢的数据，而这需要通过用户权限进行审核（第 IV-C 节）。这意味着攻击的成功取决于用户是否授予恶意流程的权限。回顾第 IV-C 节，如果中枢判定来自中枢的协作或数据访问请求具有潜在恶意，我们会在权限对话框中包含警告。因此，对于 ISOLATEGPT，我们报告警告率，即所有权限请求中带有警告的请求所占的比例。

1)总体趋势：表 I 列出了 VANILLAGPT 和 ISOLATEGPT 的保护评估结果。在高层面上，我们注意到即使对于不提供任何保护的 VANILLAGPT，许多攻击也未能成功。根据我们的调查，我们发现攻击失败是因为 LLM 凭借其防护措施能够检测到恶意的提示注入，这与提出这些基准测试的原始研究论文[13]的发现相符。
我们还注意到，相当数量的攻击在 VANILLAGPT 上确实执行成功，或者在 ISOLATEGPT 上显示了警告。对于 VANILLAGPT，在所有测试的攻击中，平均有 20.2% 的攻击成功。对于 ISOLATEGPT，平均有 7.6% 的情况出现了权限对话框，并且在这些情况中，100% 的权限对话框都包含了警告。这意味着相当数量的攻击在 VANILLAGPT 上能够成功，而攻击在 ISOLATEGPT 上可能成功的可能性取决于用户是否允许恶意流程。

2)当危害可能性明显时，LLM 防护措施更敏感：接下来，我们注意到，在 VANILLAGPT 和 ISOLATEGPT 中，跨应用数据窃取的攻击成功率和权限对话框出现率分别特别高。正如这些基准测试的原始评估[13]中也指出的，与通过危害应用造成财务和人身伤害相比，数据窃取的攻击成功率/可能性更高，一个可能的原因是 LLM 防护措施在保护用户免受那些危害可能直接且明显的攻击时更为敏感。
我们还注意到，在 VANILLAGPT 中，危害第二个应用的攻击成功率显著高于危害第一个应用。一个合理的解释是，随着 LLM 上下文窗口的增加，它们变得更容易受到越狱和提示注入攻击[54]。另一种解释是，如果一个恶意提示能够一次危害 LLM，那么在后续指令中，它可以使用相同的恶意提示再次危害它。
最后，我们注意到，从系统窃取数据的攻击成功率和权限出现率较低。这主要是基准测试中提示的局限性造成的，这些提示假设系统中的数据也以与应用/辐条内存中相同的描述符存储。而在现实中，为了使用更少的存储资源或进行其他优化，数据可能以结构化格式（即键值对格式）存储在系统中，并带有受限的描述[17]。

【个人总结】

B. 案例研究的保护评估

在用大量攻击评估 ISOLATEGPT 之后，我们现在通过定制的案例研究深入讨论 ISOLATEGPT 的保护效果评估。

图5：

1)应用危害：为了证明 ISOLATEGPT 能够保护应用免受恶意应用的危害，我们实现了案例研究 C 中描述的场景，即用户希望系统通过比较两个网约车应用的车费来预订最低车费的车辆。为了实现该案例，我们开发了"地铁叫车"和"快车"作为两个网约车应用。我们将"快车"实现为恶意应用，试图改变"地铁叫车"的行为，使得"地铁叫车"提供的车费总是比其实际报告的价格高出 10 美元。
图 5 并列比较了在 VANILLAGPT 和 ISOLATEGPT 中借助两个应用解决用户查询的摘要流程。从 VANILLAGPT 的执行流程可以看出，"快车"能够成功指示 LLM 向"地铁叫车"的预估车费增加 10 美元。而在 ISOLATEGPT 中，此攻击失败，应用报告的预估车费未被篡改。此攻击在 ISOLATEGPT 中失败是因为应用辐条中的 LLM 只能在其执行空间内执行应用的指令，而不能在其外部执行。请注意，非数据依赖型应用的结果是在一个隔离的空普通辐条中合成的，恶意应用无法篡改它。

图6：

2)数据窃取：为了证明 ISOLATEGPT 能够防止对存在于应用或系统中的用户数据的未经授权访问，我们实现了案例研究 B 中讨论的场景，即电子邮件和云盘应用协作用于在邮件中附加文档。我们没有自行开发应用来实现该案例，而是利用了 LangChain [55, 56] 上提供的 Gmail 和 GDrive 应用。我们模拟了一个外部攻击者的攻击，该攻击者发送一封包含指令的恶意电子邮件，指示 LLM 从 GDrive 窃取敏感文档。我们还通过指示 LLM 删除已发送和已接收的电子邮件来使攻击隐蔽。
图 6 并列比较了在 VANILLAGPT 和 ISOLATEGPT 中触发 Gmail 和 GDrive 的查询解决的摘要流程。在 VANILLAGPT 中，攻击者不仅成功窃取了敏感文档，还通过删除已发送和已接收的电子邮件隐藏了痕迹。相比之下，ISOLATEGPT 能够防御此攻击，主要是因为跨应用通信需要获得用户的明确同意。
此攻击展示了 ISOLATEGPT 设计的两个关键优势。首先，即使在用户永久允许两个应用协作的场景下（例如，因为用户信任它们），用户仍然有机会审查应用将要执行的不可逆操作（在此例中为发送电子邮件），这是 ISOLATEGPT 强制要求的（参见附录 A-D1 中关于永久权限的讨论）。其次，即使应用在 ISOLATEGPT 中被攻破，攻击也被限制在其隔离的执行空间中，不会扩散到整个系统。

3)意外数据泄露：为了证明 ISOLATEGPT 能够防止因自然语言的模糊性导致的用户数据意外泄露，我们扩展并实现了案例研究 A 中讨论的场景，即旅游预订应用所需的数据可能已与系统共享。我们开发了一个名为"旅行伴侣"的旅游预订应用，以及一个名为"健康助手"的医生预约应用。对于这两个应用，我们都指定需要个人数据，但没有精确定义具体需要哪些数据。为了改善用户体验，我们还指定，如果 LLM 在先前的交互中已经记录了数据，则可能无需向用户请求。安装这些应用后，我们首先查询系统触发"健康助手"，并分享了一些个人数据，包括用户出现的症状。然后，我们查询系统触发"旅行伴侣"，没有分享任何额外的个人数据，而是期望系统自动分享。
在解决用户查询后，我们注意到，在 VANILLAGPT 中，"旅行伴侣"提供的不精确定义导致其意外获取了它不需要的敏感和个人数据。而在 ISOLATEGPT 中，系统在调用"旅行伴侣"时也试图向其提供相同的个人数据，但失败了，因为在调用应用时共享数据需要获得明确的权限。图 7 比较了 VANILLAGPT 和 ISOLATEGPT 中的摘要执行流程。
我们还注意到，在此场景下，用户需要手动提供数据，这需要额外的努力。我们认为这种可用性与安全性的权衡是必要的。总的来说，此案例研究说明了应用进行精确声明的必要性，并强调了即使在没有主动攻击者的情况下，自然语言的模糊性也会给用户带来风险。

4)不受控的系统改变：为了证明 ISOLATEGPT 能够防止因自然语言的模糊性而危害或影响应用功能的实例，我们扩展并实现了案例研究 D 中描述的场景，即一个应用改变了系统行为。具体来说，我们实现了一个名为"创意缪斯"的小说写作应用，它使用强烈的语言指示 LLM 要富有想象力。此外，我们还实现了一个名为"症状解决者"的症状诊断应用，它也使用强烈的语言指示 LLM 要客观。我们在两个系统上同时安装这两个应用。
在解决用户查询后，我们注意到，在 VANILLAGPT 中，由于两个功能描述存在于共享内存空间中，LLM 试图平衡其响应，以同时遵循两个应用的指令。而 ISOLATEGPT 仅遵循"症状解决者"的指令，从而可能避免给用户一个意想不到的答案。图 8 并列比较了 VANILLAGPT 和 ISOLATEGPT 中的摘要执行流程。
此案例研究表明，即使应用不是恶意的，如果在共享环境中执行，它们的指令也可能相互干扰，导致安全问题。

【个人总结】

六、评估：功能正确性分析

由于 ISOLATEGPT 的执行流程不同于非隔离的基于 LLM 的系统，我们想评估这是否对其功能产生任何负面影响。为此，我们通过在多种用户查询上评估它们，将 ISOLATEGPT 的功能与 VANILLAGPT（我们实现的非隔离 LLM 系统）进行比较。具体来说，我们评估并比较它们在以下查询上的功能：(i) 不需要使用应用，(ii) 需要使用单个应用，(iii) 需要使用多个应用（最多 13 个），以及 (iv) 需要应用间协作（最多 5 个）。我们选择这些案例是因为解决这些查询将调用并利用 ISOLATEGPT 引入的新组件。
我们没有为这些场景创建自己的查询，而是依赖于 LangChain [14] 提供的基准测试 [15]，这些基准测试旨在评估使用 LangChain 框架开发的系统和应用的端到端查询解决准确性。这些基准测试类似于软件开发测试用例，将 LLM 系统生成的输出的执行流程和语义相似性与预期输出进行匹配。我们在附录 A-E 中提供了有关基准测试的更多细节。

A. 总体趋势
表 II 提供了 ISOLATEGPT 和 VANILLAGPT 的功能评估。对于所有包含应用的基准测试，正确率是通过将测试系统的输出与基准测试的预期输出相匹配的实例数除以输出总数来计算的。对于不包含应用的基准测试，与预期基准输出的文本相似度作为正确性的衡量标准。表 II 显示，对于所有涉及应用的基准测试，ISOLATEGPT 能够提供与 VANILLAGPT（没有执行隔离的基于 LLM 的系统）相同的功能。对于无应用基准测试，两个系统的准确率差异微乎其微。

B. 错误分析
ISOLATEGPT 和 VANILLAGPT 在"多应用协作"和"无应用"基准测试中都出现了错误。我们调查了这些情况，并在表 III 中提供了错误的细分。对于"多应用协作"基准测试，中间步骤错误发生在以下情况：应用被调用了两次、调用了意外应用、未调用预期应用、或者应用的调用顺序不符合基准测试的定义。然而，在所有实例中，LLM 提供的最终输出是正确的。对于意外应用调用和意外调用顺序，最终输出正确是因为获取正确响应所需的核心应用仍被调用。在应用未被调用的情况下，LLM 能够自行完成任务。在应用被调用两次的情况下，LLM 因为无法解析其响应而再次调用了该应用。总的来说，在所有这些情况下，LLM 都能够提出一个不同的计划来实现正确的输出，但与基准测试中描述的计划不匹配。
对于"多应用协作"基准测试的整体错误，LLM 无法解析应用返回的正确响应。对于"无应用"基准测试的整体错误，大多数错误是由于 LLM 返回的响应与预期响应之间缺乏相似性所致。我们将此错误归因于 LLM 的概率性。一小部分"无应用"基准测试的错误是由于响应长度超过上下文窗口造成的，这是 LLM 已知的局限性[17]。
基准测试局限性。 虽然我们依赖于经过同行评审[13]和广泛使用的 LLM 框架基准测试[15]，但它们并非完美无缺。例如，在现实世界中，基于 LLM 的系统可能会遇到这些基准测试范围之外的复杂和微妙的用例。尽管如此，我们相信它们足以帮助理解我们的系统设计——这是我们的核心贡献。

【个人总结】

七、评估：性能分析

接下来，我们通过与基线非隔离 LLM 系统 VANILLAGPT 进行比较，来评估 ISOLATEGPT 带来的性能开销。ISOLATEGPT 产生开销主要是因为其引入的组件需要额外的执行时间，也因为我们的原型系统未进行性能优化。对于性能评估，我们依赖与功能评估相同的 LangChain 基准测试 [15]。此外，在 ISOLATEGPT 中，如果解决查询需要用户权限，我们会自动授予。

A. 总体趋势

我们在表 IV 中提供了 ISOLATEGPT 和 VANILLAGPT 针对特定基准测试和不同组件的查询解决时间细分，并在图 9 中提供了高层次概述。正如预期，ISOLATEGPT 解决用户查询需要额外的时间。当不涉及应用时，查询的开销最低，但是，随着解决查询所需应用数量的增加，开销也随之增加。总体而言，对于超过四分之三（75.73%）的测试查询，与 VANILLAGPT 相比，ISOLATEGPT 的性能开销在 30% 以内。在第 90 和第 95 百分位数，开销分别为 1.24 倍和 1.80 倍。这一开销与早期实现进程隔离的原型系统（例如网页浏览器 [33, 57]）相当，在某些情况下甚至更好。例如，在名为 Gazelle [33] 的进程隔离浏览器原型中，加载网站的开销接近约 44%。我们在描述 ISOLATEGPT 中导致开销的组件时，指出了一些可以消除大部分开销的简单优化。

B. 规划和内存提取耗费额外时间

接下来，我们调查 ISOLATEGPT 引入的额外组件所带来的开销。从表 IV 中，我们注意到，对于 ISOLATEGPT 中的所有基准测试，中枢和辐条中的规划和内存提取过程占用了大部分额外时间。这些过程负责选择合适的应用、启动相关的辐条，以及与辐条共享解决用户请求所需的数据。需要指出的是，在我们的测量中，我们假设冷启动，即辐条总是需要重新启动并且不拥有任何数据。在实际运行环境中，辐条只需启动一次，后续查询可以直接调用，从而减少启动开销。此外，随着用户与辐条交互，辐条维护自己的数据，后续运行时它们只需要获取自身没有的数据，这进一步消除了从中枢到辐条的数据传输开销。通过并行化规划和内存提取过程也可以减少开销。
从表 IV（以及图 9c 和 9d）中，我们注意到，当涉及多个应用以及它们协作解决查询时，ISOLATEGPT 的表现尤其不佳。对于 ISOLATEGPT 中的"多应用"基准测试，我们发现 ISOLATEGPT 消耗的额外时间中，有 17.18% 和 80.43% 分别由中枢和辐条中的规划和内存提取过程占用。类似地，对于"多应用协作"基准测试，额外时间的 28.87% 和 67.67% 分别由中枢和辐条中的规划和内存提取过程占用。
中枢中的规划过程耗时，因为中枢需要遍历所有可用应用以找到最适合解决查询的应用。减少此开销的一种优化是让中枢仅基于启发式方法遍历选定数量的应用，例如，从常用应用和应用组合开始遍历。另一种优化是为单个应用创建定制的提示模板 [58]，以便中枢可以轻松地将用户查询与可用模板匹配，从而消除预测最适合解决用户查询的应用的成本。
在辐条的情况下，规划耗时是因为 ISOLATEGPT 中所有可用的功能都会暴露给辐条，并在规划过程中被考虑，以防它需要这些功能来解决查询。减少此开销的一种优化可以是仅共享应用/辐条可能需要的有限功能集，这可以由应用开发者暴露。
我们还注意到，对于"多应用"和"多应用协作"基准测试，随着涉及的应用越来越多，查询解决时间也在增加（表 IV）。因此，对于许多只涉及少数应用的用例，用户体验到的性能开销会更低。同样重要的是要注意到，应用数量增加与开销增加之间的正比关系并非基于 LLM 的系统独有，依赖进程隔离的先前计算系统，例如 Google Chrome，也随着进程数量和进程间通信的增加而面临性能开销问题 [12]。

C. 结论要点

我们的测量包括端到端的查询解决时间，即基于 LLM 的系统产生完整响应所需的时间，而不仅仅是出现前几个词的时间。因此，在实际环境中，我们预计用户感知到的开销可能不那么显著。同样重要的是要注意，LLM 通常生成响应较慢 [59, 60]，事实上，提高 LLM 的性能是一个活跃的研究领域 [61]，而且更新的模型正变得越来越快 [62]。随着未来 LLM 性能的提升，它将减少开销，并使像我们这样的安全改进更具吸引力。
尽管如此，具有进程隔离的安全保护在基于 LLM 的系统中会产生开销，正如它们在先前的计算系统 [33, 57, 12] 中产生开销一样。我们强调，隔离带来的好处是显著的，并且正如我们所讨论的，未来的优化可以提高 ISOLATEGPT 的可用性。

D. 成本开销

我们还计算了 10% 基准测试查询的成本，发现 ISOLATEGPT 的成本是 VANILLAGPT 的 1.85 倍。请注意，上面讨论的性能优化可以减少这些成本开销，并且随着 LLM 变得更便宜，安全措施的绝对成本将显著降低。例如，最新的 GPT-4o 模型（版本：2024-08-06）的成本比我们测试的那个（版本：0613）便宜约 12 倍 [63]。

【个人总结】

八、结论

基于 LLM 的系统，通常也称为代理系统，正在研究界 [39, 24, 17, 64, 7] 和工业界 [1, 2, 3, 4, 5] 涌现。随着这些系统的广泛部署，安全性、隐私性和可靠性需要成为其设计中的关键考量，但情况往往并非如此。类似于传统计算系统（例如 Web 和移动平台），保护它们的安全是一个（并且仍然是一个）漫长的过程，基于 LLM 的系统也将需要大量工作来从多个方面改善其安全性。

ISOLATEGPT 正是这样一项保护基于 LLM 的系统的努力，我们的评估为其提供了经验证据。通过 ISOLATEGPT，我们证明，通过创新和应用经过检验的安全实践，即执行隔离，我们可以显著提高基于 LLM 的系统的安全性。我们认为，创新和评估此类实践是评估它们在保护基于 LLM 的系统方面的局限性的重要一步。我们相信，这些知识为我们以及更广泛的安全社区奠定了基础，以便做出明智的后续步骤。

为了简化对 ISOLATEGPT 的扩展，我们已开源其代码。我们还与 LlamaIndex [16] 合作，将 ISOLATEGPT 集成为一个 Llama Pack。