系统视角下的 AI Agent 隔离模型与安全边界

"AI agent" 在产品语境下已被广泛使用，但同一个名字下面的工程实现并不一样。本文从一次完整请求的执行路径切入，针对每个具体产品考察三个基础问题：代码在何处执行 · agent 控制循环在何处运行 · 凭证保存在哪里。

举两个对照例子。Perplexity Pro 处理数据分析请求时，后端把 LLM 生成的 Python 下发到 e2b 启动的 Firecracker microVM 内执行，用户文件、代码、运行结果隔离在其中，session 结束就销毁 [1]。Claude Code 在本地终端执行 claude 命令时，模型推理在 Anthropic 云端完成，工具调用全部在本地 claude 进程内以登录用户 UID 执行，默认不启用 OS sandbox，安全由进程内的 permission 系统承担 [2]。

两者都被叫作"AI agent"，但在上述三个问题上的回答完全不同。本文调研了 7 款常见的 agent 产品，逐一回答这三个问题，再从答案中归纳出共通的差异维度。

七款产品介绍

Perplexity Pro（数据分析）。后端把 LLM 生成的 Python 下发到 e2b 启动的 Firecracker microVM 内执行，每月在 e2b 平台启动数百万个此类 sandbox [1]。agent 控制循环留在 Perplexity 后端；OAuth 凭证不进 sandbox，需要连接器时由后端代理调用；session 结束 VM 销毁。agent 与 LLM 生成的代码不共享信任域。

Manus（端到端任务）。每个 Manus 任务获得一台 microVM 形态的完整 Linux 环境（第三方拆解称底层接近 e2b / Firecracker [9]），内含 Node、Python、headless Chromium、终端、文件系统，以及预装的约 27 个工具。任务工作状态、工具执行与 agent 行为决策驻留在同一 VM 内。这给了 agent "本地虚拟员工"般的工程便利，代价是把一切都装进同一个信任域：Chromium 一旦加载攻击者构造的恶意网页，prompt injection 攻击的直接目标就是 agent 自身的决策，sandbox 反而位于攻击者的身后。Manus 的强隔离防的是横向移动（用户 A 的 VM 影响不了用户 B），而不是纵向劫持（同一个用户的 agent 被诱导执行恶意指令）。

Claude Code 默认配置（本地终端）。模型推理在 Anthropic 云端，工具调用全部在本地 claude 进程内以登录用户 UID 执行 [2]。默认不启用 OS sandbox，安全由进程内的 permission 系统承担。Anthropic 在 2025-10 开源了一个可选的 sandbox-runtime 工具，启用后会把 Bash 子进程包进 macOS Seatbelt 或 Linux bubblewrap [10]，但默认关闭。Ona 团队公开演示过这种模式的脆弱性：诱导 Claude Code 通过 /proc/self/root/usr/bin/npx 绕过自身的命令 denylist；进一步当 sandbox 检测到绕过并拦截后，agent 自主执行了一条 disable sandbox 指令，随后重新执行原命令并成功 [11]。这一失败模式比 Manus 更严重，因为没有 microVM 提供的 OS 级横向隔离兜底。

ChatGPT Code Interpreter（数据分析）。生成的 Python 路由到 OpenAI 后端的 sandboxed、firewalled Python 执行环境，社区推断底层为 gVisor pod [5][6]。结构上与 Perplexity 同档（不共享信任域、每请求即时），区别在于该环境通常不具备任意公网出站，威胁模型更保守。

Bolt.new（应用生成）。把 Node 运行时通过 WebContainers 装进浏览器内执行，sandbox 跑在用户的浏览器标签页里 [8]。云端无需承担 vCPU 成本，代价是兼容性，依赖 fork() 或原生扩展的 Node 代码无法运行。

Codex CLI（本地终端）。与 Claude Code 几乎相同的本地 CLI 形态，但默认开启 OS 级子进程隔离（macOS Seatbelt、Linux bwrap + seccomp），并提供 read-only / workspace-write / danger-full-access 三档 sandbox 模式与 approval policy [19]。Codex 是 Claude Code 在 sandbox 默认开关上的镜像选择。

