企业官网建设流程全解析

thClaws 是一个用 Rust 编写的开源 AI Agent 框架，GUI、CLI、无头模式共用同一个二进制文件。当 Agent 开始替你改文件、跑命令、访问网络时，安全就成了绕不开的话题。thClaws 权限体系通过审批门、文件系统沙箱、操作系统级 Bash 沙箱三道相互独立的防线（外加组织策略层兜底），让 AI Agent 能力再强也不会"失控"——本文带你一次看懂这套安全设计，以及如何在几分钟内完成配置。

为什么 AI Agent 需要权限体系

AI Agent 和普通的"聊天机器人"有本质区别：它能真的动手。thClaws 的 Agent 可以：

• 编辑、创建、删除项目里的文件；
• 执行任意 shell 命令（npm install、git push、curl ...）；
• 访问外部 URL、调用 MCP 服务器启动子进程。

能力越大，风险越大。如果模型产生幻觉或被人诱导，一条rm -rf就可能是灾难。thClaws 的思路不是"把功能砍掉"，而是给每类操作设计独立生效、互不覆盖的防线：绕过任何一道，另外几道照样拦截。核心实现分别在 crates/core/src/permissions.rs、crates/core/src/sandbox.rs 和 crates/core/src/confine.rs。

三道防线总览：各司其职，独立生效

四层的"失败即拒绝"（fail-closed）原则意味着：你在auto模式下选了全自动，也照样写不了/etc/passwd（文件系统沙箱拦截）；沙箱再宽松，装不了策略文件里没批准主机的技能（策略层拦截）。这正是"纵深防御"在 AI Agent 权限管理里的落地。

第一道防线：权限模式与审批弹窗

thClaws 定义了三种基础权限模式（PermissionMode）：

在ask模式下，只读工具（Read、Grep、Glob、Ls 等）永远"免费"放行，而修改类工具（Write、Edit、Bash、WebFetch 以及所有 MCP 工具）每次都会弹出审批框：

弹窗提供三个选项：Allow（仅本次）、Allow for session（本会话内全部放行，CLI 里对应输入yolo）、Deny（拒绝）。注意yolo只跳过审批提示，不会关闭沙箱——写项目外的文件依然会被第二道防线拦下。

切换模式非常简单，终端输入斜杠命令即可：

❯ /permissions ask permissions: ask (auto = never prompt, ask = prompt on mutating tools)

此外还有plan模式的特殊保护：计划提交后，Agent 不能自己推进步骤或"擅自退出计划模式"，必须等人在侧边栏点 Approve / Cancel——防止模型把一句随口"开始吧"当成批准就动手改文件。详见 user-manual/ch18-plan-mode.md。

第二道防线：文件系统沙箱，管住每一次文件读写

审批门管"要不要执行"，文件系统沙箱管"能碰到哪里"。所有文件类工具（Read / Write / Edit / Ls / Glob / Grep）在执行前都会调用 Sandbox::check 或 Sandbox::check_write，把路径"钉死"在你打开的项目根目录里。它的验证算法有三重技巧：

1. 先做词法归一化：在访问磁盘之前先解析..和.，防止projects/../outside.txt这种"父目录在项目内、终点在项目外"的穿墙路径；
2. canonicalize 跟随符号链接：哪怕/tmp里放了一个指向别处的软链，也会被识破；
3. 保护内部目录：写入.thclaws/（存放团队状态、设置、收件箱）会被 enforce_write_policy 直接拒绝——Agent 不能改写自己的"档案室"。

这层沙箱独立于权限模式生效，是yolo模式"没那么吓人"的根本原因：即使会话内全放行，Write("/etc/passwd")依然过不了这一关。想让 Agent 碰项目外的文件？从父目录启动 thClaws 即可扩大沙箱边界。

第三道防线：操作系统级 Bash 沙箱，内核说了算

文件工具被沙箱管住了，那Bash命令呢？echo x > ~/secret用的是绝对路径，文件系统沙箱管不到；用"检查命令字符串"的钩子也没用——$(printf 'r''m') -rf ~/这类混淆写法能让任何字符串匹配形同虚设。

所以 thClaws 选择了让操作系统本身来强制执行边界（crates/core/src/confine.rs）：

两个值得记住的安全细节：

• 秘密文件禁读：~/.ssh、~/.aws、~/.config/thclaws等凭据目录在受限模式下禁止读取。尤其是~/.config/thclaws——它存着 Agent 自己的 API Key，"Agent 跑的命令不能读到 Agent 依赖的钥匙"；
• 报告如实：审计记录里同时写明mode和enforced两个字段。如果宿主机缺少 Landlock 等机制，thClaws 会打印醒目的警告并降级为无限制运行（绝不悄悄谎报），enforced: false会如实记录，方便审计者判断防线是否真正生效。

该沙箱对 Bash 派生的所有子进程（含子 Agent 和 workflow shell）同样生效，因为规则在安装exec之前就绑定到进程上。

隐藏的第 N 道：MCP 命令白名单与危险命令提醒

除了三道主防线，thClaws 还在几个"容易被忽视的入口"加了锁：

🔒MCP stdio 首次启动审批：MCP 服务器配置可能来自克隆的第三方仓库，command字段指向任意二进制。因此每个 MCP stdio 命令第一次启动时都会弹窗确认，批准后记入白名单文件~/.config/thclaws/mcp_allowlist.json，之后不再打扰。无 TTY 的无头环境默认直接失败，除非你在可信环境显式设置THCLAWS_MCP_ALLOW_ALL=1。

⚠️危险命令标记：rm -rf、sudo、curl ... | sh、dd、mkfs等 80 多种破坏性模式会被标记黄色⚠，提醒你在批准前多看一眼。

👥团队模式硬拦截：在 Agent Team 中，lead（协调者）的 lead_forbidden_command 会直接阻断git reset --hard、rm -rf、git push --force等曾"误伤"队友工作区的命令——提示词约束只是君子协定，这是安全带。

实战配置：最常用的三种权限策略

方式一：会话内临时切换（不写盘，重启失效）

❯ /permissions auto ❯ /permissions ask

方式二：项目级持久化配置，编辑.thclaws/settings.json：

{ "permissions": "auto", "allowedTools": ["Read", "Write", "Edit", "Bash"], "disallowedTools": ["WebFetch"] }

也支持细粒度写法："allow": ["Bash(git *)"]表示只放行 git 命令，"deny"列表中的工具在任何模式下（包括yolo）都被硬拦截。

方式三：单次运行用 CLI 参数（仅覆盖当前进程）：

thclaws --cli --permission-mode ask

想调整 Bash 沙箱边界时，在settings.json增加：

{ "bash": { "sandbox": "workspace", "sandbox_write_paths": ["/some/extra/dir"], "sandbox_deny_read": ["~/secret-notes"] } }

合法命令需要写到工作区之外时，优先追加sandbox_write_paths，而不是把整个沙箱关掉。

总结：防线的意义不是越严越好，而是各管一段

thClaws 的权限设计给所有做 AI Agent 产品的团队一个清晰的参考：审批管意图，沙箱管路径，内核管进程，策略管来源——四层问答互不替代，任何一层被绕过，其余各层依然独立兜底。更多细节可查阅官方技术文档 thclaws-technical-manual/permissions.md 与 thclaws-technical-manual/confinement.md，面向用户的完整说明见 user-manual/ch05-permissions.md。