系列说明：上一篇英伟达AI安全平台- Open Agent Safety Platform 解读（OpenShell / Sentry 全栈拆解）重点分析平台架构、OpenShell 与 Sentry 的定位，以及它与 AI Gateway、Guardrail 和身份治理的关系。这篇把视角收回到可实际部署的 OpenShell。

实验环境：Windows + WSL2（Ubuntu 24.04）+ Docker Desktop；OpenShell v0.1.2；OpenClaw 2026.9.9

阅读提示：本文是单一环境下的工程记录，不是通用部署指南，也不构成安全保证。文中的“实测”“官方资料”“推断/待验证”分别标注。本文验证的是 OpenShell 软件运行时；没有部署 NVIDIA Sentry 或 BlueField-4，因此不把硬件层能力写成自己的实测结果。

一、从“看懂方案”到“动手验证”

上一篇文章回答的是：NVIDIA 为什么要把智能体安全从模型输入输出控制，进一步扩展到运行时执行与硬件基础设施层？OpenShell 与 Sentry 分别处在哪一层？

这次我想回答更具体的问题：把 OpenShell Sandbox 接到 OpenClaw 后，工具动作是否真的进入沙箱？网络策略是否在运行时生效？策略能否被形式化检查？有没有工具仍然在宿主机执行？

起点是 OpenClaw 升级到 2026.9.9 后，我在插件市场里看到了 OpenShell Sandbox。于是，我在 Windows + WSL2 + Docker Desktop 环境中完成接入，并把重点放在可复现的运行时测试上。

这次实践，我总结出了智能体安全的八字口诀：

知行分离，持续验证。

知行分离：模型负责理解任务、推理和提出动作；执行动作的工具与运行环境则必须接受独立策略约束。不能因为模型说“我已经获得授权”，就直接相信它；也不能假设配置了沙箱，就代表每一个工具都自动进入了沙箱。

持续验证：一次策略配置成功，不代表所有边界都成立。要通过网络拒绝与放行对照、文件越界测试、工具执行位置检查、策略形式化验证和日志证据，持续回答一个问题：Agent 的动作是否真的经过预期的安全边界？

这篇文章不只记录“怎么搭起来”，也记录“哪些验证通过了、哪些结论还不能下”。上一篇中的 Sentry / BlueField-4 仍作为整体方案背景保留；由于本次没有对应硬件，本文不会将其描述为实测结果。

先看openshell 的架构图：

再看本次实验图部署拓扑：

二、先厘清架构：谁负责决策，谁负责执行？

2.1 本次实测的调用链

本次采用的是 OpenClaw 插件桥接模式。在这一模式中，模型推理由宿主机上的 OpenClaw 完成，部分工具执行被 OpenShell 插件路由到沙箱中。实际调用链如下：

用户在 Web Chat 发出任务          
        ↓          
宿主机 OpenClaw 调用模型，得到工具调用意图          
        ↓          
OpenClaw 工具调度与沙箱后端          
        ↓          
OpenShell 插件 / CLI → OpenShell Gateway          
        ↓          
沙箱运行时创建的 workload + supervisor          
        ↓          
workload 内执行命令；文件和网络访问受策略约束          
        ↓          
执行结果返回 OpenClaw，再交给模型继续处理

这里有一个边界必须说明：这张链路图只描述本次 OpenClaw 桥接部署，不代表所有 OpenShell 部署都把 Agent 的推理过程放在宿主机。 OpenShell 也可以用于在沙箱环境中启动 Agent。

2.2 组件怎么分工

组件	本次实践中的职责	需要记住的边界
Workload / Sandbox	在隔离环境中承载命令和工具执行	它不是可信决策者，不能自行决定扩大权限
Supervisor	处于受保护边界外，执行运行时策略检查，代理受控网络访问，并处理相关凭据	它会在数据面实施策略，不是“完全不参与策略判断”
Gateway	管理沙箱生命周期、身份认证、策略与凭据配置、连接协调等	主要属于控制平面；不应与每次请求的数据面判定混为一谈
Policy	描述文件、进程、网络目标和可执行请求的授权边界	策略文件存在不等于策略已经生效，需确认运行时加载状态
Policy Prover	检查候选策略是否超出指定安全边界	形式化检查只覆盖其建模范围，不代替运行时旁路测试
NVIDIA Sentry + BlueField-4	NVIDIA 公开平台方案中的可选独立硬件监测与执行层	本次没有部署，以下仅讨论公开资料明确描述的能力及未公开细节

