Skip to content
ToLO Knowledge Base

IsolateGPT 执行隔离架构

一句话

核验状态:pending。 本页按论文自述做阅读笔记;venue、DOI、实现细节、benchmark 数字和结论仍需回到官方来源核验。正文中的数字均应读作”据论文报告”。

据论文,IsolateGPT 用 hub-and-spoke 架构把第三方 LLM app 的模型、记忆和执行上下文隔离开,再由可信 hub 做路由、权限和跨 app 协作控制。

为什么读这篇

IsolateGPT 是一条 agentic systems 执行隔离架构阅读线索,可对照本站 C_SAFE^{capability} 的实际工程实现。

它和 CaMeL 都属于”capability 系列”防御,但视角不同:

  • CaMeL: 单个 agent 内,控制流-数据流分离 + capability 标签
  • IsolateGPT: 多个 third-party agent 共存,进程级隔离 + hub 路由

读完它,你会理解 ToLO 防御里”capability”不只是 sanitizer 函数,而是架构层概念。

先对齐术语

  • Hub-and-spoke:可信 hub 负责路由、权限与用户确认;每个第三方 app 作为 spoke 在隔离上下文运行。
  • Process isolation(进程隔离):用 OS 进程边界限制一个 spoke 的内存、文件、网络或崩溃影响面。
  • ISC(Inter-Spoke Communication):spoke 之间通信必须经 hub 转发与检查,不能直接共享上下文。
  • C_SAFE^{capability}:ToLO 中的能力门控 sanitizer;IsolateGPT 展示的是架构级能力控制,不是单个 escaping 函数。
  • TCB(Trusted Computing Base):必须被信任的系统组件。IsolateGPT 中 hub 是核心 TCB。

核心贡献

  • 提出 agent app 执行隔离架构
  • 用 hub 统一管理权限与路由
  • 用 ISC(Inter-Spoke Communication)协议 约束跨 app 协作

它解决的问题

当 LLM 平台支持第三方 plugin / agent app(类似 ChatGPT plugin store、Claude MCP 生态),会出现:

  1. 跨 app 数据泄露:A app 处理的隐私数据被 B app 偷走
  2. 跨 app 行为劫持:被注入的 A app 让 B app 干坏事
  3. 权限混淆:user 不清楚一个动作背后是哪个 app 真的执行
  4. 责任不明:出事后难以归因到具体 app

许多 agent 框架或 plugin 平台在默认示例中倾向于共享 conversation history、tool list 或 memory。这是 ToLO 在多 app 场景需要重点审查的地带。

IsolateGPT 重新设计架构。

方法摘要

据论文,hub-and-spoke 架构:

                  ┌────────────────┐
                  │   Trusted Hub   │
                  │  (路由 / 权限 / │
                  │   user consent) │
                  └───────┬─────────┘
                          │ ISC 协议
        ┌─────────────────┼─────────────────┐
        │                 │                 │
   ┌────▼────┐       ┌───▼────┐       ┌───▼────┐
   │ Spoke A │       │ Spoke B │       │ Spoke C │
   │ (App-A) │       │ (App-B) │       │ (App-C) │
   │  LLM    │       │  LLM    │       │  LLM    │
   │  Memory │       │  Memory │       │  Memory │
   │  Tools  │       │  Tools  │       │  Tools  │
   └─────────┘       └─────────┘       └─────────┘
   (Process     (Process       (Process
    isolation)   isolation)     isolation)

Hub 职责

  • 可信接口(user-facing)
  • 请求路由(决定调哪个 spoke)
  • 权限管理(spoke 间不能跨权)
  • spoke 管理(启动 / 停止 / 监控 spoke)
  • 系统级记忆(跨 spoke 共享的少量元数据)

Spoke 设计

每个第三方 app 在隔离 spoke 中运行:

  • Dedicated LLM(spoke 内 LLM 独立)
  • Dedicated memory(spoke 内 memory 独立)
  • Process isolation(基于 OS 进程隔离实现)

ISC 协议

Inter-Spoke Communication(ISC) 必须经 hub 转发:

  • 定义好的 request/response format
  • 关键步骤请求 user consent(高敏感动作需要 user 点同意)
  • hub 校验 spoke 权限后才转发

实现

  • 基于 LangChain 与 LlamaIndex 改造
  • Process isolation 提供隔离机制

与 ToLO 的关联

IsolateGPT 是 C_SAFE^{capability} 的设计参考:它不把 S_LLM 当作全局可信协调器,而是在工具边界与执行边界处引入非 LLM 控制面。

