How Mercari Safely Distributed Claude Code Internally

"I understand it's convenient. But honestly, isn't it scary that AI executes commands on employee PCs?"

This is the most common concern I hear from executives when supporting AI implementation. AI that stays within a browser, like ChatGPT, isn't as intimidating. But Claude Code reads files on employee computers, executes commands, and accesses the internet. "I know it makes things faster. But who takes responsibility if an accident occurs?" Many companies are likely stuck at this point.

A large corporation has provided an answer to that anxiety. Mercari recently shared their "security settings and distribution methods" used when deploying Claude Code to hundreds of employees during a study session.

Moreover, the content wasn't about expensive, proprietary systems. By preparing and distributing a single configuration file, even small and medium-sized enterprises (SMEs) can replicate much of it.

The reason Mercari could distribute it to hundreds of people wasn't a high-cost mechanism, but a single "configuration file that employees cannot remove." SMEs can do the same starting today.

In this article, I will break down Mercari's design as simply as possible, covering "what to fear," "how Mercari managed it," and "where your company can start." I'll add explanations for technical terms as they appear, so non-engineer executives and PMs can follow along.

You can find the referenced presentation materials here:

(Mercari Claude Code Organization Deployment Security Settings / Speaker Deck).

The exact syntax for the settings has been verified against Anthropic's official documentation.

Why is Claude Code "Convenient yet Scary"?

First, let's clarify the nature of the fear. I feel that if you just copy the settings without understanding this, you won't know what you're actually protecting.

What makes Claude Code different from standard chat AI is that it can act on its own within your local computer. It can search for and read files, rewrite them, and execute shell commands (commands typed into a terminal). It can also access the internet. In other words, almost anything you can do on that computer, the AI can do as well.

Specifically, what could go wrong? Computers usually contain things you don't want seen:

• Information acting as passwords for clouds or APIs (configuration files like .env, ~/.aws/credentials, etc.)
• Keys for logging into servers (contents of ~/.ssh/)
• Important files that would be disastrous if deleted

AI has no malice. However, due to ambiguous instructions or commands embedded in suspicious text on the web (known as prompt injection), it could accidentally read these secret files and send them to the internet, or delete important items using the rm command. Anthropic's official documentation recommends a design that restricts permissions based on these risks (Permission Settings - Official).

In short, there are three things to protect: preventing secret information from leaking, preventing dangerous operations from being performed automatically, and narrowing the scope of what can be touched in the first place. Mercari's measures become much easier to understand when read through these three lenses.

Breaking Down Mercari's "5 Measures"

Mercari's presentation summarized five major measures. We will look at "the purpose" and "how to implement it" for each.

Please note that the presentation slides focus on the concepts, and don't include every detail of the configuration file. Therefore, I will present this in the form of "how to implement Mercari's policies using Claude Code's official settings." The key names and syntax are all verified from Anthropic's official docs.

Measure ①: Make Human Confirmation "Unskippable"

Claude Code has a mode that proceeds automatically without asking for confirmation every time. While convenient for developers on their experimental PCs, allowing this when distributing to everyone in a company removes the safety brakes.

Mercari disabled this "bypass confirmation mode." Officially, settings like permissions.disableBypassPermissionsMode (and disableAutoMode to block automatic mode) are available. Setting these to "disable" prevents users from entering those modes. Furthermore, if placed in the "managed settings" described later, employees cannot disable them themselves (Permission Settings - Official).

The meaning is simple: it enforces the rule that "a human must give the OK before the AI moves its hands" across the entire company.

Measure ②: Stop Dangerous Commands, or Always Confirm

Next, we put a leash on the commands themselves. For example, curl (a command to fetch data from the internet). If used freely, it can become a pathway for sending secret files outside.

In Claude Code, you can set a deny list for specific commands and an ask list that requires confirmation before execution. The syntax looks like this:

1{
2  "permissions": {
3    "deny": [
4      "Bash(curl:*)",
5      "Bash(wget:*)"
6    ],
7    "ask": [
8      "Bash(git push:*)"
9    ]
10  }
11}

Bash(curl:*) means "block all commands starting with curl" (the :* at the end represents "anything after that"). One important note: the official docs state that trying to allow curl only for specific destinations like GitHub is easily bypassed via redirects. Therefore, the official recommendation is to block internet communication entirely and unify necessary fetches through a separate safe port (Permission Settings - Official). This "safe port" is WebFetch (a built-in Claude Code feature for internet retrieval), where destinations can be whitelisted.