OpenShell 官方架构说明：Gateway 管理沙箱生命周期并提供管理与连接能力；创建沙箱时，运行时会创建 workload 和独立 supervisor、建立受保护通道与隔离边界；Supervisor 在确认边界后再连接 Gateway 获取策略、凭据、日志和交互会话。

2.3 “知行分离”不是只装一个容器

本次环境中，文件、进程和网络访问分别由不同机制约束：

控制机制	主要作用	不应误解成什么
Landlock	在 Linux 内核层限制进程可访问的文件系统路径	不是对所有宿主机资源的万能隔离保证
Seccomp BPF / user notification	过滤系统调用；在 OpenShell 的 Linux 后端中，还会把特定网络操作交给受控路径处理	它本身不是按域名或 HTTP 路径作最终授权判断的策略引擎
外层网络隔离	阻止 workload 绕开受保护通道直接出网	不能单凭“请求很快失败”就认定一定是策略拒绝
Supervisor 网络代理与策略引擎	依据程序身份、目标地址及受支持的应用层规则检查网络请求	不能推断所有程序、所有协议都能被同等深度地解析
Gateway	管理身份、沙箱、策略和生命周期	不代表配置后便自动验证了所有工具路径

网络控制之所以重要，是因为仅仅限制 Agent 的文件系统还不够：它仍可能通过合法可执行文件向外发送数据。反过来，只做网络白名单也无法限制它读取哪些本地文件。因此，这些控制需要协同工作。

更准确地说，在 OpenShell 的 Linux 后端里，Seccomp 的作用包含将特定网络操作交由 Supervisor 处理；而目标主机、端口以及受支持的 REST 请求规则，最终由 Supervisor 侧的策略机制判断。不要把“Seccomp 参与网络调用的拦截路径”误写成“Seccomp 自己理解域名和 HTTP 语义”。

三、按 Agent 配置策略：不只看配置文件，要看生效策略

本次为两个 OpenClaw Agent 分别创建了 OpenShell 沙箱：

·main：具身智能安全研究，侧重论文、机器人与安全资料站点。

·anguanghui：AI 安全研究，侧重漏洞情报、MITRE、GitHub 与安全文档。

【实测】两个沙箱拥有各自的策略，网络放行范围并不相同。这证明了本次环境可以按沙箱维护不同的网络策略，但不能据此概括所有插件默认行为或所有部署方式。

下图为运行的两个智能体的沙箱，每个智能体2个。

3.1 一个代表性网络策略

以下是压缩后的示例，展示策略如何把“可访问的目标”和“可发起请求的程序”绑定起来。实际部署应依据任务最小化授权，而不是直接照抄白名单。

version: 1          
network_policies:          
  security_intel_nvd:          
    endpoints:          
      - host: nvd.nist.gov          
        port: 443          
        protocol: rest          
        enforcement: enforce          
      - host: services.nvd.nist.gov          
        port: 443          
        protocol: rest          
        enforcement: enforce          
    binaries:          
      - path: /usr/bin/curl

这条规则的设计意图是：允许指定程序访问明确列出的安全情报站点，而不是给沙箱开放任意出网权限。若要开放 API 的特定方法或路径，还必须确认所用协议规则和当前 OpenShell 版本支持相应限制。

3.2 Base Policy、Effective Policy 与 Global Policy

这是配置时最容易踩坑的地方。

概念	含义
Base Policy	用户为沙箱设置的基础策略
Effective Policy	实际执行策略；通常由基础策略与已附加 Provider 贡献的规则组合而成
Global Policy	Gateway 管理员应用到所有沙箱的全局策略

