AI Security

外观

AI 应用与智能体系统安全 · A5.5 Agent Runtime、Sandbox 与 Workspace更新 2026-09-10约 20 分钟证据：强 来源：多来源研究综述

Agent 沙箱架构与逃逸研究综述 ​

摘要 ​

Agent 沙箱的真实安全边界由隔离原语、策略配置和沙箱到宿主的信任交接共同决定。公开案例显示，许多"沙箱逃逸"并未击穿内核隔离，而是利用命令批准、符号链接、配置 Hook、宿主可信进程或产物导入链。产品比较必须区分已验证技术、厂商声明和公开证据不足。

证据等级说明（沿用 pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 的约定）：强 表示有 CVE 编号、官方安全公告或可复现的第三方研究支撑；中 表示只有厂商产品页/博客描述、无独立验证；未披露 表示公开资料未找到足够技术细节，不代表该产品一定没有对应能力或该风险一定不存在。

分类介绍 ​

本领域覆盖容器、用户态内核、microVM、WASM、TEE 等隔离原语，以及托管服务、自托管运行时和编码 Agent 内置沙箱的产品化封装。市面上不存在单一"最安全"的 Agent 沙箱：产品的安全边界几乎完全由它选用的底层隔离原语决定，产品层的营销语言（"hardware-level isolation"）需要对照底层技术还原。2025–2026 年最重要的转变是：真正能突破沙箱的漏洞已很少直接击穿隔离边界，绝大多数实战可复现的"逃逸"发生在沙箱到宿主的信任交接（命令白名单、符号链接处理、配置 Hook），而不是内核态；沙箱本身的编排能力（快速拉起/销毁、批量并发）攻击者可将其征用为攻击基础设施，而不只是需要被逃逸的边界。

材料范围与选择方法 ​

本综述覆盖底层隔离原语、MicroVM、自托管运行时、云托管服务、编码 Agent 内置沙箱、浏览器 Agent 和机密计算路线。证据优先采用论文、开源代码、安全公告和厂商架构资料；无法从公开资料确认的能力标记为"未披露"，不据此判断产品没有实现。跨厂商市场地图、AgentENV 案例、隔离原语分级与安全成熟度模型的完整比较见Agent 沙箱市场地图、AgentENV 案例与安全成熟度模型。

沙箱攻击方法分类 ​

按攻击是否需要突破隔离原语本身，分为"原语层逃逸"（真正的沙箱漏洞）和"信任边界滥用"（沙箱本身完好，但沙箱之外的逻辑被欺骗）两大类，后者是 2025-2026 年绝大多数实战案例所在。

原语层逃逸：配置错误 ​

最古老也最常见的一类，本质是运维/产品把危险能力开放给了沙箱内进程：

  • 特权容器 / --privileged：容器内进程直接获得几乎全部 root 能力（CapEff = 0000003fffffffff），可挂载宿主磁盘或 nsenter 进入宿主命名空间。
  • Docker socket 挂载：把 /var/run/docker.sock 挂进容器，等价于把宿主 Docker daemon 控制权交给容器内进程，可再启动一个 --privileged 容器逃逸。
  • cgroup release_agent 逃逸：向 cgroup 层级的 release_agent 文件写入宿主可执行路径，当该 cgroup 的 notify_on_release=1 且进程清空时，宿主内核以最高权限执行该脚本；本用于容器退出清理，被滥用为逃逸原语，代表性漏洞 CVE-2022-0492。
  • 过量 Linux capabilities：CAP_SYS_ADMIN 可组合利用挂载/cgroup 逃逸；CAP_SYS_PTRACE + hostPID 可注入宿主进程；CAP_DAC_READ_SEARCH 对应经典的 shocker 逃逸。
  • 敏感目录挂载：把宿主 /、/proc、/var/run 等挂入沙箱。

对 Agent 沙箱而言，这类风险的现实意义在于：很多"轻量级"自建沙箱包装器（市场地图中碎片化生态里的小项目）为了方便调试或功能完整性，容易在无意中开放上述某一项能力，而这类项目通常没有经过独立安全审计。

原语层逃逸：运行时或内核漏洞 ​

