LLM Agent Sandboxing
从运行时隔离，到自主行动边界

分析任何产品时，先问它位于哪一层。Firecracker 是精简 VMM，不会单独提供任务路由与凭据策略；Kubernetes Agent Sandbox 是会话资源的 orchestrator，低层隔离通过 RuntimeClass 委托；OpenSandbox 提供统一 API，却可以对接不同后端。给 API 加上“sandbox”名称，并不使 Docker 后端自动拥有 guest kernel。Firecracker · Agent Sandbox · OpenSandbox architecture

这个对照是机制归纳，不表示 CI、远程 IDE、serverless 或 notebook 从未处理这些问题。agent 的变化在于把多个既有系统问题压进同一个自主、长期、可受不可信观察影响的循环。你应分别考察隔离、授权、恢复和完成率，而不是寻找一个替代容器的单一标准。

一个有用的威胁模型 不是“把 guest 设成非 root 就安全了”。有的产品故意允许 guest 使用 sudo 或 Docker，因为外层 VM 负责宿主隔离；有的 runtime 则依赖 guest 内的权限分隔。当你把 VM 内不同 agent 当成不同租户时，必须重新确认 Linux DAC、capabilities、local API 与共享文件到底能否构成所需边界。

你可以把“必须运行 Docker-in-Docker”视为具体 workload requirement，再选能在 guest 内承载 container runtime 的实现。但不要把宿主 Docker socket 挂入 guest 来解决兼容性：那往往是把创建宿主容器与挂宿主文件系统的 authority 直接交给不可信程序。Docker Sandboxes 的独立 guest Engine 正好解释了另一条路径。Docker isolation layers

这里有三个独立命题：secret 不可读取、authority 不可任意使用、不可信数据不可自行决定敏感动作。external credential injection 主要解决第一个；资源与 action policy 解决第二个；control/data separation 与信息流约束尝试解决第三个。它们可以组合，但不应互相冒名。OpenAI Vault · CaMeL

从域名到实际目的地，再到业务对象

即使你把策略收敛到 hostname，也必须处理 DNS、IP literal、redirect、SNI/Host 一致性与真实 dial address。guest 自填的 SNI 只是一段输入，不是目的地证明；“允许 example.com”不应让它把同名标签贴到内网 metadata IP 上。再上一层，真正的 example.com 服务本身也可能提供写入、上传、转发和反射功能。

普通 NetworkPolicy 属于 L4；HTTP method、URL path、repository、recipient 等语义需要 L7 proxy 或工具 reference monitor。允许包仓库仅是网络收敛，安装脚本仍可读当前挂载工作区。应减少 setup 时可见数据、预制可信基底，并把动态安装当成一项有来源与权限范围的能力请求。NetworkPolicy · OpenSandbox Vault

E2B 当前 runtime 公开 memory、disk 和 machine-state 模板与 live fork；Vercel current persistence 明确是 filesystem snapshot 后启动新的 session。Cloudflare 的 name/DO 与 Linux instance 又有独立生命周期。不能从一个产品的 `resume()` 类比另一个产品的状态承诺。E2B Runtime · Vercel persistence · Cloudflare lifetime

快照加速与安全恢复需要不同工程机制

保存机器让初始化和依赖工作得到复用；它也会复制机器认为“独一份”的状态。Firecracker 文档指出快照重复恢复会复制随机状态与标识；VMGenID 可让 kernel PRNG 重新播种，但用户态缓存、应用 ID 和 token 仍需集成方处理。这说明 hypervisor 的正确恢复并不等价于产品身份的正确恢复。Firecracker snapshot support

可以把恢复看成一次新的 admission：校验 caller 对 snapshot 的权限，验证版本与完整性，在网络受限状态启动，更新 execution generation 与连接 capability，重建时间、熵和网络，再由外部 broker 按当前 policy 绑定短期能力。resume 可以保留同一 logical sandbox identity，例如 E2B 的暂停恢复；fork 则应独立 branch identity 并重新授权。完成这些动作之后，才能放开受控 I/O。若直接从旧快照开始出网，权限轮换与新策略可能赶不上第一条旧进程请求。