重要：Global Policy 是替代式来源，而不是简单叠加在每个沙箱策略上的“权限上限”。 官方策略文档说明，全局策略激活时会替换沙箱自身策略，并抑制 Provider 贡献的策略规则；此时沙箱策略修改与提案审批也会受到限制。因而，部署了 Global Policy 并不等于每个 Agent 都自动通过了独立的边界证明。

3.3 常用策略检查命令

# 沙箱列表          
openshell sandbox list          

# 查看基础策略 / 完整生效策略          
openshell policy get <沙箱名> --base          
openshell policy get <沙箱名> --full          

# 查看策略历史与加载状态          
openshell policy list <沙箱名>          

# 导出当前策略，供评审或 Policy Prover 使用          
openshell sandbox get <沙箱名> --policy-only > candidate.yaml          

# 增量更新网络规则（示例字段需按实际策略调整）          
openshell policy update <沙箱名> --rule-name security_intel_nvd \          
  --binary /usr/bin/curl \          
  --add-endpoint nvd.nist.gov:443:read-only:rest:enforce --wait

本次实验观察到：网络规则可以通过策略更新热加载；filesystem_policy、landlock 和 process 等设置则在沙箱启动/创建阶段生效。沙箱重建前，应先明确新实例会继承哪一份策略、Provider 和配置，再重新核验加载状态。不要仅凭旧实例上的测试结果推断新实例仍具有同样的边界。

四、实测结果：哪些通过了，哪些还不能下结论？

4.1 主要测试结果

测试项	本次观察	可以得出的结论
默认网络访问	curl https://example.com 很快失败（约 1 ms）	说明请求未成功；单凭耗时不能证明是策略拒绝，仍需日志佐证
放行后的网络请求	curl https://nvd.nist.gov 收到 HTTP 403	网络已建立到足以收到 HTTP 响应；不代表业务请求成功
网络规则热更新	策略版本递增，并显示已加载	本次规则更新路径可用；仍需以实际访问对照验证规则效果
二进制路径检查	readlink -f /usr/bin/curl 返回 /usr/bin/curl	确认了该路径解析结果；尚不能独立证明二进制身份控制已生效
Agent 与沙箱关系	scope=agent 场景仅创建一个沙箱	记录了本次配置下的行为，不能推广到其他 scope 或版本
自建镜像	Python 3.12.3 可用	解决了该镜像缺少 Python 导致的工具依赖问题

其中，HTTP 403 的价值在于它与“本地立刻连接失败”不同，说明请求至少收到了对端 HTTP 层的响应；但如果要证明应用请求成功，还必须进一步检查响应内容和业务结果。

4.2 文件与宿主机旁路测试

本次做了 9 项直接检查，包括尝试读取宿主机专有文件、访问 /root、写入 /etc 与 /usr、读取 /etc/shadow、比较宿主机与沙箱执行身份，以及确认远程执行生成的文件是否会自动出现在宿主目录等。

【实测】上述测试中，未发现直接的文件系统或执行旁路：越界访问得到 Permission denied，宿主机专有文件在沙箱内不可见，宿主与沙箱的执行身份也不同。

但这句话应准确写成：“在本次测试范围内，未发现直接的文件/系统旁路。” 它不是对所有内核攻击、容器逃逸、符号链接边界或所有工具路径的完整安全证明。

4.3 最有价值的发现：工具执行面并不只有一类

检查 OpenClaw 的工具执行路径后，我把工具分成了三类：

类别	本次观察到的工具	安全含义
沙箱路由	exec、process、read、ls、write、edit、apply_patch、view_image 等	这些工具在本次配置中进入沙箱并受对应运行时策略约束
直接不可用/被拒绝	browser、canvas、computer、mobile_ui、nodes、automations、gateway 以及部分渠道工具	本次不可调用，不应把“被拒绝”误报成“已被沙箱保护”
宿主侧执行	sessions_list、sessions_history、sessions_search、sessions_send、sessions_spawn、sessions_yield、subagents、session_status 等	它们属于 OpenClaw 宿主侧会话协调能力，不受容器内 Landlock 与网络代理策略直接约束

这是全文最值得关注的部分。沙箱只约束真正进入沙箱的执行路径，不会自动约束框架所有宿主侧工具。sessions_history 和 sessions_search 涉及会话记录读取，可能触及不同会话的数据边界；sessions_spawn / subagents 则需要单独验证新派生的 Agent 是否获得了正确的沙箱配置。