真正打穿隔离层代码本身的漏洞，数量少但影响面大：

  • runc（容器运行时）：2025 年 11 月披露的 CVE-2025-31133 / CVE-2025-52565 / CVE-2025-52881 三连发，影响 runc 1.0.0-rc3 至补丁前几乎所有版本，波及 Docker/containerd/Kubernetes 及各大云厂商托管 Kubernetes；三者分别利用 masked path 符号链接替换、/dev/console 挂载竞态、/proc/self/attr/<label> 重定向绕过 LSM 检查。截至 2026 年 6 月仍有在野利用报告。这类漏洞对任何以容器为默认后端的 Agent 沙箱（包括 Daytona 默认模式）都直接适用。
    • 修复版本：runc ≥1.2.8/1.3.3/1.4.0-rc.3，containerd ≥1.6.39/1.7.28-2，Docker Desktop 已内置 runc 1.3.5（2026-06）。
  • gVisor：CVE-2020-10890（Sentry socket 处理逃逸）、CVE-2021-22555 的 gVisor 专属变种（Sentry 自实现 netfilter 存在堆溢出）。gVisor 的设计本身通过 seccomp 白名单大幅收窄了到达宿主内核的路径，攻击者必须先攻破 Sentry 的 Go 实现才能进一步触达宿主内核 CVE，这也是它至今逃逸级 CVE 数量少于容器方案的结构性原因。
  • Firecracker：2026 年出现首批逃逸级 CVE——CVE-2026-5747（virtio-pci 越界写，CVSS 8.7）、CVE-2026-1386（jailer 符号链接任意宿主文件覆写，CVSS 6.0，AWS 官方声明其托管服务因限制了 jailer 目录访问而不受影响）。此前 Firecracker 多年无公开的 hypervisor 逃逸记录，2026 年是明确的转折点，值得持续跟踪其后续 CVE 节奏。
  • WASM 运行时：Wasmtime CVE-2026-34971（aarch64 Cranelift 后端误编译导致 guest 越界读写宿主内存）；Wasmer CVE-2023-51661（WASI 路径转换缺陷绕过文件系统限制）；此外 "Wasm bomb"（内存膨胀式 DoS，如 CWA-2023-004）属于资源耗尽而非内存破坏型逃逸。
  • Wasmtime GHSA-hgjw-h833-99q9（2026-07-31）：多个 public API 未在使用前校验对象与 Store 是否属于同一 Engine，最严重后果可能是 trampoline signature 混淆导致越界写。公告明确说明 guest WebAssembly 程序无法触发、wasmtime CLI 不受影响；需要 embedder 创建多个 Engine 并混用对象，使用单一 Engine 的进程不受影响。严重度为 low、CVSS 3.8，修复版本为 24.0.12、36.0.13、46.0.2 和 47.0.3。它是 embedder API 隔离缺陷，不应计为 guest-triggered sandbox escape。

Agent 特有的跨组件信任滥用 ​

