強化 Claude Code 安全：實用最佳實踐指南

Claude Code 能夠讀取您的儲存庫、編輯檔案、執行 shell 指令並呼叫 MCP 伺服器。這正是它實用的原因，也正是它值得您像對待具有生產憑證的 CI 執行器一樣謹慎對待的原因。本指南彙整了 Claude Code 在日常工作中經得起考驗的安全最佳實踐：包括如何配置、每個設定為何重要，以及每個防護層的極限。

簡而言之，請假設代理最終會讀取到惡意內容（例如 README、問題、網頁或工具結果），並確保即使發生這種情況，它所能造成的損害也是微乎其微的。

大多數實際風險來自於單一會話中三種情況的結合：模型讀取到不受信任的內容、它能接觸到的敏感資料（例如 .env、~/.aws、SSH 金鑰、MCP 配置中的權杖），以及一個可供其行動的通道（例如 shell、網路、git push 或一個會寫入的 MCP 工具）。

提示詞注入是常見的觸發因素，但一個無心之過，例如帶有空變數的清理指令，或一個自信的 git reset --hard，也會造成同樣的損害。以下每項實踐都旨在移除這三種要素之一，或在它們之間設置一個檢查點。

1. 編寫明確的權限規則，而非點擊提示詞通過

Claude Code 從 JSON 設定檔中讀取權限規則。規則分為三種類型：允許 (allow)、詢問 (ask) 和拒絕 (deny)，每種都指定了工具及其可執行的操作。以下是 ~/.claude/settings.json 或專案的 .claude/settings.json 中一個合理的起始設定：

{"permissions": {"allow": ["Bash(npm run lint)", "Bash(npm run test *)"],"ask": ["Bash(git push )"],"deny": ["Read(./.env)", "Read(./.env.)", "Bash(git push --force *)", "Bash(rm -rf *)"]}}

設定文件中有一些細節值得注意：列表會在不同範圍內合併。使用者、專案、本地和受管理的權限允許列表會合併；一個檔案不能默默地移除另一個檔案的條目。在已提交的專案檔案中的拒絕 (deny) 和詢問 (ask) 規則會立即生效，而專案的允許 (allow) 規則則會等到每個人信任該資料夾後才生效。這種順序是比較安全的。

當從專案或本地設定中設定時，bypassPermissions 和 auto 預設模式會被忽略。被複製的儲存庫無法悄悄地關閉您的提示。將指令模式規則視為絆腳索，而非堅固的牆。Bash(rm -rf *) 不會匹配 rm -fr、rm -r -f 或 find . -delete。模式規則擅長捕捉常見的拼寫，但它們並非「破壞性」操作的完整描述。

2. 透過所有途徑拒絕存取機密，而非僅限單一途徑

Read(./.env) 僅阻止 Read 工具。它本身並未提及透過 Bash 執行 cat .env、在儲存庫中進行 Grep，或根植於您家目錄的 MCP 檔案系統伺服器。在您新增拒絕規則後，請自行測試其他途徑：要求代理執行 cat、grep 和 less 同一個檔案，並確認每個操作都被拒絕。

更好的做法是，將生產機密完全從開發機器上移除。在執行時，從機密管理器中將它們注入到需要它們的指令中，這樣工作樹中就沒有代理可以讀取的內容了。

3. 定期審查「是，且不再詢問」所累積的設定

當您批准一個 Bash 指令並選擇「是，且不再詢問」時，Claude Code 會將一個允許規則儲存到 .claude/settings.local.json 中。這些批准會悄悄地累積起來。每隔幾週打開該檔案，刪除任何比您有意願授予的權限更廣泛的設定，例如 Bash(python *) 或 Bash(curl *) 授予的權限遠超過您原本打算批准的單一指令。

4. 分享基準設定；為團隊集中執行

提交 .claude/settings.json，以便每個複製的儲存庫都獲得相同的拒絕列表。對於組織而言，受管理的設定凌駕於所有其他設定之上，且無法被使用者或專案檔案覆寫。將您的不可協商事項（例如機密路徑、強制推送、生產部署指令）放在那裡，並允許個人在本地新增方便的允許規則。

5. 將每個 MCP 伺服器視為帶有您憑證的第三方程式碼

