kajogo777/the-agent-sandbox-taxonomy

# Agent Sandbox 分类体系 (AST) *版本 1.0，2026 年 3 月* 一个用于评估 AI Agent Sandbox 的开放分类体系和评分框架。它将沙箱机制分解为 **7 层防御层**，将其映射到 **7 种威胁类别**，并从 **3 个维度**（强度、粒度、可移植性）对每种机制进行评分，从而为任何产品生成可比较的指纹。其中包括 18 种沙箱工具的评分卡、用于堆叠互补产品的组合框架，以及选择合适沙箱技术栈的决策检查清单。

## 如何使用本文 本文档提供了一套通用语言，用于讨论 Agent Sandbox 能做什么、不能做什么以及它们解决了哪些威胁。请记住 **7-7-3**：**7** 层防御层，**7** 种威胁类别，**3** 个评估维度（强度、粒度、可移植性）。 文档分为两大部分： **分类体系** ([第 1–5 部分](#the-taxonomy)) 定义了沙箱*是什么*。七层防御层、七种威胁类别、它们之间的关系、如何对机制评分，以及如何为任何产品生成指纹。用它来以平等的条件描述、分类和比较解决方案。 **框架** ([第 6–8 部分](#the-framework)) 定义了沙箱消费者应该*做什么*。组合模式、反模式、决策检查清单和堆叠规则。用它来为你的情况选择合适的沙箱技术栈。 **附录** 包含特定产品的数据：[评分卡](#appendix-b-product-score-cards)、[威胁覆盖矩阵](#appendix-c-threat-coverage-matrix)和[机制参考](#appendix-a-layer-mechanism-reference)。这是唯一需要定期更新的部分。 ### 目录 **分类体系** 1. [问题背景](#1-the-problem) 2. [七层防御层](#2-the-seven-defense-layers) - [L1 — 计算隔离](#l1--compute-isolation) · [L2 — 资源限制](#l2--resource-limits) · [L3 — 文件系统边界](#l3--filesystem-boundary) · [L4 — 网络边界](#l4--network-boundary) · [L5 — 凭证与密钥管理](#l5--credential--secret-management) · [L6 — 操作治理](#l6--action-governance) · [L7 — 可观测性与审计](#l7--observability--audit) 3. [七种威胁](#3-the-seven-threats) 4. [评分](#4-scoring) - [强度](#strength-s-04) · [粒度](#granularity-g-03) · [可移植性](#portability) · [指纹](#the-fingerprint) 5. [术语表](#5-glossary) **框架** 6. [为何组合是必要的](#6-why-composition-is-necessary) 7. [组合模式](#7-composition-patterns) 8. [决策检查清单](#8-decision-checklist) **附录** - [A — 层级机制参考](#appendix-a-layer-mechanism-reference) - [B — 产品评分卡](#appendix-b-product-score-cards) - [C — 威胁覆盖矩阵](#appendix-c-threat-coverage-matrix) - [结论](#conclusion) # 分类体系 *沙箱是什么，如何描述它们，以及如何比较它们。* ## 1. 问题背景 当有人说“我们对 Agent 进行了沙箱处理”时，这可能意味着任何事情，从没有安全加固的 Docker 容器，到具有默认拒绝出口流量和凭证代理的硬件隔离 microVM。 AI 编码 Agent 必须支持完整的开发工作流（包安装、编译、测试执行、数据库访问、浏览器自动化），同时将每一条生成的命令都视为潜在的恶意行为。Agent 可能会因为幻觉、Prompt 注入、受损的依赖项或对意图的误解而行为失常。沙箱不关心*原因*。它只负责强制执行边界。 该分类体系将沙箱分解为 **七层防御层**，并将它们映射到 **七种威胁类别**，从而为任何沙箱做什么和不做什么提供了一套精确的词汇表。 ## 2. 七层防御层 每个沙箱都强制执行这七层的某种组合。没有哪个沙箱能同等覆盖所有七层。大多数只覆盖了两三层，而忽略了其余的。 | 层级 | 名称 | 关键问题 | |---|---|---| | **L7** | 可观测性与审计 | 你能看到 Agent 做了什么吗？ | | **L6** | 操作治理 | 你能控制它执行什么操作吗？ | | **L5** | 凭证与密钥管理 | 密钥在 Agent 周围是如何处理的？ | | **L4** | 网络边界 | 它能与什么通信？ | | **L3** | 文件系统边界 | 它能读取、写入和删除什么？ | | **L2** | 资源限制 | 它在 CPU、内存、磁盘、时间上是否受到限制？ | | **L1** | 计算隔离 | 是什么将 Agent 与主机隔开？ | 层级是自下而上编号的，因为较低的层是基础。强大的 L1 使 L3 更容易实现：microVM 默认获得一个全新的文件系统。但是**上层无法从下层推导出来**。一个拥有完美 L1 但没有 L4 的 microVM 仍然允许 Agent 通过单个出站请求窃取秘密。一个拥有完美 L1–L5 但没有 L7 的系统将无法让你检测到滥用行为或改进策略。 ### L1 — 计算隔离 *是什么将 Agent 的执行与主机系统隔开？* L1 是基础。上层不可能比它更强，因为逃逸 L1 的进程会绕过其上的所有内容。重要的是沙箱工作负载与主机之间**共享攻击面的大小**，范围从完整的主机内核（容器），到减少的 syscall 表面（用户空间内核），到最小的 VMM（microVM），到单用途内核，再到硬件加密内存（机密计算）。机制谱系请参见 **[附录 A](#appendix-a-layer-mechanism-reference)**。 ### L2 — 资源限制 *Agent 能否耗尽 CPU、内存、磁盘或时间？* Fork 炸弹或内存泄漏即使在完美的 L1 边界内也能对主机发起拒绝服务攻击。强制执行必须发生在**沙箱之外**：主机上的 cgroups，或由 hypervisor 进行的 VM 资源分配。在其沙箱内拥有 root 权限的 Agent 可以绕过沙箱内的资源控制，但无法逃逸 hypervisor 级别的上限。 ### L3 — 文件系统边界 *Agent 能在磁盘上读取、写入和删除什么？* 边界必须是**选择性的**，而非完全的。Agent 合法地需要读/写项目文件。真正的问题是敏感路径（`~/.ssh`、`~/.aws`、`.env`）是否可访问。范围从完全访问，到路径允许列表、敏感路径阻止列表、临时根目录、带有可写覆盖层的不可变根目录，再到完全独立的文件系统。 ### L4 — 网络边界 *Agent 可以与哪些外部系统通信？* 这是最被低估的一层。在具有 unrestricted network access 的完美计算沙箱内，Agent 仍然可以通过单个出站请求窃取每一个秘密。 **流量如何被拦截与是否被拦截同样重要。** 依赖沙箱进程遵守 `HTTP_PROXY` 环境变量的网络边界，与在内核级别拦截的边界有着根本的不同。进程可以通过原始套接字、`--noproxy` 标志或自定义 DNS 轻松绕过代理环境变量。这反映在强度分数中：协作式强制执行（进程必须选择加入）始终是强度 1，无论代理多么复杂。只有不透明强制执行（进程无法规避的内核/hypervisor 拦截）或结构性强制执行（不存在网络设备）才能获得强度 3–4。 ### L5 — 凭证与密钥管理 *Agent 能否看到、使用或窃取凭证？* 即使有强大的 L1–L4，拥有 API 密钥的 Agent 也可以将它们嵌入到生成的代码中或将它们提交到 repo。理想情况下，凭证**从未出现**在 Agent 的环境中。范围从完全凭证访问，到文件阻止、环境变量过滤、占位符替换（检测到秘密并替换为令牌，在执行时恢复）、凭证代理（外部代理代表进行身份验证），再到临时的每会话令牌。 ### L6 — 操作治理 *Agent 能否执行破坏性或未经授权的操作？* L6 与 L1–L5 不同。那些层限制**对资源的访问**。L6 限制**Agent 利用其所拥有的访问权做什么**。拥有合法云访问权限的 Agent 仍然可以终止实例。拥有合法 DB 凭证的 Agent 仍然可以删除表。 L6 在**语义层面**运作，跨越较低的层级。L3 说“你不能写入此路径”。L4 说“你不能连接到此目的地”。L6 说“你不能删除生产资源”，无论操作流经哪一层，都管理意图和效果。这使得 L6 能够表达任何单个较低层都无法表达的策略。 权衡在于，L6 通常是软件强制执行的，并且可以以内核/硬件强制执行所不具备的方式被绕过。命令阻止列表可以通过 Shell 重定向规避。L6 是纵深防御，在强大的 L1–L4 之上最有价值。 ### L7 — 可观测性与审计 *你能看到 Agent 做了什么、何时做以及为什么做吗？* 如果没有可观测性，你就无法检测滥用、调查事件、改进策略或证明合规性。L7 将沙箱从静态边界转变为**自适应安全系统**。范围从无日志，到会话级日志、命令级审计、全量遥测（网络、syscall、MCP 工具调用、实时 UI），再到加密审计链（具有来源跟踪的防篡改日志）。 ## 3. 七种威胁 Agent 可能造成七类伤害。沙箱的存在就是为了遏制它们。 | ID | 威胁 | 出什么问题 | 示例 | |---|---|---|---| | **T1** | **数据窃取** | Agent 读取敏感数据并将其传输到外部 | 读取 SSH 密钥，通过出站请求发送 | | **T2** | **供应链攻击** | Agent 引入恶意代码：受损的依赖项、二进制文件替换、构建产物投毒 | 恶意安装脚本窃取环境变量；包替换受信任的二进制文件 | | **T3** | **破坏性操作** | Agent 销毁或错误配置资源，**包括本地和远程** | 本地：`rm -rf /`。远程：通过 API 删除云资源、删除 DB 表、`kubectl delete namespace` | | **T4** | **横向移动** | Agent 到达其预期范围之外的系统 | 扫描本地网络，访问云元数据端点 | | **T5** | **持久化** | Agent 在沙箱销毁后幸存 | 写入 cron job，修改 shell 初始化文件，安装 git hooks | | **T6** | **权限提升** | Agent 完全逃逸沙箱 | 利用内核 CVE，容器逃逸 | | **T7** | **拒绝服务** | Agent 消耗过多资源，降低主机或其他租户的性能 | Fork 炸弹，内存炸弹，磁盘填满 | ### 沙箱与 Agent 对齐正交 Prompt 注入、幻觉、未对齐、错误的上下文、受损的依赖项 —— 这些都是 Agent 可能**决定**做有害事情的原因。它们是**载体**，而不是威胁。分类体系故意排除了它们，因为沙箱在不同的层面上运作：它们控制 Agent **能**做什么，而不是它**选择**做什么。 让 Agent 做出好的决策是一个 **Agent 对齐** 问题（护栏、RLHF、系统提示、上下文过滤）。当它做出错误决策时防止损害是一个**沙箱**问题。这两者是互补但独立的。完美对齐的 Agent 仍然受益于沙箱（纵深防御）。具有不良对齐的完美沙箱 Agent 仍然受到遏制。 ``` ┌─────────────────────┐ Prompt Injection ──┐ │ │ Hallucination ─────┤ │ Agent Alignment │ ← why the agent decided Misalignment ──────┼──▶ │ (out of scope) │ Bad context ───────┤ │ │ Malicious code ────┘ └────────┬────────────┘ │ ▼ Agent attempts harmful action │ ▼ ┌─────────────────────┐ │ │ │ Sandbox boundary │ ← what the agent can do │ (this taxonomy) │ │ │ └─────────────────────┘ ``` ### 各层如何防御威胁 威胁不遵守层级边界。单个破坏性操作可能涉及读取凭证 (L3/L5)、发出网络请求 (L4) 和执行破坏性 API 调用 (L6)。 | 威胁 | 主要防御 | 为何需要多层 | |---|---|---| | **T1 窃取** | L3 + L4 + L5 | L3 阻止读取秘密，L4 阻止将其发送出去，L5 确保它们不存在。任何单层单独都会泄露。 | | **T2 供应链** | L3 + L4 + L7 | L4 控制下载源，L3 保护文件系统完整性（防止二进制替换），L7 在事后检测到攻击。 | | **T3 破坏性操作** | L1 + L3 (本地) / L4 + L6 (远程) | L1+L3 覆盖本地破坏。**远程破坏是一种网络操作**：需要 L4 阻止访问以及 L6 在语义上阻止该操作。单靠 L1 不保护远程资源。 | | **T4 横向移动** | L4 + L1 | L4 阻止出站访问。L1 提供网络命名空间隔离作为次要边界。 | | **T5 持久化** | L1 + L3 + L | 临时沙箱（L1 被销毁）本质上防止持久化。持久沙箱需要 L3 阻止初始化文件写入以及 L6 阻止计划任务创建。 | | **T6 权限提升** | L1 + L2 | L1 强度直接决定逃逸阻力。硬件边界比软件边界从根本上更难逃逸。 | | **T7 拒绝服务** | L2 + L1 | L2 限制资源。强制执行必须在沙箱之外（cgroups, hypervisor 分配）。 | **威胁不是独立的。** T2 通常是 T1/T3/T4 的载体。T5 延长了任何其他威胁的时间窗口。T6 使所有其他层失效。T7 可以是直接目标或副作用。 ### 威胁评估规则 威胁覆盖范围是从层级分数中**机械地**评估出来的，而不是凭直觉。对于每种威胁，主要防御层都有一个 **S >= 2** 的阈值（软件强制执行或更强）。评级取决于有多少主要层达到阈值： - **●** (已解决)：**所有**主要层都达到阈值 - **◐** (部分)：**至少一个**主要层达到阈值，但不是全部 - **○** (未解决)：**没有**主要层达到阈值 | 威胁 | 主要层 | ● (全部达到阈值) | ◐ (部分达到) | ○ (均未达到) | |---|---|---|---|---| | **T1** | L3, L4, L5 | 三者全部 >= 2 | 至少一个 >= 2 | 没有 >= 2 | | **T2** | L3, L4, L7 | 三者全部 >= 2 | 至少一个 >= 2 | 没有 >= 2 | | **T3-L** | L1, L3 | 两者 >= 2 | 一个 >= 2 | 都不 >= 2 | | **T3-R** | L4, L6 | 两者 >= 2 | 一个 >= 2 | 都不 >= 2 | | **T4** | L4, L1 | 两者 >= 2 | 一个 >= 2 | 都不 >= 2 | | **T5** | L1, L3, L6 (或临时) | 三者全部 >= 2，或临时 L1 >= 4 | 至少一个 >= 2 | 没有 >= 2 | | **T6** | L1, L2 | L1 >= 3 且 L2 >= 2 | 至少一个 >= 2 | 都不 >= 2 | | **T7** | L2, L1 | 两者 >= 2 | 至少一个 >= 2 | 都不 >= 2 | T3 总是分为本地 (T3-L) 和远程 (T3-R)。组合后的 T3 评级使用两者中较低的一个。符号表示：`L●/R○`、`L●/R◐`、`full L+R` (两者都为 ●)。 将 `~` (层未解决) 视为 0 用于阈值比较。 ## 4. 评分 每一层都从两个维度进行评级，加上一个可移植性标签。这些共同构成了 7-7-3 结构中的**三个评估维度**。 ### 强度 (S: 0–4) 强度将强制执行的健壮性、可逆性和执行透明度结合到一个分数中。可以被绕过、逆转或选择退出的边界会获得较低的分数，无论该机制多么复杂。 | 分数 | 级别 | 含义 | |---|---|---| | **0** | 无 | 此层无强制执行 | | **1** | 协作式 | 沙箱进程可以规避、选择退出或可以通过逃逸 hatch 逆转的强制执行。包括：进程可以忽略的代理环境变量、建议性限制、具有已知绕过机制的配置。如果进程可以打开原始套接字并跳过你的过滤器，那就是 S:1。 | | **2** | 软件强制执行 | 由沙箱进程无法从内部规避的单独进程或代理强制执行，但操作员可以从外部重新配置。包括：容器级隔离、热加载策略引擎、带有 iptables 重定向的 MITM 代理 | | **3** | 内核强制执行 | 由 OS 内核通过一旦应用就无法削弱（即使操作员在会话期间也无法削弱）的机制强制执行。包括：Landlock、Seatbelt、seccomp-BPF、内核级网络过滤。不可逆。 | | **4** | 结构性 | 由 CPU 虚拟化、硬件加密或架构缺失强制执行。受保护的资源或攻击面在沙箱内不存在。包括：KVM 隔离的 microVM、unikernel、禁用网络的沙箱（无网络设备）、凭证代理（秘密从不进入沙箱）、机密 VM (SEV-SNP/TDX)。 | **关键原则：** 协作式强制执行始终是 S:1，无论代理多么复杂。如果内核拒绝 syscall，那就是 S:3。如果没有可使用的网络设备，那就是 S:4。 ### 粒度 (G: 0–3) 这一层的控制有多细粒度？ | 分数 | 级别 | 含义 | |---|---|---| | **0** | 无 | 无控制 | | **1** | 二元 | 开/关（例如，“网络：启用/禁用”） | | **2** | 允许列表/阻止列表 | 允许或拒绝的资源列表（例如，“允许这些域”，“阻止这些路径”） | | **3** | 每资源策略 | 针对每个资源、操作和上下文的细粒度规则（例如，“允许 GET 但拒绝 DELETE”，针对每个连接的 Cedar/OPA 策略） | ### 可移植性 回答以下问题的扁平标签列表：**它在什么 OS 上运行，需要什么基础设施？** 标签涵盖两个维度 —— **OS 支持**和**基础设施依赖** —— 组合在单个数组中。 | 标签 | 维度 | 含义 | |---|---|---| | **any-os** | OS | 适用于 Linux、macOS 和 Windows | | **linux** | OS | 需要 Linux | | **mac** | OS | 支持 macOS | | **cloud** | 基础设施 | 在供应商的云中运行；OS 被抽象化 | | **docker** | 基础设施 | 需要 Docker 或兼容的容器运行时 | | **k8s** | 基础设施 | 需要 Kubernetes 集群 | | **kvm** | 基础设施 | 需要 `/dev/kvm`（裸机或嵌套虚拟化） | 没有基础设施标签意味着该工具直接在 OS 上运行，没有额外的依赖项。 产品通常有多个标签（例如，`[linux, mac]` 或 `[any-os, cloud]`）。 ### 指纹 每个产品都有一个**指纹**，一个受 CVSS 启发的向量字符串，显示其在每一层的强度分数。每个条目是 `Layer:Score`，用 `/` 分隔。 **`0` vs `—` (破折号)：** 两者都意味着“无覆盖”，但原因不同。**`0`** 意味着产品*在此层运作*但不提供强制执行：该能力存在，只是完全开放（例如，具有 unrestricted network stack 的云沙箱）。**`—`** 意味着产品*根本不解决*这一层；它超出了产品的范围（例如，不是计算沙箱的策略工具）。出于组合目的，两者都被视为“无覆盖”，来自另一个产品的任何非零分数都会填补空白。 **完整形式**，自我描述，用于产品评分卡： ``` E2B L1:4/L2:4/L3:4/L4:0/L5:2/L6:-/L7:2 ``` **紧凑形式**，位置式（L1 到 L7，始终按顺序），用于比较表和组合： ``` E2B 4/4/4/0/2/-/2 Leash 2/2/2/3/2/2/3 Warden -/-/1/2/3/2/3 nono 3/-/3/3/3/2/2 ``` 这两种形式可以互换。紧凑形式始终按 L1→L7 顺序包含所有七个位置，因此可以从列标题中读取层标签。 评分卡（参见 [附录 B](#appendix-b-product-score-cards)）将每一层显示为 `S.G`，强度和粒度用 `.` 分隔（例如，`4.1` = 结构性强度，二元粒度）。指纹仅使用强度用于快速比较视图。 **分隔符约定：** `:` 将层绑定到其值（完整形式），`.` 分隔层内的强度和粒度，`/` 将层彼此分隔。 有关产品评分卡，请参见 **[附录 B](#appendix-b-product-score-cards)**。 ## 5. 术语表 | 术语 | 定义 | |---|---| | **爆炸半径** | Agent 受损或行为失常时的最大损害 | | **协作式强制执行** | 依赖沙箱进程遵守约定（例如代理环境变量）的强制执行。可绕过；始终为 S:1 | | **纵深防御** | 分层多个独立边界，这样一个边界失效不会危及系统 | | **逃逸 hatch** | 允许绕过沙箱限制的机制；其存在将强度限制在 S:1 | | **不透明强制执行** | 无论沙箱进程行为如何都有效的强制执行。无法规避；S:2–3 | | **结构性强制执行** | 受保护资源在沙箱内不存在的强制执行。没有什么可绕过的；S:4 | | **Agent 对齐** | 让 Agent 做出正确决策的问题（护栏、RLHF、上下文过滤）。与沙箱互补但独立 | | **载体** | 触发威胁的攻击路径（Prompt 注入、幻觉、未对齐、受损依赖项）。与其激活的威胁 (T1–T7) 不同。沙箱与载体无关 | # 框架 *如何选择、组合和堆叠沙箱解决方案。* ## 6. 为何组合是必要的 没有单一产品能很好地覆盖所有七层。这是设计使然：专注于 L1–L3（隔离边界）的产品与专注于 L4–L7（行为治理、凭证、可观测性）的产品互补。认识到这一点是分类体系中最重要的见解。 指纹使这一点变得可见。当一个产品显示 `—` 或 `0` 时，另一个显示 `3` 或 `4`。这就是互补性。堆叠它们，差距就会消失： ``` Firecracker VM 4/4/4/2/1/-/1 <- strong box, weak credentials, no governance Network Proxy 2/0/2/2/2/2/2 <- no box, but governs behavior + secrets ----------------------------------- Composed 4/4/4/2/2/2/2 <- take the max at each layer ``` 组合时，**取每一层的最大强度**。组合后的技术栈的强度仅取决于其最薄弱的未覆盖层。 ## 7. 组合模式 ### 平台 + 策略层 *"坚固的盒子，智能的护栏"* 云沙箱平台提供 L1–L3（硬件隔离计算、资源限制、临时文件系统）。策略工具分层 L4–L7（网络策略、凭证管理、操作治理、可观测性）。全栈覆盖。 ### OS 级包装器 + 策略 Sidecar *"轻量级本地保护"* 内核级进程包装器提供具有不可逆强制执行的 L1/L3/L5。策略 sidecar 添加 L4/L6/L7。全栈减去 L2（资源限制）。零成本，无云依赖。 ### 内置沙箱 + 云后备 *"本地为了速度，云为了不受信任"* Agent 的内置沙箱处理受信任的交互式工作 (L1/L3/L4)。不受信任的操作卸载到具有完整 L1–L3 的云平台。 ### K8s 原生技术栈 *"企业级、自托管、策略驱动"* Kubernetes 沙 箱 CRD (L1/L2/L3) + NetworkPolicy (L4) + 策略引擎 (L6) + secrets manager (L5) + 监控技术栈 (L7)。全栈，自托管。 ### 反模式：没有网络控制的平台 云平台提供出色的 L1/L2/L3，但用户使用默认（unrestricted）网络访问部署，并将云凭证作为环境变量传递。Agent 在完美的 microVM 中运行，但仍可以窃取凭证、删除云资源并访问内部服务。 **这是实践中最常见的配置，也是一种虚假的安全感。** 强大的 L1 是必要的但不够的。查看指纹：如果 L4 是 `0`，你就有问题了。 ## 8. 决策检查清单 按顺序解决这些问题，以确定你的沙箱技术栈需要什么。 **1. 你对代码的信任程度如何？** 不受信任的代码需要 L1 S:4 (microVM/unikernel)。你自己审查过的代码可以使用 S:2–3。 **2. Agent 是否与远程资源（云、数据库、API）交互？** 如果是且具有读写访问权限：L1 **不**保护远程资源。你需要 L4（阻止破坏性端点）、L6（在语义上阻止破坏性操作）或 L5（范围限定的只读凭证）。 **3. Agent 是否需要网络访问？** 如果不需要，请禁用它 (L4 S:4)。这会一步消除 T1 和 T4。如果需要，请使用允许列表 (S:2–3) 并投资于 L5 和 L7。 **4. Agent 是否处理凭证？** 理想情况下凭证从不出现（通过代理或临时令牌的 L5 S:4）。如果可以避免，切勿传递原始凭证。 **5. 你能容忍人在回路中吗？** 如果不能（自主 Agent），你需要 L6 S:2+（策略引擎）。这就是行为治理工具变得必不可少的地方。 **6. 你需要审计跟踪吗？** 为了合规或团队使用，L7 S:2+ 带有结构化日志。考虑针对监管要求的加密审计链。 **7. 临时还是持久箱？** 临时沙箱本质上解决了 T5。持久沙箱必须通过不可变文件系统或受监视的变更明确解决 T5。 **8. 你的可移植性约束是什么？** 无基础设施 → 进程包装器（无需 infra 标签）。Docker 可用 → 容器包装器、sidecar (`docker`)。云/K8s → 完整平台范围 (`cloud`, `k8s`)。 ### 检查清单之后 将你的答案映射到层级要求，然后扫描 [评分卡（附录 B）](#appendix-b-product-score-cards) 以寻找以所需强度覆盖这些层的产品。如果没有单一产品满足你的需求，请使用堆叠规则（取每层的最大值）组合两个产品。验证组合后的指纹在你关心的层上没有零或破折号。 # 附录 A：层级机制参考 列出了每层的机制及其强度和粒度。列出的产品作为示例，并非详尽无遗。 *最后更新：2026 年 3 月* ## A.1 — L1 计算隔离 | 机制 | S | G | 工作原理 | |---|---|---|---| | 裸进程 | 0 | 0 | 无隔离；完整用户权限 | | Linux namespaces + cgroups | 2 | 1 | PID/mount/net/user 命名空间分离；共享主机内核 | | Namespaces + seccomp/Landlock/Seatbelt | 3 | 1–2 | 内核强制执行的 syscall 过滤或 LSM；不可逆 | | 用户空间内核 | 3 | 1 | 在用户空间拦截约 200 个 syscall；暴露约 60 个主机 syscall | | MicroVM — 最小 VMM (Firecracker) | 4 | 1 | 通过 KVM 为每个工作负载提供专用内核；约 50K 行 Rust VMM | | MicroVM — 容器形态 | 4 | 1 | 容器形态 VM；兼容 CRI；需要 KVM | | Unikernel | 4 | 1 | 单应用自定义内核；约 1MB 镜像；需要 KVM | | Library OS | 3–4 | 1 | 嵌入式最小 OS 库；实验性 | | 机密 VM (SEV-SNP/TDX) | 4 | 1 | 硬件加密内存；即使 hypervisor 也无法读取 | ## A.2 — L2 资源限制 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无 | 0 | 0 | 无限制 | | cgroups v2 | 3 | 2 | 内核强制执行的 CPU/内存/IO 上限 | | VM 资源分配 | 4 | 2 | 创建 VM 时固定的 vCPU/RAM/磁盘 | | 平台配额 | 2 | 2 | 每会话或每账户限制 | | 有时间限制的会话 | 2 | 1 | 超时后自动终止 | ## A.3 — L3 文件系统边界 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无限制 | 0 | 0 | 完整用户文件系统 | | 仅工作目录挂载 | 3 | 2 | 仅项目目录可见；其他所有内容不可见 | | 敏感路径阻止列表 | 3 | 2 | 大多数路径可访问；阻止 ~/.ssh, ~/.aws 等 | | 临时根目录 | 4 | 1 | 每个会话全新的 OS；项目挂载其中 | | 不可变根目录 + 可写覆盖层 | 4 | 2 | 只读基础；写时复制；能够回滚 | | 完全独立的文件系统 | 4 | 1 | 单独的磁盘；无主机路径可见 | ## A.4 — L4 网络边界 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无限制 | 0 | 0 | 完整网络访问 | | 代理环境变量 | 1 | 2 | **协作式**：通过原始套接字轻松绕过 | | 透明代理 (iptables 重定向) | 2 | 3 | **不透明**：无论进程如何，所有流量都被重定向 | | 内核/hypervisor 网络过滤器 | 3 | 2 | **不透明**：iptables、eBPF 或 Network Extension | | MITM 代理 (内核重定向) | 2–3 | 3 | **不透明**：TLS 终止；每 URL/方法策略 | | 默认拒绝 + 例外 | 3–4 | 2–3 | **不透明/结构性**：所有出口被阻止；仅允许列表 | | 网络禁用 | 4 | 1 | **结构性**：不存在网络接口 | ## A.5 — L5 凭证 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无限制 | 0 | 0 | 完整凭证集可见 | | 敏感文件阻止 | 3 | 2 | 通过 L3 阻止凭证文件；环境变量仍然可见 | | 环境变量过滤 | 2 | 2 | 仅转发批准的变量 | | 占位符替换 | 3 | 3 | 秘密替换为令牌；仅在执行时恢复 | | 外部凭证代理 | 4 | 3 | 凭证从不进入沙箱 | | 临时每会话令牌 | 4 | 3 | 有时间限制、范围限定的凭证；自动过期 | ## A.6 — L6 操作治理 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无治理 | 0 | 0 | Agent 可以做任何它有权访问的事情 | | 人在回路中 | 1 | 1 | Agent 提议；人类批准 | | 命令阻止列表 | 2 | 2 | 阻止已知的危险命令 | | 策略引擎 | 2 | 3 | 每操作/资源/上下文的细粒度规则 | | 仅声明模式 | 3 | 3 | Agent 仅生成声明；无法直接执行 | ## A.7 — L7 可观测性 | 机制 | S | G | 工作原理 | |---|---|---|---| | 无日志 | 0 | 0 | 无 Agent 操作记录 | | 会话级日志 | 1 | 1 | 开始/停止，退出代码 | | 命令级审计 | 2 | 2 | 记录每个命令、文件操作、工具调用 | | 全量遥测 | 3 | 3 | 网络、syscall、MCP 调用、实时 UI | | 加密审计链 | 3 | 3 | 带有加密承诺的防篡改日志 | # 附录 B：产品评分卡 每个产品在每一层的评分为 `S.G` (Strength.Granularity)。`0` = 层级运作但未强制执行；`—` = 层级未解决（参见[指纹](#the-fingerprint)）。所有分数维护在 [`products.yaml`](products.yaml) 中。