这类攻击的共同特征是沙箱隔离边界本身完好无损，问题出在沙箱内 Agent 生成/下载的产物，被沙箱外的可信组件不加区分地处理：

  • Google Antigravity：提示词注入结合"允许创建文件"的能力，诱导 Agent 拉取一个含有攻击者控制注释的源文件；这些注释作为正常内容被摄入并处理，最终获得远程代码执行权限——攻击链完全没有触碰沙箱边界本身。
  • Cursor "DuneSlide"（CVE-2026-50548 / CVE-2026-50549，CVSS 9.8）：零点击提示词注入，可逃逸 Cursor 沙箱并在宿主操作系统执行任意代码。
  • Cursor CVE-2026-48124：Claude hooks 配置文件被用于在沙箱外执行命令，3.0.0 版本修复。
  • Claude Code CVE-2026-39861（<2.1.64 版本）：沙箱化进程可以创建指向工作区之外的符号链接，随后一个非沙箱化进程会在未提示用户的情况下通过该符号链接写入——本质是沙箱内进程与沙箱外特权进程之间的 TOCTOU/符号链接信任问题。
  • OpenAI Codex CLI："安全"命令白名单按命令名信任 git show，但实际调用并非只读，OpenAI 在 v0.95.0 修复并支付了高危漏洞赏金（CVE 待分配）。
  • Docker socket 滥用（Codex CLI / Cursor / Gemini CLI，GHSA-v4xv-rqh3-w9mc）：沙箱管得住 Agent 进程本身，管不住它委托给特权本地 daemon（Docker）执行的操作，逃逸发生在 Docker VM 内部、完全在沙箱管辖范围之外。
  • Venv 解释器劫持（Cursor，GHSA-p9g2-cr55-cw9c）：Agent 替换 bin/python 后，由非沙箱化的 IDE 扩展宿主（ms-python.python 的解释器发现机制）在后台执行，与目录命名无关。
  • Git 目录间接引用（Cursor）：--separate-git-dir 让仓库元数据脱离字面 .git/ 路径，沙箱的路径正则规则失效，core.fsmonitor 被劫持为执行触发器。
  • Windows 二进制搜索顺序劫持（Cursor CLI / GitHub Copilot CLI / Gemini CLI / Codex Desktop App）：这些工具解析 git/npx 等外部依赖时沿用 Windows 默认搜索顺序（当前工作目录先于系统 PATH），工作区内攻击者放置的同名可执行文件被优先执行；四款产品的厂商响应从"已修复"到"关闭为 Informative/Not Applicable/低严重性"不等。
  • 配置投毒（AWS Kiro，CVE-2026-10591，CVSS 8.8）：fswrite 工具允许 LLM 不经审批写入 .vscode/tasks.json 等执行敏感文件，配合 VS Code 风格的 "runOn": "folderOpen" 任务定义，受害者打开项目文件夹即自动执行攻击者指定命令；已在 Kiro 0.11 修复。详见AI CLI 工具的零点击 RCE。
  • Auto Mode 拒绝后的解释器信任转移（Claude Code Opus 5）：研究者观察到模式拒绝运行外来二进制后，模型改为生成解码器，再由可信解释器加载工作目录中的同名模块，形成“策略拒绝原动作、替代实现重获同等效果”的多跳链。两组小样本结果为 3/5 与 4/5，尚无独立复现；该证据已合并进AI CLI 工具的零点击 RCE，不应外推为稳定产品成功率。
  • 可信父进程血缘掩护检测（Claude Code）：编码 Agent 派生的子进程建立反向隧道并安装 LaunchAgent 持久化，安全运营常把"进程树里有 Claude/Cursor"当作低风险信号自动结案；Elastic 记录的真实端点事件显示这一假设本身就是检测盲区，且同一行为链无法仅凭进程血缘区分合法远程管理与攻击。详见Living off the 编码 Agent。
  • 无人值守模式工作区自动信任（Gemini CLI，GHSA-wpqr-6v78-jr5g，CVSS 10.0）：CI/CD 等无人值守模式下自动信任工作区目录，不经沙箱初始化即加载 .gemini/ 配置，恶意环境变量以宿主权限执行，全程不涉及模型推理；叠加 --yolo 模式下工具白名单被忽略的第二个缺陷，构成沙箱初始化前的远程代码执行。已修复。详见Gemini CLI 无人值守模式工作区信任绕过 RCE。
  • 共同结论：Pillar Security 等研究者明确指出，这不是经典意义上的沙箱逃逸，而是一个根本性的信任问题——Agent 严格遵守了沙箱约束，但它产出的文件后续被沙箱外的可信软件处理，从而间接导致了沙箱外代码执行。这意味着仅评估沙箱隔离原语强度是不够的，还必须审计"沙箱边界两侧的数据流转"这一整条链路。 上述全部案例的技术细节、PoC 步骤与检测方式的系统性梳理见 pillar-week-of-sandbox-escapes-detection.md。

网络出口滥用 ​

即使沙箱本身隔离良好，只要沙箱内进程拥有出站网络能力，就存在以下风险：

  • 攻击者控制的代码请求云元数据服务（如 169.254.169.254）以窃取宿主/沙箱编排层的临时凭据。
  • DNS rebinding：首次域名解析返回合法公网 IP 通过出站校验，实际发起连接时二次解析已经指向 127.0.0.1 或内网地址，绕过基于"首次解析结果"的白名单/黑名单校验（TOCTOU）。
  • 防御要点：默认拒绝出站（default-deny egress）+ 白名单域名、封禁 RFC 1918 内网段、在实际发起连接时（而非仅在解析阶段）校验并锁定已解析 IP。这正是 Cleanroom（Buildkite）等项目主打的"deny-by-default egress + 凭据代理"模式所针对的问题。

MCP 与工具链供应链攻击 ​

