IsolateGPT 执行隔离架构
一句话
据论文,IsolateGPT 用 hub-and-spoke 架构把第三方 LLM app 的模型、记忆和执行上下文隔离开,再由可信 hub 做路由、权限和跨 app 协作控制。
为什么读这篇
IsolateGPT 是 NDSS 2025 提出的 agentic systems 执行隔离架构 —— 直接对应本站 C_SAFE^capability 的实际工程实现。
它和 CaMeL 都属于”capability 系列”防御,但视角不同:
- CaMeL: 单个 agent 内,控制流-数据流分离 + capability 标签
- IsolateGPT: 多个 third-party agent 共存,进程级隔离 + hub 路由
读完它,你会理解 ToLO 防御里”capability”不只是 sanitizer 函数,而是架构层概念。
核心贡献
- 提出 agent app 执行隔离架构
- 用 hub 统一管理权限与路由
- 用 ISC(Inter-Spoke Communication)协议 约束跨 app 协作
它解决的问题
当 LLM 平台支持第三方 plugin / agent app(类似 ChatGPT plugin store、Claude MCP 生态),会出现:
- 跨 app 数据泄露:A app 处理的隐私数据被 B app 偷走
- 跨 app 行为劫持:被注入的 A app 让 B app 干坏事
- 权限混淆:user 不清楚一个动作背后是哪个 app 真的执行
- 责任不明:出事后难以归因到具体 app
主流 agent 框架(LangChain、LlamaIndex、ChatGPT Plugins)默认共享上下文:所有 plugin 看同一个 conversation history,所有 tool 调用走同一个 LLM。这是 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-Exec | spoke 内 exec 不能影响 hub 或其他 spoke |
ToLO-Shell | 同上 |
ToLO-Path | spoke 文件系统 chroot,跨 spoke 读取被 hub 拒绝 |
ToLO-SSRF | spoke 网络限制由 hub 策略决定 |
ToLO-SQL | spoke 内数据库连接由 hub 配置(可读 only / minimal perms) |
ToLO-Deser | spoke 内反序列化结果不能跨 spoke 传 |
ToLO-Template | spoke 内模板渲染不能影响其他 spoke |
实验与结论要点
据论文,作者将 IsolateGPT 与 VanillaGPT 对比,评估:
- adversary 改变其他 app 行为:被攻击 spoke 不能干扰其他 spoke
- 窃取其他 app 或系统数据:跨 app 数据隔离
- 自然语言歧义导致的误暴露或行为改变:hub 的明确路由减少歧义
功能与性能评估使用 LangChain benchmarks;所有 benchmark 功能与 VanillaGPT 相同,75.73% tested queries 的 overhead under 30%(可接受性能代价)。
局限与开放问题
- hub 自身成为可信计算基(TCB),策略错误会影响整体安全。
- process isolation 与 user consent 的真实产品成本仍需进一步量化。
- app 开发者必须改造代码适应 IsolateGPT 架构 —— 现有 LangChain 应用不能”零成本迁移”。
- 对单 app 内的 ToLO(一个 LangChain agent 自己有 path traversal)不直接帮助 —— IsolateGPT 关注跨 app 边界。
对本站的启发
该论文支持本站把 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)读完检查
- 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 响应控制)的影响面。
外部链接
- 论文:https://www.ndss-symposium.org/ndss-paper/isolategpt-an-execution-isolation-architecture-for-llm-based-agentic-systems/
- 代码 / 数据集:https://github.com/llm-platform-security/SecGPT/tree/IsolateGPT-AE
- 作者主页: