「我知道這工具很好用，但讓 AI 在員工電腦裡自動執行指令，老實說不會很恐怖嗎？」
這是在評估導入生成式 AI 輔助開發工具時，許多企業管理者與資安主管心中最真實的顧慮。
與在瀏覽器中運作、環境相對封閉的網頁版 AI 不同，Claude Code 是一套直接深入本機開發環境的工具。它能讀寫檔案、自動執行終端機指令、還能存取網際網路。換句話說，這部電腦的使用者能做什麼，AI 基本上也拿到了相近的權限。
如果在缺乏配套防護的情況下開放使用，機密資料外洩、重要專案檔案被誤刪等意外確實可能發生。
然而，日本大廠 Mercari 在技術分享會中，給出了一個極具參考價值的解答。他們並沒有採用昂貴或高難度的專門防護系統，而是僅憑「一張員工無法自行修改的設定檔」，就成功在內部數百人規模的團隊中，安全地分發並啟用了 Claude Code。這套防禦邏輯不只適用於跨國大廠，中小企業也完全可以無痛複製。
究竟在擔心什麼呢？
Claude Code 擁有極高的操作自由度，而其潛在的安全問題主要集中在以下三個核心問題。
第一個問題是金鑰與敏感資料外洩。開發人員的本機電腦中，通常存放著用來串接外部服務的環境變數檔案（例如 .env 檔案），或是用於登入伺服器的私鑰路徑。AI 在進行程式碼分析時，有可能在無意間讀取到這些敏感檔案並將內容傳出。
第二個問題是惡意指令執行。不論是因為人類給出了語意不詳的模糊指令，或是遭遇了網路上惡意文章中夾帶的「提示詞注入攻擊」（Prompt Injection），AI 都有可能被誘導去執行具有破壞性的終端機命令，例如刪除重要檔案的 rm 指令。
第三個問題則是權限邊界模糊。當 AI 的存取範圍沒有被嚴格限制在專案目錄內時，它就可能跨越邊界去觸碰系統核心路徑。
Mercari 的五大安全防禦心法
針對上述風險，Mercari 提出了五項核心防禦對策，對照 Anthropic 官方文件，將其具體落實為以下設定邏輯。
強制保留人類決策權：禁止略過確認
Claude Code 具備全自動執行任務的無人值守模式。在個人測試環境中這很方便，但在企業內部，這無疑是拿掉安全煞車。Mercari 透過設定直接封鎖了略過確認與自動執行的模式。這確保 AI 在執行任何實質修改或終端機指令前，畫面一定會停下來，等待人類開發者確認後才繼續。
限縮危險指令：設定黑名單與詢問機制
針對高風險指令，必須建立嚴格的過濾機制。例如用來從網路下載與傳送資料的 curl 與 wget 指令，很容易被利用來將機密檔案往外傳送。Mercari 在設定中將此類指令列入拒絕名單（deny list）。對於敏感但必要的指令，則設定為每次執行都必須向人類確認（ask list）。
機密檔案防護隔離：預防性拒絕讀取
為了防止 AI 將密碼、API 金鑰或系統金鑰流出，必須在底層直接封鎖特定敏感檔案與目錄的讀取權限。這包含專案中的環境變數檔、SSH 金鑰目錄，以及具備系統最高權限的 sudo 指令。
建立系統級沙箱：徹底限縮活動範圍
如果前面的黑名單是針對特定指令的防禦，那麼沙箱技術（Sandbox）就是實體空間的圍牆。透過啟用沙箱機制，能將 AI 限制在特定的專案目錄與安全域名內。即便 AI 被誘導嘗試執行越界操作，也會因為沙箱的物理屏障而無法得逞。
CyberQ 提醒， Claude 的沙箱機制目前支援 macOS、Linux 與 Windows 上的 WSL2 環境，若在 Windows 原生環境中執行，則需要更仰賴權限控制黑名單。
建立 AI 的行為守則：每一次對話都進行宣導
除了硬性的程式碼阻擋，軟性的規則宣導同樣能發揮功效。我們可以在專案根目錄放置名為 CLAUDE.md 的規則檔案，Claude Code 在每次啟動時都會主動閱讀此檔案。
Markdown
# 安全宣告與守則
請注意環境變數檔案與金鑰檔案絕不開啟
請確認顧客資料與社外機密不傳送至外部
請務必在執行任何刪除或公開操作前取得人類確認
不只設定好，更要配得聰明
Mercari 這套作法最值得借鏡之處，在於他們如何將設定安全地部署到數百人的電腦中，且不被員工自行修改。
在一般情況下，設定檔由員工本機管理，這代表員工可以隨意更改或關閉安全限制。為了避免防禦設定被自行停用的資安漏洞，Mercari 利用行動裝置管理系統（MDM），將設定檔統一寫入系統級的唯讀目錄。在此目錄下的設定具有最高優先權，且員工無權修改。
此外，他們針對不同職能進行了設定分流：
| 職能團隊 | 設定策略 | 調整權限 |
| 工程師團隊 | 提供保有適度彈性、不影響開發效率的最佳化設定 | 允許部分自訂 |
| 非技術人員 | 提供最為嚴格、不開放客製化調整的預設安全配置 | 完全唯讀鎖定 |
中小企業的無痛導入指南
即使企業目前沒有部署 MDM 系統，依然可以參考這套架構。只要將設定檔分享給團隊，並放置在各自的 .claude/settings.json 中，就能立即建立起第一道防禦網。
以下是我們結合 Mercari 的防禦思維與 Anthropic 官方規範，為您整理出的即用型 JSON 安全設定檔：
JSON
{
"permissions": {
"disableBypassPermissionsMode": "disable",
"deny": [
"Bash(curl:*)",
"Bash(wget:*)",
"Bash(sudo:*)",
"Read(.env)",
"Read(.env.*)",
"Read(**/.ssh/**)"
],
"ask": [
"Bash(git push:*)",
"Bash(rm:*)"
]
},
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["*.github.com", "registry.npmjs.org"]
}
}
}
導入前必須釐清的三個資安盲區
在將設定檔分發出去之前，請務必理解技術的邊界。
首先，拒絕名單並非萬無一失。雖然我們限制了 curl 指令，但如果 AI 撰寫了其他程式語言的腳本在背景執行網路通訊，單純的終端機指令過濾很難完全防堵。這也是為什麼必須搭配沙箱機制，從系統層級進行雙重阻絕。
其次，切勿過度依賴細粒度的條件式許可。例如嘗試去寫「只允許連線到特定 GitHub 網址的 curl 指令」，官方已明確指出此類引數限制極易被繞過。安全的作法是直接全面禁止危險指令。
最後，設定檔只是工具，安全防護的根本在於使用者的資安意識。技術阻擋能降低意外，但日常的工具安全教育，才是長治久安的解答。
從害怕而禁用走向安全地賦能
過去，許多企業面對強大的 AI 開發工具，往往因為未知風險而採取全面禁用的保守策略。然而，這也意味著企業同時放棄了大幅提升生產力的機會。
Mercari 的實踐展示了可行的第三條路，理解風險、套上韁繩、安全配發。從今天開始，您可以先從最簡單的一步做起，在專案目錄下建立 .claude/settings.json，並寫入阻擋讀取 .env 的設定。用漸進式的方式，讓團隊在安全的防護傘下，充分享受 AI 帶來的工作效率革命。