MCP 伺服器定義存在於 Claude Code 自己的配置中。每個伺服器都是一個以您的使用者權限執行的程序，並且通常持有權杖。實用規則包括：固定版本，而非使用 npx -y some-server@latest。將檔案系統伺服器的範圍限制在專案目錄，絕不要設定為 / 或 ~。盡可能將權杖從內聯環境區塊中移除；任何內聯的內容都可以被能夠讀取配置檔案的任何東西讀取。移除本週未使用的伺服器。

6. 使用 PreToolUse 鉤子來測試您想實施的規則

鉤子允許您在工具執行前運行自己的程式。對於 PreToolUse，Claude Code 會將 JSON 負載（工具名稱和輸入）寫入鉤子的標準輸入，並讀回一個 JSON 決策。返回 permissionDecision: "deny" 並附帶原因會阻止該呼叫，並向模型顯示原因，這通常會讓模型重新規劃，而不是重試。

{"hooks": {"PreToolUse": [{"matcher": "Bash|Write|Edit|WebFetch", "hooks": [{"type": "command", "command": "node /path/to/your-hook.mjs"}]}]}}

相較於靜態模式，鉤子的優勢在於它可以標準化指令、在解析路徑後進行檢查、查看會話歷史記錄，並像任何其他程式碼一樣在 CI 中進行單元測試。

7. 隔離不受信任的工作

對於您未編寫的儲存庫，請在沒有掛載主機憑證且網路出口受限的容器或虛擬機中運行 Claude Code。Claude Code 也提供了 Bash 沙盒選項，請務必使用。隔離是當上述所有規則都稍有錯誤時，仍能提供保護的最後一道防線。

8. 記錄代理的決策與行為

當出現問題時，「代理執行了什麼，以及是什麼允許它執行？」這個問題應該在一分鐘內就能回答，而不是花一個下午去挖掘 shell 歷史記錄。請記錄決策及其產生的規則，並將日誌保存在代理無法編輯的地方。

Cirvix 的應用

Cirvix AgentControl 是一個開源（Apache-2.0 授權）的策略層，它透過一個策略檔案涵蓋了上述兩個層面。它會在受控工具呼叫執行前進行評估，並返回允許 (permit)、暫停 (hold, 等待指定審批者) 或拒絕 (deny)，預設為拒絕。對於 Claude Code，有兩種途徑，它們是互補的：

MCP 閘道。Claude Code 將 Cirvix 閘道作為其唯一的 MCP 入口；Cirvix 會啟動您的真實伺服器，並首先評估每個路由的工具呼叫。

PreToolUse 鉤子。儲存庫中的 integrations/claude-code/hook.mjs 會透過 socket 將內建工具呼叫（Bash、Write、Edit、WebFetch）發送到本地的 Cirvix 運行時。預設情況下，如果運行時未運行，鉤子會以標準錯誤警告的形式開放失敗；在 CI 或任何需要封閉失敗行為的地方，請設定 CIRVIX_HOOK_FAIL=closed。

您可以在不到一分鐘的時間內嘗試一個決策，而無需執行任何操作：npx --yes @cirvix_ai/agent-control check --action fs.read --resource .env.production # DENY fs.read …/.env.production rule deny-dotenv-read (exit 1)。

請明確其界限：Cirvix 管理透過閘道、鉤子或其 SDK 包裝器路由的呼叫。它不檢查提示詞，不阻止提示詞注入，也不會看到您自己輸入的終端機。它限制了被注入或錯誤的代理可以做的事情，這是您實際可以控制的部分。

檢查清單

[ ] 為機密、強制推送和破壞性指令設定明確的拒絕規則

[ ] 測試了所有存取機密的途徑（Read、Bash、Grep、MCP）

[ ] 審查了 .claude/settings.local.json 中的批准設定

[ ] 提交了共享專案設定；組織規則位於受管理的設定中

[ ] MCP 伺服器已固定版本、限制範圍並清除

[ ] 為可測試的策略設定了 PreToolUse 鉤子（或閘道）

[ ] 不受信任的儲存庫在隔離環境中運行

[ ] 決策日誌保存在代理無法編輯的地方

Cirvix AgentControl 是開源的：https://github.com/CIRVIX/agent-control

更多指南和文件：https://cirvix.com