Measure ③: Prevent Reading Secret Files and System Modification

We also block access to the secret information itself, such as .env files where passwords reside or the sudo command used for deep system changes.

1{
2  "permissions": {
3    "deny": [
4      "Read(.env)",
5      "Read(.env.*)",
6      "Read(**/.ssh/**)",
7      "Bash(sudo:*)"
8    ]
9  }
10}

Writing Read(.env) makes .env unreadable at any level under the working folder. One thing to know for safety is that while this deny list works against Claude's own file reading or obvious commands like cat, it cannot completely stop a script written by the AI from opening a file secretly in the background (Permission Settings - Official). That's why Measure ④ is necessary.

Measure ④: Enclose the "Reach" with a Sandbox

While a deny list is about drawing lines for specific commands, a sandbox creates a wall at the OS level. It physically restricts the AI from touching anything outside the working folder or connecting to anything other than permitted internet domains.

1{
2  "sandbox": {
3    "enabled": true,
4    "network": {
5      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
6    }
7  }
8}

When enabled, even if the AI accidentally reaches for a secret file, it can't get to it because it's outside the "sandbox." The official docs explain that you should layer both the deny list (Measures ② & ③) and the sandbox for the final boundary (Sandboxing - Official). Think of it as having both individual rules and a perimeter fence.

One constraint: Sandboxing works on macOS, Linux, and WSL2 (Linux on Windows), but it is not supported on native Windows. In Windows-centric workplaces, the decision would be to strengthen the permission settings in Measures ①–③.

Measure ⑤: Make the AI Read "What to Protect" Every Time

Finally, a different angle from rigid settings: write the company's security policy in an instruction manual that the AI reads every time. If settings are "physical locks," this is like a "review of workplace rules."

There are several technical ways to do this, and it's not clear from the materials which one Mercari used. However, the easiest way is to place a file named CLAUDE.md directly in the working folder and list internal rules there. Claude Code reads this file every time.

1# Security Requests
2- Do not open .env or key files (~/.ssh/, etc.)
3- Do not send customer info or trade secrets to external services
4- Always confirm with a human before executing delete or publish operations

Action for today: Just pasting these three lines into a CLAUDE.md file adds a layer of common sense to the AI's behavior. You can start with this even before the configuration files.

Action for today: You don't have to implement everything at once. Start by adding just the Read(.env) line from Measure ③ to a configuration file named .claude/settings.json. Create a folder named .claude (including the leading dot) in your project folder and save a text file named settings.json inside it. If you want it to apply to all projects, place it in ~/.claude/settings.json in your home directory. You can start with the most effective move: preventing the AI from reading secret files.

Mercari's Real Skill was in the "Distribution"

So far, we've covered "what to set." Mercari's presentation was particularly practical because it addressed how to distribute these settings to hundreds of people.

Normally, configuration files are placed on each person's computer (user settings), meaning employees can rewrite them. This leads to situations where "security settings were distributed, but someone disabled them."

To solve this, Mercari used MDM (Mobile Device Management—a system for companies to manage employee PCs) to simultaneously distribute "managed settings" that employees cannot overwrite. Claude Code has a designated location for managed settings that take priority over individual settings and cannot be changed by the user. On macOS, this is /Library/Application Support/ClaudeCode/managed-settings.json (Settings - Official). By writing Measures ①–④ here, they cannot be loosened on-site.

Even smarter was differentiating safety levels for engineers and non-engineers:

• For Engineers: Settings that allow some customization and don't hinder productivity too much.
• For Non-Engineers: The safest default settings with less room for tinkering.

Even for the same tool, they adjusted the length of the leash based on the user's literacy. If everyone is strictly restricted, the work stalls; if everyone is loose, accidents happen. They solved this by varying the distributed settings.

Where SMEs Can Start Replicating

Most companies probably don't have MDM. That's okay. You can extract the parts of Mercari's design that work regardless of scale.

All you need to do is distribute a single file with safety settings and have it placed. If you have MDM, distribute it as a managed setting; if not, share it and say, "Please put this settings.json in your .claude/ folder." The enforcement is lower, but the direction is the same.

As a minimum set, combining Measures ①–③ looks like this. I recommend using this as a foundation and adding any specific commands your company wants to ban.

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}

From top to bottom: disable confirmation bypass, block internet communication and admin operations, prohibit reading secret files, and always confirm deletion or publishing. Even if you don't understand the contents, it will work if you copy and paste it.