等待一小时后继续，为什么不是简单保持 Pod

模型推理、人类审批和网络断线都使任务出现大量等待。持续运行实例保留后台 server，却消费驻留内存；停止实例保存磁盘节省资源，却需要 job restartability；保存完整机器状态增加恢复能力，却引入权限与唯一性检查。选择取决于任务需要，不应把一种状态能力当作全产品默认。

审批还应该绑定 action digest、资源对象、policy revision 和有效期。假设 agent 在批准前改了目标仓库，或快照恢复后采用新凭据，旧“允许”不应自动授权新动作。审批是外部可信状态，不能只靠 guest 文件中的 `approved=true` 恢复。取消同样需要 lease/token/preview/PTY/volume/snapshot 各自回收，不是删一个 Pod 就结束。

分叉是搜索原语，也是事务问题

三个 agent 从相同文件状态尝试不同修复，可以提高探索吞吐。若它们共用同一个 Git branch、数据库或者 webhook，则“独立 VM”不等于“独立世界”。分支需要独立 staging、外部动作 ledger 与 commit gate；否则重复提交和竞态可能掩盖你正在比较哪个候选方案。回滚文件后重试一次 API，也可能重复外部 side effect。

一个可审计实验应记录 parent snapshot、branch、runtime、policy、workspace version、credential binding 和每个外部 request 的 idempotency key。将这个谱系与 artifact hash 关联，才能解释最终 patch 来自哪条探索路线，以及为何一次候选失败没有对生产世界留下副作用。

三种值得拆开画的开源架构

Fast Sandbox 提供一个更具挑战的设计：warm Pod 中运行多个 sandbox instance。它绕开每个环境从 scheduler 到 kubelet 的创建链，但 Pod 级 NetworkPolicy 只看见合并出口，必须让网络策略重新识别实际 sandbox subject。容量复用时又需要 generation fencing，让旧请求不会路由到新租户。这是以更高密度换取更复杂显式安全语义，而不是“一个 Pod 多跑些程序”。integration contract · egress profiles

真实公告把审计位置拉回 host TCB

公开漏洞数量不是成熟度分数：它受研究关注度、版本跨度、披露文化和攻击面影响。更有价值的是受影响路径、修复版本、可复现测试、downstream pin 与 hardening 默认值。一个“零公告”的托管平台也不能据此推断逃逸概率为零。

Docker Sandboxes：把高 guest 权限留在低 host 权限之外

本地产品用每 sandbox microVM 与独立 Docker Engine，agent 可以在 guest 内 build/Compose，不需要共享宿主 Docker socket。workspace 的直接挂载、私有 clone 和 mountless 模式表达不同文件授权；默认共享 cwd 仍把隐藏文件和 repo 配置交给环境。microVM 保护不了你主动分享进来的内容。isolation · defaults

其 stdio MCP server 在 host，经 gateway 被 guest agent 调用；这条工具路径仍可拥有宿主 Docker 或本地文件权限。local/cloud 的 credential store、network policy 和 lifetime 分开，不能因为 CLI 同名便认为迁移自动保持策略。Docker/Moby 开源背景也不足以证明当前 sbx 产品的全控制平面源码均可审计。MCP gateway · local/cloud comparison

把 Linux 执行边界接入持续的 agent 权限治理

OpenShell 提供了一个很直接的“容器经验如何延伸到 agent”的案例：隔离底座仍由 compute driver 建立，gateway 负责生命周期与策略，边界外的 supervisor 负责逐请求网络中介和真实凭据。它不是 agent harness，也不是一种固定的 VMM。Docker、Podman、Kubernetes 和 VM 路径共享治理契约，却有不同的 host boundary；把它一律称为容器 sandbox 或一律称为 microVM，都会遗漏实际机制。产品定位 · compute drivers

拓扑与 driver 契约来源：Architecture、Sandbox Runtimes。隔离成立仍依赖 Linux/虚拟化、driver、网络后端、可信 supervisor 及其代理实现；公开策略文本本身不是这些组件正确运行的证明。

一条 HTTPS 请求，至少有两道不同授权