MCP 生态引入了新的攻击面，其"逃逸"往往不发生在容器/VM 边界，而发生在 Agent 的工具调用信任链上：

  • 工具投毒（Tool Poisoning）：恶意文本藏在工具描述/schema 中，Agent 在决策阶段读取到并被诱导调用其他已授权的高权限工具（如把消息历史通过一个"合法"的邮件工具外泄）。
  • 供应链攻击：Agent 插件/MCP server 注册表普遍没有代码签名、漏洞扫描、来源认证等标准化安全要求，攻击者可以低门槛发布恶意 MCP server。
  • 官方组件自身的逃逸链：Cymulate 在 Anthropic 官方 Filesystem MCP Server 中发现两个可串联利用的沙箱逃逸，组合后可在不触发内存破坏的前提下获得完整文件系统读写权限——说明"官方/受信任"标签不能替代独立安全审计。
  • 即使 MCP server 运行在隔离容器中，只要它保留网络访问能力，仍可被用于数据外泄或建立反向 shell，容器隔离只限制了"能否触达宿主"，不限制"能否把数据发到外部"。

资源耗尽与侧信道攻击 ​

  • Fork bomb、内存耗尽、"Wasm bomb"式内存膨胀：目标是让沙箱编排层过载或让其他租户共享资源被挤占。
  • 侧信道：多租户 microVM/容器共享物理核心时的时序/缓存侧信道，公开文献未见 Agent 沙箱场景下的成熟利用案例，仍属于理论风险（未披露）。

沙箱被征用为攻击基础设施 ​

这是与前几类"如何跳出沙箱"方向相反的威胁模式：

  • 2026 年 7 月 Hugging Face 安全事件：攻击者的自主 Agent 框架利用数据集处理流水线中的两个代码执行路径（远程代码加载器 + 数据集配置模板注入）在处理节点上获得代码执行，随后操纵一个由大量短生命周期沙箱组成的集群，在一个周末内跨多个内部集群执行数千个独立动作完成横向移动、凭据窃取。这里"沙箱"扮演的角色不是被攻破的边界，而是被攻击者当作低成本、可批量销毁重建、天然难以被传统 IOC 追踪的攻击执行单元。
  • 这与 ../../pentest-agent-countermeasure/notes/security-agent-countermeasure-research.md 中 "Red-Teaming the Agentic Red-Team" 论文的结论（worker 被武器化后横向渗透 orchestrator）方向一致，但 HF 事件是首个已知的生产环境真实案例，而非红队论文中的受控实验（180 次组合实验中工作区代码执行成功率 97.8%，10/12 系统实现某种宿主逃逸）。
  • 对沙箱产品的启示：安全评估不能只看"能否被逃逸"，还要看"沙箱编排 API 本身的鉴权和批量操作限流是否足够"——AgentENV 当前缺乏鉴权的公开声明（见市场地图）就是同一类风险的例证。

局限与待验证问题 ​

  • 建立"信任边界审计"清单：逐一梳理 Claude Code / Cursor / Codex CLI / Gemini CLI 在"沙箱内产物 → 沙箱外可信进程"路径上的具体处理逻辑（符号链接解析顺序、命令白名单是否检查完整参数而非仅命令名、hook/配置文件是否需要签名或用户确认），产出可复用的检测脚本而不仅是事后合订的 CVE 列表。
  • 复现并量化 Firecracker CVE-2026-5747 / CVE-2026-1386 在主流托管沙箱中的实际可利用性（E2B、Vercel Sandbox、Fly.io Sprites、AgentENV）——这些产品是否已升级到修复版本、jailer 部署配置是否遵循 AWS 官方声明的"不受影响"前提，目前公开资料未披露。
  • 跟踪 AgentENV 后续版本是否补齐鉴权层，以及是否有其他同类"训练场景优先、鲜有考虑对外暴露"的开源沙箱项目存在同样问题。
  • 为 MCP server 沙箱化建立独立于代码执行沙箱的威胁模型——重点是网络出口而非内存破坏，现有容器/microVM 强度指标不能直接套用。
  • 产品对比证据的独立性有限：市场地图大量依赖厂商博客与第三方评测站点，尚未找到公开方法论、可复现的独立评测覆盖全部主流产品；已知相关论文只评测了五个沙箱产品，需要进一步核实全文结论（本地 PDF：../papers/ai-code-sandboxes-comparative-security-study.pdf）。

历史研究成果 ​

本分类下的独立研究围绕"动作面与资源权威未分离"（即 Agent 的可见操作与底层资源权限之间缺乏有效隔离）这一失效控制展开。

