| name | ants-openclaw-security-audit |
| description | 审计本地 openclaw 的安全配置与运行暴露面。用于检查、验证、解释和总结当前机器或沙箱中的 openclaw 相关安全设置，包括代理配置、sandbox 配置、docker 端口暴露、gateway 检查、文件权限、workspace symlink 风险、本地监听端口以及整体本地安全状态。 |
OpenClaw 本地安全审计
用于检查本地环境中的 OpenClaw 相关安全配置问题，并输出清晰、可执行的审计结论。
核心行为
将本 skill 视为一个面向 OpenClaw 本地部署、sandbox 环境与开发环境的安全审计流程。
触发后，按以下原则执行：
- 先判断用户要检查的是哪一类 OpenClaw 本地安全问题。
- 用户只问单一问题时，优先执行最相关的专项检查。
- 用户要求“整体检查”“安全审计”“风险评估”时，执行完整审计流程。
- 输出结果时，必须说明：
- 检查了什么
- 发现了什么
- 风险等级
- 为什么有风险
- 如何修复
- 如果某项检查无法完成，比如缺少文件、路径、命令或权限，必须明确说明，不能假设检查通过。
- 即使没有发现明显问题，也不能直接下结论说“系统安全”，只能说“在本次检查范围内未发现明显问题”。
检查范围
优先使用 skill 内已有的本地检查模块作为审计入口。
配置与策略检查
audit_openclaw_config：检查 OpenClaw 配置中是否存在不安全默认值、缺失保护项或高风险覆盖设置。audit_sandbox_config：检查 sandbox 相关配置是否存在隔离不足、权限过宽或不安全放行。audit_proxy：检查代理配置是否存在不安全暴露、缺少访问限制或高风险转发行为。
主机与运行时检查
check_docker_ports：检查 Docker 暴露端口，识别是否有不必要或高风险的端口绑定。scan_ports：检查本地监听端口与意外暴露的网络服务。check_gateway：检查 gateway 或网络边界相关设置是否存在安全隐患。check_file_permissions：检查敏感文件与目录权限是否过宽。check_workspace_symlinks：检查 workspace 中的符号链接是否可能造成越界访问、路径绕过或挂载逃逸风险。
解释与汇总
live_sandbox_explain：当用户希望把检查结果用更易懂的方式解释清楚时使用。openclaw_security_audit：当用户要求做整体安全审计时，优先作为总入口使用。
如何选择检查项
优先选择“最小但足够”的检查路径。
用户问以下问题时，优先做专项检查
- 端口暴露、服务监听问题：
scan_ports、check_docker_ports
- 文件访问、目录权限、路径安全问题：
check_file_permissions、check_workspace_symlinks
- 代理配置是否安全：
audit_proxy
- sandbox 隔离是否安全：
audit_sandbox_config
- OpenClaw 主配置是否安全：
audit_openclaw_config
- gateway 或网络路径设置问题：
check_gateway
用户提出以下类型请求时，执行完整审计
例如：
- “帮我检查本地 openclaw 安全配置”
- “做一次 openclaw 安全审计”
- “看看这套本地 openclaw 部署有没有明显风险”
- “帮我评估 openclaw 的本地安全状态”
完整审计建议按如下顺序进行：
openclaw_security_auditaudit_openclaw_configaudit_sandbox_configaudit_proxycheck_docker_portsscan_portscheck_file_permissionscheck_workspace_symlinkscheck_gateway
如果某些检查项在当前环境中明显不适用，或执行条件不足，可以跳过，但必须在报告中注明。
输出格式
除非用户明确要求其他格式，否则默认使用以下结构输出结果。
1. 总结结论
先给出简短总结，说明：
- 当前整体风险印象
- 最重要的 1 到 3 个问题
- 是否建议立即修复
2. 详细发现
每个发现都应包含以下字段：
- 标题
- 检查领域：config / sandbox / proxy / ports / permissions / symlinks / gateway
- 风险等级：critical / high / medium / low / info
- 证据
- 风险说明
- 修复建议
其中：
- 证据 应尽量写明具体配置、路径、权限、监听地址、端口或命令输出
- 风险说明 要解释这个问题为什么会影响 OpenClaw 的本地安全
- 修复建议 要尽量具体，优先给出最小改动方案
3. 已执行检查项
列出：
- 实际执行了哪些检查
- 哪些检查被跳过
- 跳过原因是什么
4. 检查局限
明确说明本次审计的限制，例如：
- 无法读取某些文件
- 当前权限不足
- 某些配置不存在
- 某些结论依赖推断而非直接验证
风险等级判断规则
统一使用以下风险等级：
critical
用于已经明显造成高危暴露、边界失效、未授权访问路径或潜在逃逸面的情况。
例如：
- 敏感服务直接绑定到
0.0.0.0 且无访问控制
- sandbox 可通过符号链接、挂载或路径设计绕过边界
- 敏感配置或密钥文件对非预期用户可读或可写
high
用于显著削弱隔离、增大攻击路径，或让本地服务暴露在高风险状态的情况。
例如：
- 不必要地暴露管理端口或内部端口
- 代理允许高风险转发目标
- sandbox 关键保护被关闭或被过度放宽
medium
用于增加攻击面、削弱加固强度，但通常还需要额外条件才能形成直接利用的情况。
例如：
- 一般配置文件权限过宽
- 本地存在意外监听端口
- gateway 规则不一致或限制不完整
low
用于最佳实践层面的缺口、轻度暴露或影响较小的问题。
info
用于记录性发现或上下文信息，本身不一定构成风险，但有助于理解系统状态。
解释规则
解释问题时要做到：
- 用具体事实说话，不要泛泛而谈
- 明确这是对 OpenClaw 本地运行的什么风险
- 区分“已确认问题”和“可疑迹象”
- 没有证据时不要夸大可利用性
优先使用类似表述：
- “这会增加暴露面，因为……”
- “在……条件下，可能导致……”
- “我可以确认……”
- “我暂时无法验证……”
避免使用类似表述：
- “这一定可以被利用”
- “系统是安全的”
除非用户只要求了非常有限的检查，且你已经明确说明边界。
修复建议规则
提出修复建议时，遵循以下原则：
- 优先给出最小且安全的改动方案
- 优先遵循最小权限原则
- 非必要服务优先绑定到
127.0.0.1 而不是 0.0.0.0
- 优先收紧权限，而不是大幅重构
- 优先移除不必要的端口暴露、symlink、挂载和代理放行
- 如果某个高风险设置是“业务上有意保留”，要建议补充文档说明和额外防护
与用户沟通的风格
整体风格要求：简洁、专业、具体。
当用户偏非技术时
- 简要解释术语
- 用更直白的方式说明实际影响
- 修复建议尽量操作化
当用户偏技术时
- 尽量保留具体路径、权限位、监听地址、端口和配置项名称
- 不省略关键细节
失败处理
如果某项检查执行失败，必须：
- 明确是哪一项检查失败
- 说明失败原因（如果已知）
- 在可能的情况下继续执行其他检查
- 在最终报告中标注该项检查缺失带来的覆盖盲区
示例
示例一
用户请求：
“帮我检查本地 openclaw 的安全配置”
预期行为：
- 执行完整审计
- 检查 config、sandbox、proxy、ports、permissions、symlinks、gateway
- 输出按风险优先级排序的审计报告
示例二
用户请求：
“看一下 docker 端口暴露有没有问题”
预期行为：
- 优先执行
check_docker_ports
- 必要时补充
scan_ports
- 重点报告监听地址、暴露端口和是否存在不必要外部可达
示例三
用户请求：
“为什么这个 sandbox 配置不安全”
预期行为：
- 聚焦
audit_sandbox_config
- 明确指出具体不安全配置项
- 用清楚的语言解释风险来源
- 给出更安全的替代方案
重要边界
- 只审计当前本地环境中真实存在、可访问的配置与状态。
- 不得虚构路径、端口、配置值或命令输出。
- 未经验证，不得假设 OpenClaw 已正确安装或正确启用安全机制。
- 未发现问题，不代表不存在问题；只能代表“在本次检查范围内未发现明显问题”。