五、Policy Prover：不是比较文本，而是检查权限边界

策略文件的文字差异，不等于权限差异。一个规则可能只是换了写法，也可能扩大了真实访问范围。Policy Prover 的价值是把策略转换为可求解的约束，检查候选策略是否超出人为定义的边界。

5.1 本次执行方式

# 导出生效策略          
openshell sandbox get <沙箱名> --policy-only > candidate.yaml          

# 与独立边界策略比较，并输出 JSON 结果          
openshell-prover check candidate.yaml \          
  --boundary boundary.yaml \          
  --output json > result.json

5.2 本次观测到的结果

将安光辉沙箱的生效策略导出为 candidate，并与一份有意设得更严格的 boundary 比较，得到：

result: exceeds_boundary          
coverage: domains=filesystem,network_l4,network_rest,process,landlock          
counterexample: network host=api.deepseek.com:443 protocol=rest method=GET path=/          
exit_code=1

这意味着：在本次 Prover 建模和覆盖的范围内，候选策略存在一条 boundary 不允许的网络访问。 反例指出了需要检查的具体目标、协议、方法和路径，帮助定位到底是哪项权限越界。

另一次测试中，boundary 使用 include_workdir: true，Prover 返回 unsupported，原因是镜像工作目录的权限范围无法解析。这一点同样重要：`unsupported` 不是通过，不能把未建模的情况当成安全。

结果	本次处理原则
within_boundary	在报告覆盖范围内通过边界检查，仍需运行时测试
exceeds_boundary	按越界处理，审查反例并修改策略
error	策略或输入存在问题，先修复再验证
unsupported / inconclusive	不作为通过；补足模型条件、简化策略或人工审查

建议把以下材料一起归档：boundary.yaml、candidate.yaml、result.json、OpenShell / Prover 版本、策略修订版本，以及对应的运行时旁路测试结果。对于关键策略，可以把 Prover 检查放进变更流程；需要注意，是否自动在沙箱启动时运行 Prover，要以对应版本的具体实现为准，不能默认它已经自动阻断所有未经证明的策略。

六、从 OpenShell 到 Sentry

上一篇已对 Open Agent Safety Platform、OpenShell 与 Sentry 的总体架构做过拆解，本节只聚焦本次实测的边界。

NVIDIA 公开的参考方案描述了 OpenShell 软件运行时与 BlueField-4 DPU 上的 Sentry 组合。公开资料说明了其硬件侧观测与执行目标，但本次实验环境没有部署 Sentry 或 BlueField-4，因此本文只能核对公开资料和 OpenShell 已有的事件能力，不能声称完成了硬件层验证。

6.1 本次环境与参考方案的区别

能力	本次状态
OpenShell 软件运行时	已部署并实测
沙箱网络策略与热更新	已测试
Policy Prover	已执行并记录结果
NVIDIA Sentry	未部署
BlueField-4 DPU	未部署
OpenShell 与 Sentry 的实际数据对接	未实测；公开文章没有给出完整接口协议与事件格式

6.2 Sentry 的数据从哪里来？哪些仍然未知？

目前能确认的是：

·OpenShell 自身会记录网络连接、进程生命周期、文件系统策略决定和配置变化，并提供结构化安全事件。

·NVIDIA 公开文章描述 Sentry/DOCA 与 OpenShell 策略进行关联，并在 BlueField-4 所处的受控路径上提供带外观测和策略执行。

·但仅凭公开博客，还无法确认 OpenShell 与 Sentry 的完整内部接口、传输协议、事件字段、策略下发拓扑，也无法认定所有 OpenShell 审计日志都会被直接推送给 Sentry。

·DPU 能观察受控网络路径上的活动，不意味着它天然能够读取所有本地文件操作；对于主机内活动，需要有相应的运行时事件源和可信关联机制。

·网络数据包可见性不等同于 HTTPS 明文可见性。能否检查请求正文，取决于实际部署中是否存在相应的应用层观测能力。