研究对象覆盖 Skill 制品与自演化 Agent 的运行时权限、非特权 Linux 进程隔离、编码 Agent 沙箱、容器逃逸的宿主侧组件，以及跨厂商市场格局与单一厂商工程实现：VIGIL 和 SkillGuard 针对 Skill，Agent libOS 针对长期运行、自演化的 Agent，Sandlock 将 Landlock、seccomp-bpf 与窄监督器组合为工作站代码执行控制面，跨产品沙箱重复失效、Week of Sandbox Escapes、AI CLI 工具的零点击 RCE、Living off the 编码 Agent 和 Gemini CLI 无人值守模式工作区信任绕过 RCE 针对编码 Agent，Bulkhead 针对容器扩展组件的路径解析，Agent 沙箱市场地图 综合跨厂商公开材料给出隔离原语分级和安全成熟度模型，OpenAI Codex 的 Windows 沙箱架构 则是单一厂商在缺少原生隔离原语平台上的工程决策深度记录。

研究方法从"自然语言规范"转向"可计算的运行时约束"：VIGIL 把 Skill 规范编译为有限轨迹上的 SMT 约束，SkillGuard 用双平面权限分别约束上下文影响与工具副作用，Agent libOS 用显式 capability、预算和审计原语分离动作与资源权威，Sandlock 将输入无关规则编译到 Landlock/seccomp-bpf、将运行时决定交给窄监督器；沙箱方向则以跨厂商会议报告和逐案逃逸复盘归纳共性，Bulkhead 把容器逃逸建模为跨组件路径解析不变量做语义检测与补丁生成，市场地图以厂商公开披露的自我报告构建隔离原语与成熟度分级，OpenAI Codex 案例和 AI CLI 工具 RCE 研究都是逐产品机制复盘：前者是单一厂商工程博客的深度解读，后者横向比较五款产品对同一类 Windows 路径解析/配置写入问题的不同处置结果，并由 Auto Mode 的模块遮蔽链补充“拒绝原动作后仍需约束语义等价替代路径”；Gemini CLI 案例则是官方安全公告披露的复合缺陷分析，说明同一产品在不同运行模式（交互 vs. 无人值守、默认 vs. --yolo）下可能暴露完全不同层级的失效控制。

研究成果的共同结论是：把"可见动作"等同于"资源权限"是这些系统的核心失效，语言层声明和单一隔离原语都不足以形成边界，需要在运行时把动作面与资源权威分离并对轨迹做可计算校验。AI 编排平台的跨阶段代码执行风险从 NocoBase、Flowise、Langflow、Dify、Activepieces、Kestra 和 Airflow 的 13 项发现补充了一类一致性问题：测试接口或预览阶段的过滤、沙箱不一定覆盖生产 worker 的实际执行路径。Copilot Studio Python 沙箱逃逸与多租户影响则显示，模型可组合被静态规则漏掉的 Python 反射访问；无出站网络也不能阻止模型响应回显数据，而跨租户共享凭据会扩大单容器失陷的影响。跨厂商证据进一步显示：市场在隔离原语选型上已经成熟，但编排面鉴权和信任边界审计仍是全行业公开空白。同一类问题在不同厂商手里的处置结果可以截然不同，说明"该产品是否已修复"不能类推到"同类产品是否已修复"。各研究的量化数字只在各自基准、版本或公开材料范围内成立。

Concepts for Securing Agentic AI Coding and the Terok Environment提供了一项架构侧增量：先评估编码 Agent 的文件、网络和命令风险，再以隔离执行环境承载 Agent 的可执行部分，目标是在保留开发效用的同时收窄宿主暴露。它支持“把执行权放进受控环境，而不是依赖模型自律”的方向，但论文主要给出风险评估、设计概念和 Terok 实现概览，没有跨产品攻击基准、逃逸率或独立复现；因此不能把该实现列为已验证更安全，也不能据此推断其对本文列出的宿主信任交接、网络出口和运行时 CVE 均有覆盖。

ClosureBound进一步把 Skill 运行时授权从根目录和单次工具调用扩展到“当前解析的传递依赖闭包 + 规范化外部效果”。它在提交持久效果前重新解析文件、递归 Skill、包、工具 Schema、模型和服务，并将精确闭包根、用途、效果上限、状态与 epoch 绑定到一个联合 witness；40 个生命周期夹具、18 个合同、6 个 mutant 及 84,608 个状态/530,752 条转移的有限探索支持其机制一致性。对 549 个公开 Skill 的审计又发现 67 个越界链接且没有根声明 dependencies 字段，说明只验根制品会遗漏现实依赖；不过结果仍是作者参考实现和词法审计，完整依赖发现、效果规范化、远程服务真实性与生产误拒率尚未验证。