网络允许 host 不意味着允许向它注入所有 provider secret；connection/request policy 与 credential endpoint binding 必须同时通过。反过来，凭据不向 agent 披露，只保护经此机制托管的值；workspace 内客户数据、cookie、服务返回的敏感内容仍可被读到。provider profile 又可能增加 effective policy 的规则，所以只读用户 base YAML 看不到全部 authority；global override 也会改变组合方式。Providers · Profiles / composition

REST request inspection 可约束 method/path/query；GraphQL、MCP 等也有运行时协议规则。但 endpoint 默认的 audit 会记录违反请求规则而放行，enforce 才会真正阻止。tcp 或未设置请求协议时没有同等的 L7 操作约束。即使配置 HTTP read-only preset，也只描述 HTTP method，不保证某个服务的 GET 实际没有副作用。request checks / enforcement

代码修复例：同时检查操作、对象与输出数据

下面是解释性规则，不是可执行配置或完整产品 policy。假设 task 只准修改 repo-a 的 docs，受信操作者检查了所有 provider 叠加规则，并设置 L7 enforce：

对云原生安全研究者，OpenShell 的增量在于把进程 confinement、协议中介、秘密不披露、动态策略申请与策略集合证明接进同一条控制链。它与 E2B 的机器状态生命周期、FastSandbox 的高密度执行 plane、Kubernetes Agent Sandbox 的会话资源编排形成不同研究切面。可以进一步检查 supervisor/driver TCB、有效策略与执行事实的一致性、TOFU/祖先 executable 权限、规则撤销、连接世代，以及模型之外的数据流控制。

选型时先写 workload contract

例如“需要 Chromium、Node、Git，持续三小时，等待时可恢复，允许私有 npm 与一个 repo branch，产物能给用户下载”。这个描述比“我要最安全、启动最快的 sandbox”更可操作。再核后端、镜像、区域、网络、user mapping、snapshot scope、SDK 和 cancellation，最后测到 browser 可导航的真实 ready time。成本也按每个成功任务的资源时间积分看，而不只看 VM 创建单价。

设备和工具兼容性不是附带因素：GPU、FUSE、nested containers、network client、package manager、JVM remote cache 和 native browser 可能触发不同 runtime 路径与例外。每个例外应解释新增 authority，不应为了成功跑通 demo 把所有 host IPC/网络重新打开。

agent 也会攻击评测与工具控制面

论文记录读取 tool proxy 日志、伪造 RPC 取答案、覆盖 /bin/bash、借 ioctl 绕工具控制、无限输出耗尽存储等行为。由此看，verifier、答案、日志和工具 socket 不是普通任务文件；它们支撑训练与测量正确性，必须处于 task authority 之外。作者的 AppArmor、按任务 eBPF allowlist 是局部缓解，并未声称一般 kernel bug 防御。DSec §6.4–6.5

对工程师来说，最可迁移的思路是把 environment identity 与 evaluation identity 分开：agent 可以修改它的程序，却不能修改“判断它是否完成任务”的 supervisor。trace 来源与最终 checker 也应在外部。否则得到高任务通过率，可能只是 agent 学会控制你用来打分的部件。

控制流看起来正常，数据流也可能已经变坏

以“把会议里 Bob 要的文档发给 Bob”为例。会议记录被攻击者编辑，parser 提取出的 recipient 可能变成 attacker@example，同时文档仍是 confidential.pdf。工具顺序没有改变：读取会议、找文档、发送邮件。仅约束顺序的 planner 仍可能产生危险参数；需要在 send boundary 检查受众与数据出处。

CaMeL 的 privileged planner 只看 trusted 用户任务与 tool definitions，不接受实际 tool observations；quarantined parser 没有 tool permission，解释器维护值来源、readers 与执行 policy。这提供一种从 prompt 防御转向程序执行语义的路线。合法的新分享则需要明确 declassification；不能把一切不可信数据都禁止使用，否则任务也无法完成。CaMeL v2

对熟悉 RBAC 的读者，可以把区别理解为：RBAC 回答 principal 是否能调用 send_email；对象 policy 回答可以发给谁；information flow 进一步回答这份 document 是否可流向 recipient，以及谁有权改变这个决定。由用户真实授权改变共享范围，与网页文本自称“用户已授权”，必须经过不同可信路径。