因此，本文不把“Supervisor 将每一条 allow/deny 日志通过某个带外协议推送给 Sentry”画成已确认事实，也不把毫秒级隔离作为本地实测结论。对于具体接入协议、事件来源及隔离动作，仍需进一步取得官方技术细节或硬件环境进行验证。

6.3 普通 x86 + Docker 能替代硬件层吗？

不能简单画等号。本次已经验证的是普通 x86 环境里的 OpenShell 软件隔离与策略执行；NVIDIA 所述 BlueField-4 硬件层强调的是独立于主机软件的监测与执行能力。两者是不同信任边界，不能仅因软件层测试通过，就宣称达到了硬件层的全部安全目标。

七、执行安全不等于内容安全

OpenShell 的核心任务是控制 Agent 能访问什么、能执行什么、能连接哪里。这与判断“模型输入是不是提示注入”“输出是否泄露敏感信息”“内容是否符合行业合规要求”是不同的安全问题。

沙箱可以阻止一次未经授权的文件写入或网络连接，但它不一定能判断某条输入是不是恶意提示注入；反过来，内容检测能发现可疑输入输出，也不能代替内核和运行时的实际访问控制。

因此，企业级方案需要分层看待：

安全层	主要问题	典型控制方向
内容与模型交互安全	提示注入、越狱、敏感信息泄露、有害输出	模型输入输出检测、脱敏、内容策略、审计
Agent 执行安全	文件、进程、网络、工具调用是否越权	OpenShell 沙箱、最小权限策略、执行前检查
独立硬件监测与执行	主机不完全可信时如何维持额外观测与执行能力	在适用的硬件部署中评估 Sentry / BlueField-4

这些层次互补，但不能据此推断某个产品已经完整覆盖全部风险。具体覆盖范围必须通过产品文档、部署设计和实测共同确认。

八、下一步怎么验证：按优先级做闭环

优先级	实验	目标与验收标准
P0	sessions_* 跨会话读取实测	使用专门构造的无敏感测试内容，确认可读范围、访问控制与审计记录；避免直接用真实私密数据试验
P0	sessions_spawn / subagents 继承验证	检查派生 Agent 的执行位置、沙箱创建情况和生效策略，确保没有未经授权的宿主侧执行路径
P1	二进制身份对照	只给 /usr/bin/curl 授权后，用其他程序访问同一目标；结合运行时日志判断实际执行策略，而非只看退出码
P1	文件边界细化	检查工作目录、符号链接、SSH 配置目录等边界，并保存拒绝事件与环境信息
P1	策略生命周期	分别验证网络热更新、沙箱重建、Provider 变化和策略回滚；比较基础策略与生效策略
P1	日志证据	记录 allow/deny 的结构化事件，使用日志佐证“为什么失败”，而不是用 1 ms 的耗时推断原因
P2	Prover 接入变更流程	每次策略变更归档 boundary、candidate、JSON 结果及版本；非通过状态不能静默放行
P2	内容安全层接入	与沙箱结合验证输入检测、输出检测、脱敏和审计效果
硬件专项	Sentry / BlueField-4 实证	在有硬件和明确接口文档的环境中核实观测来源、事件关联、策略执行和隔离时延

九、结论：从方案认知走向工程验证

如果说上一篇的重点是理解 NVIDIA Open Agent Safety Platform 的设计思路，那么这篇实操得出的结论更具体：OpenShell 的价值不在于“给 Agent 套一个容器”，而在于把执行路径变成可以配置、观察和验证的安全边界。

这次实践完成了以下验证：

·OpenClaw 可以通过插件桥接，将本次测试中的命令和文件工具路由到 OpenShell 沙箱执行。

·网络默认拒绝、按规则放行、网络规则热更新等行为在本环境下得到测试。

·9 项文件/系统旁路检查中，未发现直接旁路；结论仅限本次测试范围。

·两个 Agent 的沙箱可以维护不同的网络策略。

·Policy Prover 能给出可定位的越界反例，也会对未建模情况返回 unsupported。

·发现部分 sessions_* / subagents 协调工具位于宿主侧，需要进一步验证它们的权限边界和子 Agent 策略继承。