有关每个产品的完整详细信息（粒度分数、机制说明、威胁分解、差距和补充），请参见 [`products.yaml`](products.yaml)。 # 附录 C：威胁覆盖矩阵 威胁覆盖范围是使用第 3 节中的[阈值规则](#threat-assessment-rules)从层级分数中**机械地**推导出来的。**●** 已解决 —— 所有主要防御层都达到 S >= 2。**◐** 部分 —— 至少一个主要层达到阈值但不是全部。**○** 未解决 —— 没有主要层达到阈值。T3 分为本地 (L1+L3) 和远程 (L4+L6)：`L●/R○` = 本地已缓解/远程未缓解；`full L+R` = 两者都缓解。

**模式**：每个 L1 >= 2 且 L3 >= 2 的产品都达到 T3-Local ●。T3-Remote 是最敏锐的区分因素 —— 只有 L4 >= 2 且 L6 >= 2 的产品才能达到 ●。三种产品实现了全 ● 覆盖：Google Agent Sandbox、Claude Code (web) 和 Copilot coding agent —— 都结合了云管理的临时 VM 以及 L4 >= 2 和 L6 >= 2。没有产品得分为 T7:○，因为每个产品都有 L1 >= 2。 ### 组合示例 ``` L1/L2/L3/L4/L5/L6/L7 E2B 4/ 4/ 4/ 2/ 1/ -/ 1 + Stakpak Warden 2/ 0/ 2/ 2/ 2/ 2/ 2 ────────────────────────────────────────────────── = Composed (max) 4/ 4/ 4/ 2/ 2/ 2/ 2 ← gaps filled ``` ``` L1/L2/L3/L4/L5/L6/L7 Claude Code (local) 3/ -/ 3/ 3/ 1/ 2/ 2 + nono 3/ -/ 3/ 3/ 3/ 3/ 3 ────────────────────────────────────────────────── = Composed (max) 3/ -/ 3/ 3/ 3/ 3/ 3 ← only L2 uncovered ``` # 结论 Agent Sandbox Taxonomy 提供了一套通用词汇 —— **7 层防御层**、**7 种威胁类别**、**3 个评估维度** —— 用于描述任何 Agent Sandbox 做什么和不做什么。 **三个要点：** 1. **没有单一产品能很好地覆盖所有七层。** 云平台擅长 L1–L3（隔离边界），但让 L4–L7（网络、凭证、治理、可观测性）敞开。策略工具覆盖上层，但没有计算边界。这种互补性是设计使然 —— 组合不是可选的，它是预期的部署模型。 2. **最常见的配置是最危险的。** 具有 unrestricted network access 和作为环境变量的原始凭证的 microVM 看起来很安全。指纹揭示了真相：L4:0 意味着窃取只需一次 `curl`。在信任营销之前务必检查指纹。 3. **沙箱和 Agent 对齐是独立的问题。** 让 Agent 做出好的决策（对齐）和限制它在做出坏决策时的损害（沙箱）是互补但独立的。两者都要投资。两者不能互相替代。 [分类体系（第 1–5 部分）](#the-taxonomy)和[框架（第 6–8 部分）](#the-framework)应保持稳定。[附录（A–C）](#appendix-a-layer-mechanism-reference)随着产品发展而更新 —— 编辑 [`products.yaml`](products.yaml) 并运行 `uv run python scripts/generate.py` 以重新生成视觉效果。 *欢迎反馈。*

标签：Agentic AI, CISA项目, LLM, Unmanaged PE, Web报告查看器, 分类学, 反取证, 大模型安全, 威胁模型, 安全基准, 安全评估, 沙箱逃逸, 系统隔离, 网络安全, 网络安全审计, 评分框架, 逆向工具, 防御层, 防护策略, 隐私保护, 风险分析