「我知道這很方便。但說真的，AI 能直接在員工的電腦上執行指令，這不恐怖嗎？」
這是我在協助企業導入 AI 時，最常從高階主管口中聽到的擔憂。像 ChatGPT 這樣只待在瀏覽器裡的 AI 就沒那麼嚇人。但 Claude Code 會讀取員工電腦上的檔案、執行指令，還能連上網路。「我知道它能讓事情變快。但萬一出事了誰要負責？」很多公司大概都卡在這個關卡。
一家大型企業為這個焦慮給出了答案。Mercari 最近在一場讀書會上，分享了他們在將 Claude Code 部署給數百名員工時所使用的「安全設定與佈署方法」。
而且，內容並非昂貴的專屬系統。只要準備並佈署一個設定檔，就連中小企業也能複製大部分的做法。
Mercari 之所以能發送給數百人，靠的不是高成本的機制，而是一個「員工無法移除的設定檔」。中小企業從今天起也能做到。
在這篇文章中，我會盡可能簡單地拆解 Mercari 的設計，涵蓋「該怕什麼」、「Mercari 如何管理」以及「你的公司可以從哪裡開始」。我會在提及技術名詞時補充說明，讓非工程師背景的主管和產品經理也能跟上。
你可以在此處找到他們引用的簡報資料：
(Mercari Claude Code 組織部署安全設定 / Speaker Deck
設定的確切語法已根據 Anthropic 的官方文件進行了驗證。
為什麼 Claude Code 既「方便又可怕」？
首先，讓我們釐清恐懼的本質。我認為，如果沒有理解這點就複製設定，你根本不知道自己在保護什麼。
Claude Code 與標準聊天 AI 的不同之處在於，它可以自主在你的本機電腦上行動。它可以搜尋並讀取檔案、改寫它們，以及執行 Shell 指令（在終端機中輸入的指令）。它也能存取網路。換句話說，你在那台電腦上能做的幾乎所有事，AI 也都能做。
具體來說，可能會出什麼問題？電腦裡通常藏著你不希望被看到的東西：
- 作為雲端或 API 密碼的資訊（如 .env、~/.aws/credentials 等設定檔）
- 登入伺服器的金鑰（~/.ssh/ 的內容）
- 刪除會造成災難的重要檔案
AI 沒有惡意。然而，由於模糊的指令或網路上可疑文字中嵌入的指令（稱為提示注入），它可能不小心讀取這些秘密檔案並傳送到網路，或使用 rm 指令刪除重要項目。Anthropic 的官方文件建議根據這些風險來設計權限限制（權限設定 - 官方）。
簡而言之，需要保護三件事：防止秘密資訊外洩、防止自動執行危險操作，以及從根本上縮小可觸及的範圍。 透過這三個角度來閱讀，Mercari 的措施就變得容易理解多了。
拆解 Mercari 的「5 項措施」
Mercari 的簡報總結了五項主要措施。我們將逐一探討每項措施的「目的」與「實作方法」。
請注意，簡報投影片著重於概念，並未包含設定檔的所有細節。因此，我將以 「如何使用 Claude Code 的官方設定來實作 Mercari 的政策」 的形式來呈現。所有關鍵名稱和語法均經由 Anthropic 官方文件驗證。
措施①：讓人類確認變得「不可跳過」
Claude Code 有一種模式，可以無需每次都要求確認就自動執行。雖然這對開發者在自己測試用的電腦上很方便，但如果讓公司裡的每個人都能用，就等於拔掉了安全煞車。
Mercari 停用了這個「跳過確認模式」。官方提供了如 permissions.disableBypassPermissionsMode（以及封鎖自動模式的 disableAutoMode）等設定。將這些設定為「停用」即可防止使用者進入那些模式。此外，如果將它放在稍後會提到的「受管設定」中，員工就無法自行停用它們（權限設定 - 官方）。
意思很簡單：它在整個公司強制執行「在 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）很容易被重新導向繞過。因此，官方建議是完全封鎖網路通訊，並透過一個獨立的安全入口來統一進行必要的擷取（權限設定 - 官方）。這個「安全入口」就是 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 所寫的腳本在背景偷偷打開檔案（權限設定 - 官方）。這就是為什麼需要措施④。
措施④：用沙箱包裹「觸及範圍」
拒絕清單是為特定指令畫線，而沙箱則是在作業系統層級建立一道牆。它從物理上限制 AI 觸及工作資料夾以外的任何東西，或連接到允許的網際網路網域以外的任何內容。
1{2 "sandbox": {3 "enabled": true,4 "network": {5 "allowedDomains": ["*.github.com", "registry.npmjs.org"]6 }7 }8}
啟用後，即使 AI 不小心去抓取秘密檔案，也因為檔案在「沙箱」之外而無法取得。官方文件說明，你應該同時使用拒絕清單（措施②和③）和沙箱作為最終的邊界，來構築多層防禦（沙箱化 - 官方）。想像成同時擁有個別規則和一道圍牆。
一個限制：沙箱功能可在 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（行動裝置管理——一種公司管理員工電腦的系統）來同時佈署員工無法覆寫的「受管設定」。Claude Code 有一個專門的受管設定位置，其優先級高於個人設定且使用者無法變更。在 macOS 上，路徑是 /Library/Application Support/ClaudeCode/managed-settings.json（設定 - 官方）。將措施①–④寫在這裡，現場就無法放寬限制。
更聰明的是，他們針對工程師和非工程師區分安全等級：
- 針對工程師：允許一定程度的客製化，且不會過度妨礙生產力的設定。
- 針對非工程師：最安全的預設設定，較少調整空間。
即使是同一種工具，他們也會根據使用者的技術素養來調整繩子的長度。如果每個人都嚴格限制，工作會停擺；如果每個人都寬鬆，則會發生事故。他們透過改變佈署的設定來解決這個問題。
中小企業可以從哪裡開始複製
大多數公司可能沒有 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 這類的條件式權限很容易被繞過。完全封鎖危險的東西，並提供一個安全的替代方案，會更穩固。 - 不要只佈署設定就了事。即使你強制實施了受管設定，如果員工自己安裝其他可疑的工具，那也是白費力氣。設定是一種「減少事故的機制」，與使用教育搭配才能發揮最佳效果。這就是措施⑤「讓他們讀規則」最終派上用場的地方。
進階使用者常見問題
Q. 個人使用設定這個有意義嗎？
有。判別標準是那台電腦上是否有秘密資訊，而不是是否為公司使用。自由工作者和個人開發者本機上仍然有 .env 和 ~/.ssh/。至少，加入措施③的讀取禁止是比較安全的。
Q. 限制權限會不會讓 AI 變得沒用？
這取決於你如何限制。唯讀指令（如 ls 或 cat）預設運作不需要確認，所以日常工作幾乎不會受阻。會被阻止的是刪除、發佈和網路通訊這類一旦出錯就會造成傷害的操作。事實上，透過轉變為「只在危險時才由人類檢查」，你可以安全地擴大讓 AI 自動執行的範圍。
Q. `settings.json` 和受管設定（`managed-settings.json`）有什麼不同？
位置和「強度」不同。專案 .claude/ 資料夾中的 settings.json 是任何人都可以編輯的共享設定。managed-settings.json 則由公司佈署，使用者無法變更。對於個人或小團隊，前者就夠了；當你進入「有人放寬設定會出問題」的階段時，再轉向後者。
Q. 同樣的概念可以應用在 Cursor 或其他 AI 程式碼工具上嗎？
你想保護的東西（秘密、危險操作、觸及範圍）是相同的，所以概念適用。但語法和是否支援沙箱功能因工具而異，請將這個 settings.json 視為 Claude Code 專用的表示法。如果使用其他工具，捷徑就是將這三個觀點套用到它們各自的官方文件上。
總結：從「不要用」到「安全地佈署」
在我收到的 AI 導入諮詢中，最常見的反應曾經是「太危險了，所以我們還不能讓人用」。但這個決定同時也拋棄了所有的便利性。
Mercari 為我們指出了脫離那個二元選擇的道路。停用確認跳過、停止危險操作、禁止觸碰秘密檔案、用沙箱封閉起來，並讓他們讀規則。然後，將這些以無法被篡改的設定形式佈署給所有人。這是一個將「因為可怕所以禁止」轉變為「因為可怕，所以繫上繩子再佈署」的設計。
- 保護目標：防止秘密洩漏 / 防止危險操作 / 縮小觸及範圍。
- Mercari 的 5 項措施：停用跳過、限制危險指令、禁止秘密檔案、沙箱化、規則閱讀。
- 佈署：使用使用者無法覆寫的受管設定，並根據技術素養區分。
最後，這裡有三個從今天就能開始的步驟：
- 在你自己的電腦上加入 `Read(.env)`：從禁止讀取秘密檔案開始。這是最有效的一步。
- 製作一個最小設定集的單一檔案：以上面的
permissions為例，加入你們公司想停止的指令。 - 發送給公司內的一個人測試：讓他貼到
.claude/settings.json中，並一起確認工作不會停擺。
第一步，只是保護 .env 的一行設定。你可以從那裡開始，一層一層地疊加出完美的多層防禦。何不今天就把第一個檔案放好，將「因為可怕所以停止」轉變為「繫上繩子委派任務」呢？
