"我知道它很方便。但说实话，AI 能在员工电脑上执行命令，这难道不让人害怕吗？"
这是我在支持 AI 落地时，从高管们那里听到最多的顾虑。像 ChatGPT 这样待在浏览器里的 AI，不会让人那么紧张。但 Claude Code 能读取员工电脑上的文件、执行命令，还能访问互联网。"我知道它能让事情变快。但如果出了事故，谁来负责？"很多公司可能都卡在了这一点上。
一家大型企业为这种焦虑提供了答案。Mercari 最近在一次学习会上分享了他们向数百名员工部署 Claude Code 时使用的"安全设置和分发方法"。
而且，内容并非关于昂贵的专属系统。通过准备和分发一个简单的配置文件，即使是中小企业也可以在很大程度上复制这些做法。
Mercari 能够将其分发给数百人的原因，并非高成本的机制，而是一个"员工无法删除的配置文件"。中小企业从今天起就可以做到。
在这篇文章中，我会尽可能简单地拆解 Mercari 的设计，涵盖"该担心什么"、"Mercari 是如何管理的"，以及"你的公司可以从哪里开始"。我会在遇到技术术语时添加解释，这样非工程师的管理者和 PM 也能跟上。
你可以在这里找到引用的演示材料：
（Mercari Claude Code 组织部署安全设置 / Speaker Deck）。
设置的具体语法已对照 Anthropic 的官方文档进行过核实。
为什么 Claude Code "既方便又可怕"？
首先，让我们明确一下恐惧的本质。我觉得，如果不理解这一点就直接复制设置，你根本不知道自己在保护什么。
Claude Code 与标准聊天 AI 的不同之处在于，它可以在你的本地计算机上自主行动。它可以搜索和读取文件、重写文件，并执行 shell 命令（即在终端中键入的命令）。它还可以访问互联网。换句话说，你在那台电脑上能做的大部分事情，AI 也都能做。
具体来说，可能会出什么问题？电脑里通常有你不想被别人看到的东西：
- 作为云服务或 API 密码的信息（如 .env、~/.aws/credentials 等配置文件）
- 登录服务器的密钥（~/.ssh/ 目录中的内容）
- 一旦被删除就会造成灾难的重要文件
AI 没有恶意。但是，由于模糊的指令或嵌入在网页可疑文本中的命令（称为提示注入），它可能会意外地读取这些机密文件并将其发送到互联网，或者使用 rm 命令删除重要内容。Anthropic 的官方文档建议根据这些风险来设计权限限制（Permission Settings - 官方文档）。
简而言之，需要保护三件事：防止机密信息泄露、防止自动执行危险操作、以及从一开始就缩小 AI 可以触及的范围。 通过这三个视角来阅读 Mercari 的措施，会变得容易理解得多。
拆解 Mercari 的"5 项措施"
Mercari 的演示总结了五项主要措施。我们将逐一了解每项措施的"目的"和"如何实现"。
请注意，演示幻灯片侧重于概念，并未包含配置文件的每个细节。因此，我将以"如何使用 Claude Code 的官方设置来实现 Mercari 的策略"的形式呈现。所有的键名和语法都来自 Anthropic 的官方文档。
措施 ①：让人工确认变得"不可跳过"
Claude Code 有一种模式，可以自动执行操作，每次都不要求确认。虽然对于在实验性 PC 上开发的开发者来说很方便，但在公司内部全员部署时允许这种模式，就等于卸下了安全刹车。
Mercari 禁用了这种"绕过确认模式"。在官方设置中，有像 permissions.disableBypassPermissionsMode（以及用于阻止自动模式的 disableAutoMode）这样的选项。将这些设置为"禁用"可以阻止用户进入这些模式。此外，如果将其放在后面会提到的"托管设置"中，员工自己就无法禁用它（Permission Settings - 官方文档）。
其含义很简单：它在全公司范围内强制推行一条规则，即"在 AI 动手之前，必须得到人类的许可"。
措施 ②：阻止危险命令，或要求始终确认
接下来，我们给命令本身套上缰绳。例如，curl（一个从互联网获取数据的命令）。如果随意使用，它可能成为将机密文件发送到外部的通道。
在 Claude Code 中，你可以为特定命令设置 deny（拒绝）列表，以及一个需要确认后才能执行的 ask（询问）列表。语法如下：
1{2 "permissions": {3 "deny": [4 "Bash(curl:*)",5 "Bash(wget:*)"6 ],7 "ask": [8 "Bash(git push:*)"9 ]10 }11}
Bash(curl:*) 的意思是"阻止所有以 curl 开头的命令"（结尾的 :* 代表"此后的任何内容"）。一个重要注意事项：官方文档指出，如果试图只允许 curl 访问像 GitHub 这样的特定目标，很容易通过重定向绕过。因此，官方的建议是完全阻止互联网通信，并通过一个独立的、安全的端口来统一处理必要的获取操作（Permission Settings - 官方文档）。这个"安全端口"就是 WebFetch（Claude Code 内置的互联网检索功能），它的目标地址可以被列入白名单。
措施 ③：防止读取机密文件和系统修改
我们还需要阻止对机密信息本身的访问，比如存放密码的 .env 文件，或者用于深度系统更改的 sudo 命令。
1{2 "permissions": {3 "deny": [4 "Read(.env)",5 "Read(.env.*)",6 "Read(**/.ssh/**)",7 "Bash(sudo:*)"8 ]9 }10}
写上 Read(.env) 会使工作文件夹下任何层级中的 .env 文件都无法被读取。有一点需要了解以确保安全：虽然这个拒绝列表能阻止 Claude 自身的文件读取或像 cat 这样明显的命令，但它无法完全阻止 AI 编写的脚本在后台偷偷打开文件（Permission Settings - 官方文档）。这就是为什么需要措施 ④。
措施 ④：用沙箱封闭"可触及范围"
拒绝列表是为特定命令划出的红线，而沙箱则是在操作系统层面建立一道墙。它从物理上限制 AI 触及工作文件夹之外的任何内容，或连接到除允许的互联网域名以外的任何地址。
1{2 "sandbox": {3 "enabled": true,4 "network": {5 "allowedDomains": ["*.github.com", "registry.npmjs.org"]6 }7 }8}
启用后，即使 AI 意外地尝试获取机密文件，它也做不到，因为该文件位于"沙箱"之外。官方文档解释说，你应该将拒绝列表（措施 ② 和 ③）与沙箱结合起来，作为最终的安全边界（Sandboxing - 官方文档）。可以把它想象成既有单独的规定，又有一道围墙。
一个限制条件：沙箱功能适用于 macOS、Linux 和 WSL2（Windows 上的 Linux），但不支持原生 Windows 系统。在以 Windows 为中心的工作场所，决策会是加强措施 ① 到 ③ 中的权限设置。
措施 ⑤：让 AI 每次都要读取"需要保护的内容"
最后，一个与硬性设置不同的角度：将公司的安全策略写入 AI 每次都会读取的指令手册中。如果说设置是"物理锁"，那这就好比是"工作场所规则的重申"。
有几种技术方法可以实现这一点，从材料中看不清楚 Mercari 使用了哪一种。不过，最简单的方法是直接在项目文件夹中放置一个名为 CLAUDE.md 的文件，并在其中列出内部规则。Claude Code 每次都会读取这个文件。
1# 安全要求2- 不要打开 .env 或密钥文件（~/.ssh/ 等）3- 不要将客户信息或商业机密发送到外部服务4- 在执行删除或发布操作之前，务必征求人工确认
今日行动：只需将这三行内容粘贴到一个 CLAUDE.md 文件中，就能为 AI 的行为增加一层常识性的约束。你甚至可以在配置好配置文件之前就先做这一步。
今日行动：你不必一次性实现所有措施。先从措施 ③ 中的 Read(.env) 这一行开始，将其添加到名为 .claude/settings.json 的配置文件中。在你的项目文件夹中创建一个名为 .claude（包括前面的点号）的文件夹，并在里面保存一个名为 settings.json 的文本文件。如果你想让它应用于所有项目，则将其放在用户主目录下的 ~/.claude/settings.json 中。你可以从最有效的一步开始：防止 AI 读取机密文件。
Mercari 真正的技巧在于"分发"
到目前为止，我们讨论了"设置什么"。Mercari 的演示之所以特别实用，是因为它解决了如何将这些设置分发给数百人的问题。
通常情况下，配置文件放在每个人的电脑上（用户设置），这意味着员工可以重写它们。这会导致"安全设置已经分发，但有人禁用了它们"的情况。
为了解决这个问题，Mercari 使用了 MDM（移动设备管理——一种公司用来管理员工 PC 的系统）来同时分发员工无法覆盖的"托管设置"。Claude Code 有一个专门的位置用于托管设置，这些设置优先级高于个人设置，并且用户无法更改。在 macOS 上，路径是 /Library/Application Support/ClaudeCode/managed-settings.json（Settings - 官方文档）。将措施 ① 到 ④ 写在这里，现场就无法将其放宽了。
更聪明的是为工程师和非工程师区分了安全级别：
- 对于工程师：允许一些自定义设置，并且不会过多地妨碍生产力。
- 对于非工程师：最安全的默认设置，减少可调整的空间。
即使是同一个工具，他们也根据用户的认知水平调整了缰绳的长度。如果每个人都严格限制，工作就会停滞；如果每个人都宽松，事故就会发生。他们通过分发不同的设置来解决这个问题。
中小企业可以从哪里开始复制
大多数公司可能没有 MDM。这没关系。你可以提取 Mercari 设计中不受规模影响的部分。
你需要做的就是分发一个包含安全设置的文件，并让用户将其放置好。如果你有 MDM，就将其作为托管设置分发；如果没有，就共享出去，并说："请把这个 settings.json 文件放到你的 .claude/ 文件夹里。" 强制力会弱一些，但方向是相同的。
作为最小集合，将措施 ① 到 ③ 组合起来是这样的。我建议以此为基础，并添加你公司想要禁止的任何特定命令。
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 }17}
从上到下依次是：禁用绕过确认、阻止互联网通信和管理员操作、禁止读取机密文件、以及始终确认删除或发布操作。即使你不理解内容，直接复制粘贴也能生效。
如果分发给非工程师，我建议使用最安全的版本，即添加沙箱（措施 ④）。将两个设置合并到一个文件中是这样的：
1{2 "permissions": {3 "disableBypassPermissionsMode": "disable",4 "deny": [5 "Bash(curl:*)",6 "Bash(wget:*)",7 "Bash(sudo:*)",8 "Read(.env)",9 "Read(.env.*)",10 "Read(**/.ssh/**)"11 ],12 "ask": [13 "Bash(git push:*)",14 "Bash(rm:*)"15 ]16 },17 "sandbox": {18 "enabled": true,19 "network": {20 "allowedDomains": ["*.github.com", "registry.npmjs.org"]21 }22 }23}
我只是简单地将 permissions 和 sandbox 并列放置，用逗号分隔。将 allowedDomains 修改为你公司使用的服务。记住，沙箱功能适用于 macOS、Linux 和 WSL2。
我在支持实施时总是告诉人们：不要因为追求完美而停滞不前。即使你无法立即构建像 Mercari 那样的多层防御，仅用一行代码保护 .env 文件也能显著降低事故发生的概率。
今日行动：如果你的公司里已经有哪怕一个人在开始使用 Claude Code，就把上面这个最小集合以文本形式分享给他，让他粘贴到 .claude/settings.json 中。这是一个非常适合进行分发演练的大小。
陷阱：分发设置前需要知道的 3 件事
因为这是关于强化安全性的，所以有些点如果误解了会很危险。
- "编写拒绝列表"并不意味着绝对安全。正如在措施 ③ 中提到的，拒绝列表无法阻止脚本在后台做的一切事情。即使你阻止了
curl，其他通信方式可能仍然存在。如果你想真正地封闭它，不要忘记将其与沙箱（措施 ④）结合使用的前提。 - 不要依赖按参数进行过滤。Anthropic 自己就警告过，像只允许
curl访问特定 URL 这样的条件权限很容易被绕过。更稳妥的做法是完全阻止危险的东西，然后提供一个安全可靠的替代方案。 - 不要只是分发设置就完事了。即使你强制实施了托管设置，如果员工自行安装其他可疑工具，那也是没有意义的。设置是"减少事故的机制"，只有与使用教育相结合才能发挥最佳效果。这就是措施 ⑤"让他们阅读规则"最终发挥作用的地方。
面向中级用户的常见问题
问：个人使用设置有意义吗？
有。判断标准是那台电脑上是否有机密信息，而不是是否用于公司。自由职业者和个人开发者本地也有 .env 和 ~/.ssh/ 文件。至少，包含措施 ③ 的读取禁止会更安全。
问：限制权限会不会让 AI 变得没用？
这取决于你如何限制。只读命令（如 ls 或 cat）默认情况下无需确认即可工作，所以日常工作很少会受阻。被阻止的是删除、发布和互联网通信这类操作——那些一旦出错就会造成损失的操作。事实上，通过转向"仅在危险时由人工检查"，你可以安全地扩大让 AI 自动执行的操作范围。
问：`settings.json` 和托管设置（`managed-settings.json`）有什么区别？
位置和"强度"不同。项目 .claude/ 文件夹中的 settings.json 是共享设置，任何人都可以编辑。managed-settings.json 由公司分发，用户无法更改。对于个人或小团队，前者就足够了；当你达到"如果某人放宽了设置就会出问题"的阶段时，再转向后者。
问：我可以将同样的思路用于 Cursor 或其他 AI 编码工具吗？
你想保护的东西（机密、危险操作、可触及范围）是相同的，所以概念适用。但是，语法和沙箱的存在与否因工具而异，因此请将这个 settings.json 的写法视为 Claude Code 所特有的。如果使用其他工具，捷径是将这些相同的三个视角应用到它们各自的官方文档中。
总结：从"别用"到"安全地分发"
当接到关于 AI 落地的咨询时，最常见的回应曾经是"这太危险了，所以我们还不能让他们用"。但这个决定也抛弃了所有的便利性。
Mercari 向我们展示了走出这种非此即彼选择的方法。禁用绕过确认、阻止危险操作、禁止触碰机密文件、封闭在沙箱中、并要求阅读规则。然后，将其作为不可篡改的设置分发给所有人。这是一种将"因为可怕所以禁止"转变为"因为可怕，所以套上缰绳再分发"的设计。
- 保护目标：防止机密泄露 / 防止危险操作 / 缩小可触及范围。
- Mercari 的 5 项措施：禁用绕过、限制危险命令、禁止访问机密文件、沙箱、规则阅读。
- 分发：使用用户无法覆盖的托管设置，并根据认知水平进行区分。
最后，从今天开始的三步行动：
- 在你自己的电脑上添加 `Read(.env)`：首先禁止读取机密文件。这是最有效的单一步骤。
- 制作一个包含最小集合的文件：以上面的
permissions示例为基础，添加你公司想阻止的命令。 - 在公司内部分发给一个人进行测试：让他粘贴到
.claude/settings.json中，一起检查工作是否停滞。
第一步只是保护 .env 的一行代码。你可以从那开始，逐步构建完美的多层防御。为什么不今天就放置好第一个文件，将"因为害怕而停止"转变为"套上缰绳再委托"呢？