If distributing to non-engineers, I recommend the safest version, which adds the sandbox (Measure ④). Combining the two settings into one file looks like this:

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}

I've simply placed permissions and sandbox side-by-side, separated by a comma. Change the allowedDomains to match the services your company uses. Remember, sandboxing works on macOS, Linux, and WSL2.

What I always tell people when supporting implementation is: don't stop because you're aiming for perfection. Even if you can't build a multi-layered defense like Mercari's right away, protecting .env with a single line significantly lowers the probability of an accident.

Action for today: If even one person in your company is starting to use Claude Code, share the minimum set above as text and have them paste it into .claude/settings.json. It's a perfect size for a distribution rehearsal.

Pitfalls: 3 Things to Know Before Distributing Settings

Because this is about hardening security, there are points that are dangerous if misunderstood.

1. "Writing a deny list" doesn't mean it's perfectly safe. As mentioned in Measure ③, a deny list cannot stop everything a script might do in the background. Even if you stop curl, other communication methods might remain. If you want to truly enclose it, don't forget the premise of layering it with a sandbox (Measure ④).
2. Don't rely on filtering by arguments. Anthropic itself warns that conditional permissions, like allowing curl only for a specific URL, are easily broken. It's sturdier to block dangerous things entirely and provide one safe alternative.
3. Don't just distribute settings and call it a day. Even if you enforce managed settings, it's meaningless if employees install other suspicious tools on their own. Settings are a "mechanism to reduce accidents" and work best when paired with usage education. This is where Measure ⑤, "making them read the rules," finally comes into play.

FAQ for Intermediate Users

Q. Is there any point in setting this up for personal use?

Yes. The criteria is whether secret information is on that computer, not whether it's for a company. Freelancers and individual developers still have .env and ~/.ssh/ locally. At the very least, it's safer to include the Measure ③ read prohibition.

Q. Won't restricting permissions make the AI useless?

It's a matter of how you restrict them. Read-only commands (like ls or cat) work without confirmation by default, so daily work rarely stops. What stops are operations like deletion, publishing, and internet communication—things that hurt if they go wrong. In fact, by shifting to "humans only check when it's dangerous," you can safely expand the range of what you let the AI do automatically.

Q. What is the difference between `settings.json` and managed settings (`managed-settings.json`)?

The location and the "strength" differ. settings.json in a project's .claude/ folder is a shared setting that anyone can edit. managed-settings.json is distributed by the company and cannot be changed by the user. For individuals or small groups, the former is enough; move to the latter when you reach the stage where "it's a problem if someone loosens the settings."

Q. Can I use the same thinking for Cursor or other AI coding tools?

The things you want to protect (secrets, dangerous operations, reach) are the same, so the concept applies. However, the syntax and the presence of sandboxing vary by tool, so consider this settings.json notation specific to Claude Code. If using other tools, the shortcut is to apply these same three perspectives to their respective official documentation.

Summary: From "Don't Use It" to "Distribute Safely"

When I receive consultations about AI implementation, the most common response used to be "It's dangerous, so we can't let them use it yet." But that decision also throws away all the convenience.

Mercari showed us a way out of that binary choice. Disable confirmation bypass, stop dangerous operations, prohibit touching secret files, enclose in a sandbox, and make them read the rules. Then, distribute it to everyone as settings that cannot be tampered with. It's a design that changes "forbidden because it's scary" to "distributed with a leash because it's scary."

• Targets to protect: Prevent secrets from leaking / Prevent dangerous operations / Narrow the reach.
• Mercari's 5 Measures: Disable bypass, restrict dangerous commands, prohibit secret files, sandbox, and rule reading.
• Distribution: Use managed settings that the user cannot overwrite, differentiated by literacy.

Finally, here are three steps starting today:

1. Add `Read(.env)` to your own computer: Start by prohibiting the reading of secret files. This is the most effective single move.
2. Make a single file of the minimum set: Based on the permissions example above, add commands your company wants to stop.
3. Distribute it to one person in the company to test: Have them paste it into .claude/settings.json and check together that work doesn't stall.

The first step is just one line to protect .env. You can layer a perfect multi-layered defense one by one from there. Why not place that first file today and change "stopping because it's scary" to "delegating with a leash"?

Reference Links

• Mercari Claude Code Organization Deployment Security Settings (Presentation / Speaker Deck)
• Configure permissions (Anthropic Official)
• Sandboxing (Anthropic Official)
• Claude Code settings (Anthropic Official)