别让 AI 越权!OpenClaw 权限配置完全指南

别让 AI 越权!OpenClaw 权限配置完全指南

一、限制只能聊天(纯对话模式)

适用场景:只想让 AI 帮你思考、写文案、做分析,不需要它执行任何文件操作或命令。

从 2026.3.2 版本开始,OpenClaw 默认已经收紧了权限,但如果你想确保它彻底无法调用工具,可以这样配置:

核心配置命令:

bash

openclaw config set tools.profile messaging 

tools.profile 的四种模式对比

表格

模式能力范围适用场景
messaging纯对话,禁用所有工具(文件读写、命令执行、技能调用等)只想聊天、咨询的场景
minimal极简工具集(如只允许网页搜索)需要查信息但不执行操作
default基础工具集(文件读写、部分命令)日常轻度使用
full完整工具集(包括高风险操作)开发、自动化等场景

验证配置:

bash

openclaw config get tools.profile # 应该输出:messaging 

效果:AI 会说“我没有权限执行此操作”,任何尝试调用工具的行为都会被阻止。

二、限制只能操作 workspace(安全执行模式)

适用场景:需要 AI 帮你处理文件、执行命令,但必须限制在指定目录,防止误删或越权操作。

这是更细粒度的配置,核心是文件系统围栏 + 工具权限白名单

核心配置三步走:

1. 限制文件系统访问范围

编辑 ~/.openclaw/openclaw.json(或使用 CLI 命令):

json

{ "tools": { "fs": { "workspaceOnly": true } } } 

workspaceOnly: true 的作用

  • ✅ AI 只能读写 ~/.openclaw/workspace 目录及其子目录
  • ❌ 禁止访问 /etc//home/user/ 等其他系统路径
  • ❌ 即使尝试用绝对路径(如 /home/user/data)也会被拦截

2. 禁用高危工具(可选但强烈建议)

json

{ "tools": { "deny": [ "group:runtime", // 禁用 exec、bash 等命令执行 "sys_shutdown", // 禁用关机等系统操作 "elevated:*" // 禁用提权(绕过沙箱在宿主机执行) ], "allow": [ "group:fs", // 允许文件读写(已受 workspaceOnly 限制) "web_search" // 允许网页搜索 ] } } 

为什么这样配?

  • group:runtime 包含 exec 和 bash,风险极高——允许 AI 执行任意 Shell 命令
  • elevated:* 禁止提权,防止 AI 绕过沙箱直接操作宿主机
  • group:fs 允许文件操作,但已被 workspaceOnly: true 限制在 workspace 内

3. 启用执行审批(双保险)

对于允许的命令执行,增加人工确认机制:

json

{ "tools": { "executionApproval": { "enabled": true, "autoApprove": ["Read", "Glob"], // 只读操作自动通过 "autoReject": ["Bash(sudo:*)", "Bash(*rm -rf*)"] // 高危命令自动拒绝 } } } 

效果

  • ✅ 读取文件、搜索文件:自动执行
  • ⚠️ 删除文件、修改配置:会问你要不要执行
  • ❌ sudo、rm -rf:直接拒绝

配置生效:

修改 openclaw.json 后,需要重启网关:

bash

# 如果是系统服务 sudo systemctl restart openclaw # 或者通过控制面板重启 

三、快速验证命令

配置完成后,可以用以下命令验证是否生效:

bash

# 检查当前权限配置 openclaw config get tools.profile # 深度安全审计(检查文件权限、沙箱状态、高危工具等) openclaw security audit --deep # 自动修复常见安全问题 openclaw security audit --fix 

四、配置建议总结

表格

场景推荐配置核心要点
纯聊天tools.profile: "messaging"禁用所有工具
安全执行fs.workspaceOnly: true + 禁用 group:runtime限制在 workspace,禁止高危命令
生产环境沙箱 mode: "all" + workspaceAccess: "none" + dmPolicy: "allowlist"最高隔离,仅允许授权用户

Read more

AI 也能写爬虫?基于 Bright Data + Warp CLI 的网页抓取实战

AI 也能写爬虫?基于 Bright Data + Warp CLI 的网页抓取实战

🤵‍♂️ 个人主页:@艾派森的个人主页 ✍🏻作者简介:Python学习者 🐋 希望大家多多支持,我们一起进步!😄 如果文章对你有帮助的话, 欢迎评论 💬点赞👍🏻 收藏 📂加关注+ 目录 一、引言 1.1 写过爬虫的人,大概率都踩过这些坑 1.2 AI 已经很会写代码了,但它真的能“写爬虫”吗? 1.3 让 AI 不只是“写代码”,而是“驱动抓取” 二、技术与工具介绍 2.1 为什么“普通 AI + 爬虫代码”很难跑通真实网页? 2.2 Bright Data:爬虫工程真正的“底层基础设施” 2.3

By Ne0inhk
高可用集群:平滑切换的架构对比与落地指南

高可用集群:平滑切换的架构对比与落地指南

前言 做金融、政务、运营商等行业的数据库架构师,对Oracle RAC一定不陌生——作为业内成熟的高可用集群方案,Oracle RAC凭借多节点共享存储的架构,支撑了无数核心系统的7×24小时运行。但在国产化替代的大趋势下,“去O”不仅要解决单库的兼容问题,更要攻克高可用集群的平滑迁移难题:毕竟核心系统对停机时间的容忍度几乎为0,一旦集群切换出问题,轻则业务中断,重则引发数据错乱、监管风险,这也是很多企业在“去O”过程中最不敢触碰的环节。 很多企业的顾虑很实际:金仓的高可用集群和Oracle RAC架构差异有多大?核心的高可用能力比如故障自动切换、负载均衡、数据一致性,能和Oracle RAC持平吗?迁移过程中怎么保障业务不中断?原有基于Oracle RAC的运维体系能复用吗?这些问题如果没有明确答案,企业根本不敢轻易启动集群迁移。 作为国产数据库的领军者,电科金仓的KingbaseES(KES)针对Oracle RAC用户的迁移痛点,打造了一套高度兼容、能力对标、无缝切换的高可用集群解决方案,不仅在架构设计上贴合Oracle RAC用户的使用习惯,更在故障切换、负载均衡、数据同

By Ne0inhk
MySQL 内置函数指南:日期、字符串、数学函数实战

MySQL 内置函数指南:日期、字符串、数学函数实战

🔥草莓熊Lotso:个人主页 ❄️个人专栏: 《C++知识分享》《Linux 入门到实践:零基础也能懂》 ✨生活是默默的坚持,毅力是永久的享受! 🎬 博主简介: 文章目录 * 前言: * 一. 日期函数:处理时间相关需求 * 1.1 核心日期函数表 * 1.2 实战案例 * 1.2.1 基础时间获取 * 1.2.2 日期加减运算 * 1.2.3 日期差计算与时间提取 * 1.2.4 业务场景:查询近期数据 * 二. 字符串函数:处理文本数据 * 2.1 核心字符串函数表 * 2.2 实战案例 * 2.2.

By Ne0inhk