同时，这次实践还没有完成：跨会话读取的受控验证、子 Agent 沙箱继承验证、全部策略拒绝原因的日志取证、内容安全层接入，以及 Sentry / BlueField-4 的硬件实测。

最后回到那八个字：

**知行分离**：模型可以提出动作，但不能自己决定权限；工具只有真正经过受控执行路径，才算处在边界内。

**持续验证**：策略会变、沙箱会重建、工具会新增。只有形式化检查、运行时证据与旁路测试形成闭环，才能知道边界是否仍然有效。

附FAQ

Q1：OpenShell Sandbox 能接入 OpenClaw，是因为 OpenClaw 有专门的配置接口吗？

并非专属定制接口。OpenClaw 提供通用可插拔沙箱后端扩展点，OpenShell 插件基于该扩展点完成接入实现。

  
  
  
  

   
   
   
   

    
    
    
    

    
    
    
    

    
    
    
    

    
    
    
    

    
    
    
    

   
   
   
   
   
   
   
   
OpenClaw 的沙箱后端抽象      ↓ 实现OpenShell 插件（registerSandboxBackend）      ↓ 选择agents.defaults.sandbox.backend = "openshell"
  
  
  
  

该扩展体系支持多类后端，Docker、SSH、OpenShell 均为通用实现，OpenShell 只是其中一种沙箱后端方案。

Q2：脱离 OpenClaw，其他智能体如何使用 OpenShell？

OpenShell 是独立产品，无 OpenClaw 依赖。所有智能体/框架均可通过以下三种通用方式接入：

接入方式	适用场景	核心说明
CLI 命令行	所有可执行命令的智能体	通过 openshell sandbox exec -n <沙箱> -- <命令> 直接执行沙箱指令
SSH 隧道	支持 SSH 连接的框架/工具	依托网关 SSH 端点，通过 ssh -F <config> 快速连接沙箱
MCP 协议	支持 MCP 的 AI 客户端	官方提供标准 MCP Server，开箱即用

OpenClaw 插件的差异化价值：自动生命周期管理、工作区同步、文件工具桥接。通用接入方式需用户自行实现以上能力。

Q3：智能体执行动作的沙箱接管原理是什么？为何沙箱可以替代本机执行？

核心原理：智能体本身无原生执行权限，所有操作必须经过框架中转。

智能体仅负责输出操作意图，真实系统调用由框架翻译、分发，执行目标可动态替换。

  
  
  
  

   
   
   
   

    
    
    
    

    
    
    
    

    
    
    
    

    
    
    
    

    
    
    
    

   
   
   
   
   
   
   
   
智能体（模型）产出意图：{tool:"exec", cmd:"ls"}      ↓（唯一必经链路）框架翻译为真实系统调用      ↓框架决定执行位置（本机 / 沙箱，可无缝切换）
  
  
  
  

执行链路改造对比：

• 改造前：智能体 → 框架执行 → 本机 Shell

• 改造后：智能体 → 框架执行 → OpenShell 沙箱 → 容器内 Shell

整个切换过程智能体完全无感知，仅负责发起请求、接收执行结果。

业界三种主流沙箱接管方案：

1. PATH 劫持（替换可执行文件）：适用于 CLI 类智能体

2. 代码级替换执行函数：适用于框架型智能体（OpenClaw 采用该方案）

3. 网络层替换连接目标：适用于 SSH 连接型工具

关键前提：所有动作必须经过框架中转。若存在绕过框架的宿主侧工具调用，则无法被沙箱接管，这也是实践中 sessions_* 相关场景不受沙箱管控的核心原因。

Q4：本次 OpenShell 沙箱实践的核心观点总结

核心主旨：知行分离，持续验证

• 知行分离：将智能体的「推理认知（知）」与「操作执行（行）」拆分至不同信任域；所有执行动作必须经过不可绕过的 Supervisor 管控层，是沙箱接管的核心技术底座。

• 持续验证：安全边界无法永久固化。策略漂移、沙箱重建、新增工具都会破坏原有安全规则，必须通过形式化验证、常态化旁路测试持续校验。

核心结论：单次跑通不代表永久安全，持续校验才是沙箱安全的关键。