文章总结： 本文提出智能体安全八字口诀知行分离与持续验证，强调模型决策与工具执行需独立策略约束。通过OpenShell沙箱接入OpenClaw的实践，验证了网络策略热加载、文件系统隔离及工具执行路径分类，发现宿主侧会话工具不受沙箱直接约束，需持续验证策略生效边界。
综合评分： 82
文章分类： 安全意识,安全工具,解决方案,实战经验
智能体安全八字口诀：知行分离，持续验证
dimu
dimu
AI简化安全
2026年10月11日 00:45
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
系列说明：上一篇英伟达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
整个切换过程智能体完全无感知，仅负责发起请求、接收执行结果。
业界三种主流沙箱接管方案：
- PATH 劫持（替换可执行文件）：适用于 CLI 类智能体
- 代码级替换执行函数：适用于框架型智能体（OpenClaw 采用该方案）
- 网络层替换连接目标：适用于 SSH 连接型工具
关键前提：所有动作必须经过框架中转。若存在绕过框架的宿主侧工具调用，则无法被沙箱接管，这也是实践中 sessions_* 相关场景不受沙箱管控的核心原因。
Q4：本次 OpenShell 沙箱实践的核心观点总结
核心主旨：知行分离，持续验证
- 知行分离：将智能体的「推理认知（知）」与「操作执行（行）」拆分至不同信任域；所有执行动作必须经过不可绕过的 Supervisor 管控层，是沙箱接管的核心技术底座。
- 持续验证：安全边界无法永久固化。策略漂移、沙箱重建、新增工具都会破坏原有安全规则，必须通过形式化验证、常态化旁路测试持续校验。
核心结论：单次跑通不代表永久安全，持续校验才是沙箱安全的关键。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：AI简化安全 dimu
dimu《智能体安全八字口诀：知行分离，持续验证》