重点文献与证据状态

如何读漂亮的 ASR / utility 数字

先固定模型、任务、攻击预算、攻击者可修改位置、defense 信息、工具实现与失败定义，再看数字。CaMeL v2 的摘要 utility 是作者 AgentDojo 配置下 77%，未防御 84%；不能混入 v1 67%，也不能把差值归因于一种通用 runtime 开销。PFI 把警告用户视为攻击失败；现实用户若疲劳批准，安全结果可能不同。这些限制不是否定研究，而是决定结果可以迁移到哪里。

自适应攻击评测意味着攻击者了解你的防御并针对它搜索；仅用固定 injection template 验证一次不足以证明 robust。The Attacker Moves Second 也明确其自身 protocol 与排除项，尤其没评 CaMeL 等 plan-then-execute。严肃比较应建立共同实验协议，而不是把来自不同 threat model 的百分比放在雷达图上。

一个可用 end-to-end 评估至少并列报告：合法任务完成、非法业务动作、secret 泄露、host/tenant boundary、memory poisoning、资源 DoS 与成本。不同后端上 prompt injection 的业务越权可能完全相同；只有加上 object policy 或 flow enforcement 后才改变。这个结果会精确说明 runtime 的收益边界，比“更强 VM 让 agent 更安全”更有信息量。

政策伪代码：对象与动作在模型之外检查

以下为说明性伪代码，不是可执行配置，也不是某个 SDK 的真实 schema。

capability = {
  principal: tenant/user/task,
  resource: github/org/repo-a,
  branch: agent/task-123,
  operations: [read, push_patch, create_pull_request],
  expires: task_lease_end,
  policy_revision: 8
}

authorize(tool_call, execution):
  require authenticated(execution.connection)
  require binding(task, sandbox_uid, execution_generation)
  require canonical_resource(tool_call) == capability.resource
  require tool_call.operation in capability.operations
  require destination == trusted_resolve(allowed_host)
  require payload_data_class allowed_by task_policy
  require current_policy_revision == capability.policy_revision
  require unconsumed_approval_if_sensitive(action_digest)
  append_external_audit(decision, canonical_action)
  broker_inject_short_lived_credential()

Canonical resource 不应直接相信 guest 传来的 repo 字符串。request path、URL 编码、重复 header、redirect、Host/SNI 与实际 IP 都要一致处理。对象 canonicalization 与 identity routing 是不同检查，二者缺一都可能在正常 API 流程中越权。审批也应与最终 canonical action 绑定，而非只批准一段容易改变的自然语言解释。

Kubernetes 资源抽象不代替租户授权

Agent Sandbox 的 threat model 区分 Template 路径与裸 Sandbox 的默认值；Router 的 default AllowAll 不等于已完成公网多租户认证。即使 RBAC 限制 Claim 创建，还要检查 connect/file/exec/snapshot API 对对应 UID 的 ownership。v1.0.6 scoped-token v2 修复的是实际 resolved Sandbox UID 与 token 的一致性，同名重建不应承接旧 token。threat model · release

WarmPool refill、events 与 user adoption 争抢 API Server 时，局部优化 VM restore 不足以解决尾延迟。APF 可以给 latency-critical 路径与 bulk background 工作不同队列；配合 batch/rate/refill 控制，防一个租户的大量创建拖慢其他租户。这里的安全可用性与性能公平性是同一个 control-plane 问题。APF insulation

产物是跨边界数据，不会自动可信

生成 HTML、SVG、终端输出、下载文档、测试报告与 PR patch 可以包含脚本、外部请求、控制序列或新的执行配置。预览 renderer 应限制 script/navigation；terminal viewer 要处理 escape；patch review 应注意 CI workflow、hooks、build scripts 与依赖变更。不能因为产物来自“安全 sandbox”就让它在用户 host 上获得新的权限。

审计链要同时连接模型决定、工具 policy、执行结果、外部副作用与产物版本。一份 stdout 可以被任务程序伪造，host audit 也未必知道模型目的；因此需要可信 execution facts 与明确 policy，而非以一个日志层自动推断用户意图。Wasmtime 输出安全讨论

