Skip to content

Claude Code 权限与安全:如何安全地让 AI 操作你的系统 ​

更新日期:2026-09-29 | 适用版本:Claude Code 最新稳定版

Claude Code 和普通 AI 聊天工具最大的区别是:它能真正执行命令、读写文件、操作你的系统。

这既是它强大的原因,也是风险的来源——一个能运行任意命令的 AI,如果没有权限约束,一次误操作可能删掉你的数据、泄漏你的密钥、或者把错误的变更推到生产环境。

这篇文章讲清楚 Claude Code 的权限机制,以及一套经过真实项目验证的三层防护实践。

一、先理解风险模型 ​

Claude Code 能做的事 = 你在终端里能做的事。所以风险也等于"一个手很快的同事":

风险类型场景举例
破坏性操作误删文件、重置分支、覆盖配置
凭据泄漏读取密钥文件、把密钥写进日志或提交
生产事故对生产环境执行未验证的变更
不可逆操作强推代码、删除数据库

关键认知:这些风险在你手动操作时同样存在——AI 只是把"手快"放大了。所以防护思路也一样:约束 + 确认 + 可审计。

二、Claude Code 的权限机制 ​

Claude Code 提供三个层次的权限控制:

1. 交互确认(默认) ​

默认模式下,每个敏感操作(执行命令、写文件)都会先向你确认。你可以选择允许一次、总是允许、或拒绝。

这是最基础的防线——保持默认模式,风险就基本可控。

2. 权限规则(settings.json) ​

对于频繁且安全的操作,可以配置白名单避免每次确认:

json
{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Read"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

关键实践:deny 比 allow 重要。把你绝不允许的操作(删除、读取密钥目录、强推)写进 deny——这是硬性红线,不依赖每次的人工确认。

3. Hooks 硬拦截(PreToolUse) ​

最强的防线是 hook:在工具调用执行之前拦截,命中规则直接阻断。

我给自己机器的配置是:按文件路径拦截所有凭据类文件的读取(密钥目录、证书文件、凭据配置),命中即阻断工具调用。

为什么需要 hook 而不是只靠规则:规则是"提醒",hook 是"上锁"。一条经验教训——关键词过滤永远会漏(内嵌在 URL 里的凭据、base64 编码的密钥都能绕过字符串匹配),所以要按文件路径设防,而不是按内容关键词。

如果你只是个人使用,第 1+2 层已经足够;如果你让 Claude Code 接触生产环境或敏感数据,第 3 层的 hook 是必要的。

三、给 AI 立规矩:CLAUDE.md 里的安全条款 ​

权限管的是"能不能做",行为规范管的是"该怎么做"。

Claude Code 每次启动会自动读取项目的 CLAUDE.md。把安全纪律写进去,AI 每次开工都会遵守:

markdown
## 安全规则

- 生产环境的配置文件**只允许在服务器上修改**,禁止用本地版本覆盖
- 涉及密钥的操作:密钥只通过环境变量注入,绝不写进命令文本
- 破坏性操作(删除、重置、强推)必须先向我确认
- 提交代码前检查:不得包含密钥、不得包含大文件

这条规则的威力:在我们维护的真实项目里,"哪些文件永远不能被部署脚本覆盖""哪些操作必须先确认"都写进了 CLAUDE.md——AI 在整个开发流程中会主动避开这些红线,比人记得还牢。

四、一条铁律:生产环境先看再做 ​

如果你的项目有生产服务器,给 AI 的默认权限应该是只读侦察,任何变更操作都要:

  1. 先做 dry-run(预览变更影响)
  2. 人工确认后再执行
  3. 执行后立即验证结果

我们在真实项目里的做法:部署脚本内置 --dry-run 模式,先跑预览、确认清单无误、再执行真实部署——"先看再做"这个习惯,比任何权限配置都值钱。

五、小结:三层防护 ​

层机制防什么
规则层settings.json 的 allow/deny已知的敏感操作
拦截层PreToolUse hook 按路径阻断凭据泄漏等高危行为
习惯层CLAUDE.md 行为规范 + dry-run 流程判断失误与流程风险

核心原则三条:

  1. 最小权限——能用只读就别给写权限
  2. 敏感操作人工确认——不可逆的事不交给 AI 自主决定
  3. 一切可审计——AI 做了什么、为什么做,都要能看到

下一步 ​