ZeroClaw 安全策略完全指南自主级别、沙箱分层与容器硬化实践【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclawZeroClaw 是一套可部署在任意系统、任意平台上的自主 AI 个人助理基础设施。本文以仓库根目录的 SECURITY.md 为骨架完整展开其安全模型从受支持版本的修复承诺、漏洞上报流程到三级自主级别Autonomy Levels与五层沙箱防护的纵深防御架构再到 129 个自动化安全测试与符合 CIS Docker Benchmark 的容器硬化方案。读完本文你将掌握 ZeroClaw 的威胁模型、如何在生产环境验证容器镜像的 non-root 与只读文件系统配置以及如何结合源码确认每一层安全机制的落地位置。版本支持策略只维护最新 minor 线ZeroClaw 的漏洞修复遵循单线维护原则安全修复只跟随最新发布线latest release line没有维护分支maintenance branches早期 minor 版本不会收到回溯补丁backported fixes。版本是否受支持最新发布的 minor 线✅ 受支持更早的 minor 线❌ 不受支持以官方文档给出的示例若最新发布版本为0.8.6则受支持的 minor 线是0.8.x0.7.x及更早的版本线均不再受支持。这意味着两件事其一升级到最新版本是你获得安全修复的唯一途径——文档明确要求在报告之前请先升级到最新发布版若问题仍可复现再按下述流程上报其二评估漏洞影响面时应始终以最新版本行为为准旧版本存在的安全问题不会单独发补丁。负责任地报告漏洞私密通道与响应时限不要在公开渠道public GitHub issue提交安全漏洞。SECURITY.md 规定了两条上报通道邮件 / GitHub 私密通道通过 GitHub 的 private vulnerability reporting 联系维护者GitHub Security Advisories使用 GitHub Security Advisories 新建私密安全公告。上报时建议包含以下四类信息漏洞描述Description of the vulnerability复现步骤Steps to reproduce影响评估Impact assessment建议修复方案Suggested fix如有官方承诺的响应时间线Response Timeline如下阶段时限确认收到Acknowledgment48 小时内评估Assessment1 周内关键问题修复Fixcritical issues2 周内这套流程与仓库的发布契约一脉相承安全补丁集中在最新发布线、按固定节奏发布配合上述时限承诺让关键漏洞的披露到修复周期是可预期的。安全架构以自主级别为核心的纵深防御ZeroClaw 的安全体系建立在**纵深防御defense-in-depth**之上第一层即自主级别——决定 Agent 能在多大程度上脱离人工干预执行动作。三级自主级别级别能力边界ReadOnlyAgent 只能读取无 shell、无写入权限Supervised默认Agent 可在 allowlist白名单范围内行动FullAgent 在工作区沙箱内拥有完整访问权限从源码看该枚举定义于 crates/zeroclaw-config/src/autonomy.rsAutonomyLevel按最小自主到最大自主排序序列化为小写字符串其中Supervised标注为#[default]——与 SECURITY.md 中Supervised默认的描述一致也与 src/security/mod.rs 中SecurityPolicy::default()断言autonomy AutonomyLevel::Supervised的测试互相印证。自主级别不是摆设而是直接参与系统提示词system prompt构造的运行时事实在 crates/zeroclaw-runtime/src/agent/system_prompt.rs 中ReadOnly会收敛工具集并禁止写入动作Supervised要求高风险操作经批准Full才放开自主执行。换句话说同样的模型、同样的工具注册表在不同自主级别下拿到的是不同能力的系统提示词级别越低Agent 可见的武器越少。五层沙箱防护SECURITY.md 列出了 5 层叠加的沙箱机制工作区隔离Workspace isolation——所有文件操作被限制在工作区目录内路径穿越阻断Path traversal blocking——拒绝..序列与绝对路径命令白名单Command allowlisting——只允许显式批准的指令执行禁入路径列表Forbidden path list——/etc、/root、~/.ssh等关键系统路径始终被封锁速率限制Rate limiting——每小时最大动作数与每日成本上限。这些机制对应到源码中是成体系的安全子模块。安全子系统集中在 crates/zeroclaw-runtime/src/security/mod.rs并在根 crate 的 src/security/mod.rs 中整体 re-export 供 CLI 使用。该目录下的模块直接对应上述防护目标沙箱执行器bubblewrap、firejail、landlockLinux、seatbeltmacOS按目标平台条件编译配合detect.rs的create_sandbox与sandbox_posture探测实际沙箱形态策略与批准policy.rs承载SecurityPolicy/AutonomyLevelapproval相关逻辑负责 Supervised 级别下高风险工具的事前批准命令与文件工具shell / file 类工具的 allowlist 校验是第 3、4 层的落地位置成本护栏[cost]配置与速率限制配合构成第 5 层防失控开销的兜底。值得强调的是禁入路径列表与命令白名单的叠加效果即使 Agent 处于Full级别也仍然被工作区边界和禁入路径约束Full不等于裸奔只是在策略边界内自主。主要防护对象威胁面SECURITY.md 明确列出该系统防范的攻击类型路径穿越攻击如../../../etc/passwd——由第 2 层路径穿越阻断拦截命令注入如rm -rf /、curl | sh——由第 3 层命令白名单拦截通过符号链接或绝对路径逃逸工作区——由第 1、2 层拦截LLM API 调用导致的失控成本——由第 5 层速率限制 / 成本上限拦截未授权的 shell 命令执行——由第 3 层拦截。这也是为什么配置中存在[risk_profiles.*]容器默认配置见下文 Dockerfile 生成的/zeroclaw-data/.zeroclaw/config.toml即定义了level supervised的默认风险画像并为file_read、file_write、file_edit、memory_recall、memory_store、web_search_tool、web_fetch、calculator、glob_search、content_search、image_info、weather、git_operations等工具配置了auto_approve白名单——这就是Supervised allowlist默认姿态的实例。安全测试129 个自动化用例守护每条防线所有安全机制都由自动化测试覆盖SECURITY.md 给出的测试入口如下cargo test -- security cargo test -- tools::shell cargo test -- tools::file_read cargo test -- tools::file_write这些测试的可信度可以从源码侧进一步佐证src/security/mod.rs 内嵌测试验证SecurityPolicy::default()的自主级别为Supervised、PairingGuard的配对要求默认关闭、SecretStore的加密/解密往返一致以及redact对敏感值的脱敏行为含多字节 UTF-8 边界安全——redact(密码是很长的秘密)不会因按字节切片而 panicredact的实现在 crates/zeroclaw-runtime/src/security/mod.rs长度 ≤4 时整体替换为***否则保留前 4 个字符加***后缀用于日志与审计场景避免敏感信息泄露tools::shell/tools::file_read/tools::file_write对应 src/tools 下的工具实现命令白名单、路径穿越、禁入路径的校验正是在这些工具的调用链上执行的。此外SECURITY.md 强调测试数量为 129 个覆盖所有安全机制——这既包括上述策略与脱敏单元测试也包括组件级测试如 tests/component/security.rs对安全边界的验证。容器安全对齐 CIS Docker BenchmarkZeroClaw 的 Docker 镜像按CIS Docker Benchmark 最佳实践构建SECURITY.md 给出的对照表如下控制项实现方式4.1 非 root 用户容器以 UID 65534distroless nonroot运行4.2 最小化基础镜像gcr.io/distroless/cc-debian13:nonroot—— 无 shell、无包管理器4.6 HEALTHCHECK不适用无状态 CLI/gateway5.25 只读文件系统支持docker run --read-only配合/workspace卷源码级的镜像硬化证据对照 Dockerfile 可以逐条核实这些声明生产阶段release stage直接基于gcr.io/distroless/cc-debian13:nonroot且该镜像以 digestsha256 固定摘要锁定杜绝基础镜像被篡改USER 65534:65534在 dev 与 release 两个运行时阶段都显式设置配合chown -R 65534:65534 /zeroclaw-data确保数据目录归属 nonroot 用户数据与配置位于/zeroclaw-dataENV ZEROCLAW_DATA_DIR/zeroclaw-data/data、ENV HOME/zeroclaw-data工作区作为可写挂载点与只读根文件系统解耦——这正是docker run --read-only可行性的基础默认配置即安全默认镜像内生成的config.toml将[risk_profiles.default]设为level supervised并预设工具auto_approve白名单开箱即是受监督 白名单姿态HEALTHCHECK 仍被提供zeroclaw status --formatexit-code60s 间隔SECURITY.md 中4.6 不适用指的是该控制项对无状态 CLI/gateway 的静态适用性判断而非镜像缺失健康检查。需要说明的前提上述 distroless 镜像路径、UID 与用户声明均以当前仓库 Dockerfile 实际内容为准不同发布版本的镜像标签与 digest 会由 dev/ci/container-base-images.toml 生成并随构建流水线更新。验证容器安全可复制的命令SECURITY.md 给出了两组可直接执行的生产验证命令# 构建并验证非 root 用户 docker build -t zeroclaw . docker inspect --format{{.Config.User}} zeroclaw # 期望输出65534:65534 # 以只读文件系统运行生产加固 docker run --read-only -v /path/to/workspace:/workspace zeroclaw gateway命令语义拆解docker inspect --format{{.Config.User}}读取镜像配置中的User字段若输出为65534:65534即确认 nonroot 运行CIS 4.1docker run --read-only将容器根文件系统挂载为只读CIS 5.25此时 Agent 的全部文件活动都必须发生在挂载的/workspace卷内——这与沙箱第 1 层工作区隔离在容器维度上的实现是一致的注意 SECURITY.md 示例使用zeroclaw gateway作为命令而仓库 Dockerfile 的默认ENTRYPOINT [zeroclaw]CMD [daemon]会以 daemon 模式启动gateway子命令适用于只想暴露 gateway 服务的场景。CI 强制镜像安全被自动化守护SECURITY.md 明确指出CI 流水线中的source-images任务.github/workflows/docker-image-pr.yml会验证其加载的默认镜像与 Alpinelinux/amd64镜像均配置为以65534:65534运行。这意味着镜像必须 nonroot不是口头约定而是合并前必须通过的门禁——任何让镜像回退到 root 运行的改动都会在 CI 阶段被拦截。该约束与仓库的镜像构建体系多阶段构建、digest 锁定、$TARGETARCH交叉编译共同构成了发布层面的安全红线。结语从策略到代码的安全闭环ZeroClaw 的安全设计呈现出完整的闭环策略层SECURITY.md 定义版本支持、披露流程与响应时限架构层AutonomyLevelReadOnly / Supervised / Full 五层沙箱实现最小权限、纵深防御实现层crates/zeroclaw-runtime/src/security 的 20 个子模块策略、沙箱执行器、配对、密钥存储、提示注入防御、审计、成本护栏等逐条落地验证层129 个自动化测试 CI 镜像门禁防止安全机制退化交付层distroless nonroot 镜像、只读文件系统支持、supervised 默认风险画像让安全默认值随镜像一起交付。对于部署 ZeroClaw 的团队落地建议是升级保持在最新 minor 线用docker inspect --format{{.Config.User}}与docker run --read-only验证镜像姿态按业务需要调整[risk_profiles.*]的级别与auto_approve白名单在自主能力与可控边界之间找到适合自己场景的平衡点。【免费下载链接】zeroclawFast, small, and fully autonomous AI personal assistant infrastructure, any OS, any platform — deploy anywhere, swap anything 项目地址: https://gitcode.com/gh_mirrors/ze/zeroclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考