每个 spoke 拥有独立 LLM 与 memory,跨 spoke communication 必须经 hub 路由,并在关键步骤请求 user consent。这类 capability gating 不对应单一 ToLO 子类,但可降低 ToLO-{Exec,Shell,SQL,Path,SSRF,Template} 等 sink 前的越权传播风险。

对七子类的具体作用

子类IsolateGPT 怎么帮
ToLO-Execspoke 内 exec 不能影响 hub 或其他 spoke
ToLO-Shell同上
ToLO-Pathspoke 文件系统 chroot,跨 spoke 读取被 hub 拒绝
ToLO-SSRFspoke 网络限制由 hub 策略决定
ToLO-SQLspoke 内数据库连接由 hub 配置(可读 only / minimal perms)
ToLO-Deserspoke 内反序列化结果不能跨 spoke 传
ToLO-Templatespoke 内模板渲染不能影响其他 spoke

为什么这对 ToLO 重要

IsolateGPT 让 C_SAFE^{capability} 从”代码里有一个检查函数”升级为系统架构约束。ToLO 的很多 sink 风险来自 LLM 输出被赋予过大的 ambient authority:同一个 agent 既能读全部 memory,又能调用全部 tools,还共享同一个执行上下文。Hub-and-spoke 把这些隐式权限拆开,使污染数据即使进入某个 spoke,也难以跨 app 扩散。

它尤其适合解释 C4 工具边界:第三方工具或 MCP server 即便返回恶意内容,也应只影响所属 spoke 的受限能力集合,不能直接驱动其他 app 的工具或读取 hub 的系统级 memory。

实验与结论要点

据论文,作者将 IsolateGPT 与 VanillaGPT 对比,评估:

  • adversary 改变其他 app 行为:被攻击 spoke 不能干扰其他 spoke
  • 窃取其他 app 或系统数据:跨 app 数据隔离
  • 自然语言歧义导致的误暴露或行为改变:hub 的明确路由减少歧义

据论文,功能与性能评估使用 LangChain benchmarks;所有 benchmark 功能与 VanillaGPT 相同,75.73% tested queries 的 overhead under 30%。该数字仍按 pending 处理。

局限与开放问题

  • hub 自身成为可信计算基(TCB),策略错误会影响整体安全。
  • process isolation 与 user consent 的真实产品成本仍需进一步量化。
  • app 开发者必须改造代码适应 IsolateGPT 架构 —— 现有 LangChain 应用不能”零成本迁移”。
  • 对单 app 内的 ToLO(一个 LangChain agent 自己有 path traversal)不直接帮助 —— IsolateGPT 关注跨 app 边界。
  • 它不替代单个 spoke 内部的 schema、allowlist、safe-codec 或参数化调用;spoke 内仍可能存在 ToLO-SQL、ToLO-Path 等普通源码级缺陷。

对本站的启发

该论文支持本站把 C_SAFE^{capability} 单列为 sanitizer 类:有效防御不只是在 LLM 输出后做字符串校验,还要把 app capability、memory、tool access 与跨域通信纳入运行时控制。

无需扩展 ToLO 七子类;更适合在 Defensive Patterns 作为 capability sanitizer 的正面案例引用。

对静态分析的具体启发

CodeQL 检测 C_SAFE^{capability} 时,可以识别以下 IsolateGPT 风格 pattern:

  • spoke 启动函数(如 spoke = HubClient.start_spoke(...))
  • ISC 调用(如 hub.route(target_spoke, request))
  • user consent 调用(如 await hub.request_user_consent(...))

这些都可作为 capability barrier 的标志。

ToLO 一行标注

- / - / - / C_SAFE^{capability} / 工具+执行边界 (跨 app)

阅读顺序

建议在 CaMeL 之后读本文。CaMeL 更适合单 agent 内的数据/控制流隔离,IsolateGPT 更适合多 app、多 plugin、多 MCP server 的平台场景。若关注攻击入口,可回读 ToolHijacker。

读完检查

  • IsolateGPT 和 CaMeL 主要差别?
    • IsolateGPT 偏 架构 / 运行时隔离(进程 + hub);CaMeL 偏 静态策略 + 数据 capability 标签。
  • 单一 agent 应用(一个 LangChain 实例)用 IsolateGPT 直接有意义吗?
    • 没有直接意义。IsolateGPT 解决多 app 共存场景。单 agent 应用应当用 CaMeL 或类似设计。
  • MCP 生态可以从 IsolateGPT 学到什么?
    • 很多。MCP 本质上是”多 third-party server 共存”。如果 MCP host(如 Claude Desktop)按 IsolateGPT 思路实现,可以大幅降低 C4(MCP server 响应控制)的影响面。

外部链接

内部互链