相关研究文章 ​

Skill 生命周期与运行时控制

ClosureBound：Agent Skill 传递依赖闭包与效果时刻授权研究如何把 Agent Skill 的传递依赖闭包、授权范围和规范化外部效果绑定到同一操作时刻，阻止旧授权跨版本与等价路径转移。2026-09-05VIGIL：将 Agent Skill 行为规范编译为运行时约束用时序、参数和值流约束检查第三方 Skill 的实际执行轨迹。2026-06-25SkillGuard：把 Agent Skill 作为双平面权限主体研究 Skill 如何同时影响模型上下文与工具副作用，并以 manifest、运行时权限控制和用户确认把两类影响放入同一执行策略。2026-06-02

工作流执行与沙箱阶段

AI 编排平台的跨阶段代码执行风险综合七款 AI 编排与工作流平台的 13 项发现，分析输入校验、代码生成与沙箱实际执行阶段不一致时如何形成远程代码执行。2026-08-13

托管 Agent 沙箱逃逸

Copilot Studio Python 沙箱逃逸与多租户影响分析托管 Python 工具如何被反射访问链突破，以及共享管理凭据、容器寿命和响应回显为何会扩大多租户沙箱逃逸影响。2026-08-13

编码 Agent 的跨组件信任交接

Living off the Coding Agent：编码 Agent 作为可信父进程掩护反向隧道与 LaunchAgent 持久化分析 Elastic 记录的真实端点事件——编码 Agent（Claude Code）派生的子进程建立反向隧道并安装 LaunchAgent 持久化，暴露"可信父进程血缘"不能作为检测降级依据的问题。2026-08-07AI CLI 工具的零点击 RCE：Windows 二进制搜索顺序劫持与配置投毒分析 Cymulate 披露的五款 AI 编码 CLI/IDE 工具漏洞——Windows 下工作区本地可执行文件优先于系统路径被解析执行，以及 AWS Kiro 未审批写入执行敏感配置文件触发自动任务执行。2026-06-04Gemini CLI 无人值守模式工作区信任绕过 RCE（CVSS 10.0）分析 GHSA-wpqr-6v78-jr5g——Gemini CLI 在 CI/CD 等无人值守模式下自动信任工作区目录、`--yolo` 模式绕过细粒度工具白名单两个复合设计缺陷如何组合成沙箱初始化前的远程代码执行。2026-04-24编码 Agent 沙箱的跨产品重复失效模式记录 Black Hat Asia 2026 的 Bad Vibes 研究对多种编码 Agent 中提示词注入、路径处理与沙箱策略问题的报告；公开材料含摘要与幻灯片，未提供统一复现套件。2026-04-23

市场态势与安全成熟度

Agent 沙箱市场地图、AgentENV 案例与安全成熟度模型按隔离原语、MicroVM、云托管服务、自托管运行时、编码 Agent 内置沙箱、浏览器沙箱和机密计算七层比较 Agent 沙箱市场，并给出 L1-L5 安全成熟度对照。2026-07-28

真实逃逸案例

Week of Sandbox Escapes 案例与检测分析复盘 Pillar Security 披露的 Agent 沙箱逃逸案例，按信任边界、根因、可观测信号和缓解控制进行归纳。2026-07-23

逃逸检测与修补

Bulkhead: Automated Semantic Detection and Remediation of Container Escape Vulnerabilities分析 Bulkhead 如何用跨组件路径解析不变量检测并修补容器逃逸漏洞，以及其单模型评测和预定义不变量带来的适用限制。2026-07-14

自演化 Agent 运行时

Agent libOS：自演化 Agent 的能力控制运行时以显式 capability 原语隔离 Skill、JIT Tool、Memory、Checkpoint 和子进程的动作面与资源权限。2026-06-02

进程隔离与受限执行

Sandlock：以非特权 Linux 原语约束 Agent 生成代码分析 Sandlock 如何以 Landlock、seccomp-bpf 与窄监督器限制 Agent 执行代码的文件、网络、IPC 和系统调用权限。2026-05-25

编码 Agent 内置沙箱

OpenAI Codex 的 Windows 沙箱架构：从未提权到提权方案的决策链解读 OpenAI 官方工程博客披露的 Codex CLI Windows 沙箱实现，分析未提权方案为何被放弃、提权方案如何用合成用户绕过受限令牌无法绑定防火墙规则的限制。2026-05-13

参考链接 ​