Cursor（IDE 编辑器）。本地交互模式（IDE 内编辑 + 终端）历史上无 OS sandbox，2026-02 起在 supported platforms 部分启用（Seatbelt / Landlock+seccomp / WSL2）[12]；并行 / 后台模式则在每个 task 用一台独立的后端 VM（第三方材料称接近 Firecracker microVM 形态），agent 控制循环留在 Cursor 服务端。同一款产品在两种使用模式下采用截然不同的隔离强度。

把 7 款产品的差异整合成一张定位表：

三个对比维度与一个共同的安全盲区

表里的三列对应三个贯穿性的对比维度。

隔离强度。从弱到强分布在"同 UID 同进程 → OS 级子进程隔离 → 浏览器 origin → gVisor → VM / microVM"五档。两端在技术上到 2018 年前后就已基本成熟，e2b / Modal 等公开可比的 CPU sandbox 服务价格已经趋同。

agent 控制循环是否与代码执行共享信任域。Perplexity、Bolt.new、Cursor 并行模式属"不共享"路径，sandbox 关的是 LLM 生成的代码；Manus、Claude Code 默认配置属"共享"路径，agent 行为决策与执行代码同处一个信任域；Codex CLI 与启用 sandbox-runtime 后的 Claude Code 属"边界跨越"中间档。这条轴决定了 prompt injection 攻击落在哪里。

sandbox 生命周期。每请求即时、每任务可休眠、本地持久三种。生命周期直接决定计费形态：API 按请求 / session·hour（Anthropic Managed Agents 的 $0.08 / session·小时、idle 免费 [14]）/ 月度订阅 + credits + usage-based billing（Replit AI 的 effort-based 计费按 agent 实际消耗计量 [22]）。

三个维度之上，所有产品共享一个共同的安全盲区。

经典 sandbox 解决的是"代码可能恶意或有缺陷"这一问题，Firecracker / gVisor / V8 isolate 到 2018 年前后已经基本就绪。AI agent 则引入了 sandbox 设计阶段未明确考虑的新威胁：LLM 自身的决策可能被 prompt injection 劫持。被攻击的对象不是 sandbox 内部的代码，而是位于 sandbox 边界上的 agent 控制循环本身。

研究者 Simon Willison 将这一攻击模式概括为 lethal trifecta：当一个 agent 系统同时具备访问私有数据、接触不可信内容、对外发起请求这三种能力时，系统会进入极高风险状态，传统 prompt-level 防护很难可靠阻断数据外泄 [15]。本文样本里的多数产品一旦启用连接器、浏览器或网络工具，就会进入这一风险区。Manus 加载恶意网页即触发、Claude Code 通过第三方 Skill 引入的指令注入，都是同一模式的具体变体。

几家厂商正在尝试填补这一缺口。把各家的应对方向归类，可以提炼出四种局部 solution（不是完备的安全分类，而是本文样本里反复出现的四类工程取舍）：

四类相对独立，工程上可叠加。Vercel 的设计同时落在"架构分离 + 凭证隔离"两类；Anthropic 的 sandbox-runtime 同时落在"出口控制 + 决策门控"两类。在本文考察的公开材料中，尚未看到一家把四类能力以统一产品形态完整暴露出来。

更高一层的"跨产品统一治理"则完全空着。每款 agent 产品都自行定义 policy 格式、自行维护 audit 日志；开发者同时用 Claude Code、Cursor、Aider 时，要分别配置三套 policy、分别查看三份 audit log。模型厂商的利益边界天然把他们限制在自家产品内，这一空白更可能由第三方、开源标准或企业治理层先行填补。

结语

我们认为，下一阶段的竞争焦点不再是"单点隔离原语谁更强"，因为 Firecracker / gVisor / V8 isolate 这类基础设施已经成熟。竞争会转向更结构性的议题：agent 控制循环是否应与代码执行共享信任域的设计分歧、多组件下的出口控制、跨产品的统一 policy 与 audit 标准。