模型的用途是暴露假设，不是代替 load test

池覆盖一次 burst 时，你仍要问后台多久补齐、不同 template 有多少份、claim customization 是否迫使 cold create，以及 refill 与 foreground 请求是否共用队列。单一总池容量掩盖 shape mismatch：池里有 100 个 Python 环境，对需要 Chromium/Node/私有依赖的任务也可能没有一个可领取。

真实系统的 cold path 又包括 scheduler、镜像/快照读取、缺页、guest agent、browser/app 启动和网络验证。将“API 返回 ID”“VM restored”“first command succeeds”作为相同 ready time，会让性能图失去意义。预热实例若已经完成这些步骤，它的快速领取只是把费用和准备时间前移，而非消灭成本。

等待推理时 CPU 不计费或很空闲，并不意味着内存、磁盘、快照、IP 与 control-plane 对象免费。应记录每个成功任务的 resource-time 与 failure/retry；比较 reclaim 与常驻策略时还要看重新读取 cold working set 的代价。这个合成计算器因此只提供最小算术关系，不能输出“最佳厂商”。

一个小而完整的实践计划

先建立两条固定版本的路径：本地 VM 工作台，用于比较 workspace sharing、Docker 与 host MCP；K8s 路径，明确 RuntimeClass、Template、Claim 和 WarmPool。先不要同时改 agent model 和所有 backend，否则失败来源无法归因。选择一个能在二者完成的 coding 任务，记录从 create 到 target app 可用的时间。

然后只改变权限层：普通出站→domain allowlist→secret 外置→repo/branch/method policy→带来源的数据流检查。每步都跑合法任务和同一个恶意 observation，用最终 side effect 判定，而非只看模型有没有说“我拒绝”。如果合法 utility 下降，记录原因是兼容性、policy 太窄还是依赖准备缺失。

第三阶段测试状态：idle 后恢复、fork 三分支、policy 升级、token 撤销、节点失效、取消。核文件与 process 的恢复，再核 authority、browser identity、外部提交与 preview 入口。这个顺序能把你熟悉的 snapshot 技术与 agent 权限语义接起来，而不迷失在品牌比较。

以上是分析性研究建议，未宣称 novelty 或已完成实验。下一步应对具体问题做更窄 prior-art 检索，写清 threat model 与 falsifiable hypothesis，再决定是否值得投入。一个有价值结果也可以是“某个强 runtime 并未改变这一类业务滥用”，只要实验把原因和控制边界解释清楚。

Sandbox boundary

被技术强制限制的资源与行为范围；应指出 enforcement 位置，不能只写品牌名。

TCB / Trusted Computing Base

安全结论依赖的可信组件集合：runtime、host kernel、broker、router、storage 与 policy interpreter 都可能在内。

Harness

运行模型与工具循环、管理会话和恢复的逻辑；执行环境可以由另一个 provider 供给。

Authority / Capability

完成某种动作的实际权限。token 值隐藏并不表示其可用操作范围已受限。

Reference monitor

在动作发生处进行完全中介的受信组件；检查对象、操作、参数、身份和数据 policy。

Egress policy

控制向外发什么、去哪与如何认证。L4 reachability、host allowlist、L7 action policy 是不同层。

Logical sandbox / generation

长期环境身份与一次运行实例的世代。resume 可保留前者；过期连接必须被后者 fencing。

Template / task snapshot

可共享通用基底与包含任务私有状态的捕获；权限、保留与污染风险不同。

Control / data separation

让不可信 observation 不获得指令 authority；值标签和 policy 仍要允许合法任务使用数据。

Utility / ASR

正常任务效用与攻击成功率；二者依赖共同实验 protocol，不能当跨厂商独立安全分数。

Reproducible task environment

为试验提供固定初始状态与 verifier；不等于已经评测 host escape resistance。

External side effect

环境外已发生的真实操作，如 push、发信、扣款；本地 snapshot 无法把它自动回滚。

本文件完整离线可读，图示与交互不调用网络。点击原始资料链接才会打开外部页面。支持键盘、窄屏与打印；禁用 JavaScript 时，正文、图示、项目和论文仍可阅读。