文章目錄
Claude Code 到底安不安全？先看權限模式，不要只看資安新聞
Claude Code 安全嗎？直接給結論：工具本身不危險，危險的是你開了什麼權限。預設的 Default 模式每次動手都要你按下批准，這個狀態下的 Claude Code 比大多數 AI 工具都保守；真正出事幾乎都是因為有人開了 Bypass Permissions、或把 allow 規則寫成 Bash(*) 全開。你會在網路上看到一堆資安媒體報 Claude Code 的沙箱繞過、prompt injection、供應鏈攻擊，這些是真實風險沒錯，但對一般開發者來說，先把權限設定顧好就能擋掉八成的事故，剩下兩成才需要去煩進階攻擊面。如果你還沒把 Claude Code 跑順，先回到 Claude Code 完整教學 把安裝與常用指令弄熟，再回來這篇調安全設定。
安全這件事要拆兩層看。第一層是「工具本身的安全性」，這要看 Anthropic 的資料政策、有沒有通過 SOC 2、你的程式碼會不會被拿去訓練模型，這部分取決於你用什麼帳號類型。第二層是「你給的權限」，這完全是你的 settings.json 說了算，模型再聰明也只能在你畫的圈圈裡動。很多開發者把這兩層混在一起談，一聽到「AI 會自動改檔案」就慌，其實只要你在 Default 或 Accept Edits 模式，每一個高風險動作都會先經過你的眼睛。
給你一個判斷框架，這個框架我用在每一個新專案：先問自己「這個任務最壞會改到什麼檔案、會跑什麼指令」，再決定開哪種模式。改一行文件，Default 就夠；跨十個檔案重構，先進 Plan Mode 讓它列出計畫再放行；要動 production 部署或刪資料，務必 deny 規則加上 PreToolUse hook 雙保險。資安媒體喜歡把焦點放在模型可能被誘騙的進階攻擊面，但實務上絕大多數事故不是這類劇本，而是開發者自己開了太寬的權限讓模型誤觸。先把自己這端可控的部分設好，再談進階威脅，這是務實的順序。
這個判斷框架其實適用於所有 agentic 工具，不局限於 Claude Code。任何會「自動讀寫檔案、自動跑指令」的 AI coding agent，風險結構都一樣：模型是執行者，權限是閘門，閘門開多寬決定爆炸半徑。所以與其爭論哪個工具「比較安全」，不如把心力放在把自己手上這個工具的閘門設對。這也是為什麼這篇不打算去比各家 agentic 工具的資安新聞，而是直接給你一份可複製的設定範本，因為設定才是你能控制、而且立刻見效的變數。把「安全嗎」這個大問題，拆成「我的 settings.json 寫對了嗎」「我開對模式了嗎」這些小問題，答案就會浮現。
Claude Code 安不安全，90% 取決於你開的權限模式與 settings.json 規則，預設 Default 每步都問你，這個狀態比你想的安全得多。
四種權限模式總覽：Default、Accept Edits、Plan、Bypass 各適合誰
Claude Code 有四種權限模式，按 Shift+Tab 循環切換，搞懂這四種就等於搞懂安全設定的骨架。Default 模式最保守，讀檔、編輯、跑指令全部都要你按確認；Accept Edits 模式信任 Claude 改檔，但跑 Bash 指令仍然要你點頭；Plan 模式只讀檔案提出計畫，什麼都不能改；Bypass Permissions 全自動不問，只該用在 CI 或隔離容器。如果你剛開始用，先回到 Claude Code 教學 把基礎跑順，再回來調安全設定。
| 模式 | 讀檔 | 編輯檔案 | 執行指令 | 最壞情況 |
|---|---|---|---|---|
| Default | 問 | 問 | 問 | 你不專心按錯批准，損失可控 |
| Accept Edits | 自動 | 自動 | 問 | 改碼太快沒看，但指令仍卡關 |
| Plan | 自動 | 禁止 | 禁止 | 只能規劃，最安全但無法執行 |
| Bypass Permissions | 自動 | 自動 | 自動 | 本機等於交出完整控制權 |
多數開發者的甜蜜點是 Accept Edits。改程式碼自動放行讓迭代速度起來，跑 Bash 指令仍要你確認，這條線剛好把「會產生副作用」的動作守住。我自己改 SEO 文章 HTML 就常駐 Accept Edits，因為寫檔風險低、但 git push 或部署指令一定得過我眼睛。Default 模式則適合碰陌生專案、或剛開始建立信任的階段，它會問到你煩，但煩就是它的安全機制，這份「煩」正是讓你有機會在按確認前把模型要做的事看清楚。
Bypass Permissions（對應 defaultMode: bypassPermissions）千萬別在本機常駐。它讓所有動作全自動不問你，一次 rm -rf 走錯目錄就無法挽回。你會在 OpenAI Codex 那種 agentic 工具看到類似的「全自動」取向，治理與權限模型的差異我們有完整的對照文，這裡只專注 Claude Code 單工具怎麼設。Bypass 真正合理的場合是 CI/CD pipeline，在用完即丟的容器裡讓它自動跑測試與部署，本機請保持 Default 或 Accept Edits。把全自動模式留在它該在的地方，是安全設定的第一條常識。
順帶一提，Accept Edits 與 Default 之間的切換頻率，本身就是一個工作風格的訊號。如果你發現自己整天在 Default 裡按確認按到煩，代表你對這個專案已經夠熟，可以考慮升到 Accept Edits 提速；反過來如果你在 Accept Edits 裡連續好幾次沒看就讓它跑，代表風險在累積，這時退回 Default 重新建立警覺反而比較安全。模式不是設一次就固定，它應該跟著你對任務的熟悉度動態調整，這才是務實的用法。
模式可以在 settings.json 的 defaultMode 指定開機預設值，不必每次手動切。例如寫 "defaultMode": "acceptEdits"，每次開 session 就是 Accept Edits，省去 Shift+Tab 的步驟。但要記得，預設開哪個模式本身就是一個安全決策，團隊導入時這個欄位應該由資安覆核定案，不是個人隨手設。個人開發可以依任務風險自己挑，公司導入則應該統一規範，避免每個人開不同模式造成行為不一致、出事難追。這跟做 技術 SEO 時強調「設定要一致、可追蹤」是同樣的治理直覺。
Plan Mode 怎麼用才有效：先規劃再動手的四步節奏
Plan Mode 讓 Claude Code 進入唯讀規劃狀態，只能讀檔案、提出計畫，不能改任何東西。正確用法是四步節奏：進 Plan Mode 讓它探索與規劃，讀它給出的計畫內容，確認方向沒問題，再切回 Default 或 Accept Edits 執行。不要在 Plan Mode 裡期待它動手，那是它設計上禁止的事，你叫它改檔它只會回說「我在 Plan 模式，沒辦法執行」。這個限制不是缺陷，是安全設計：先讓你檢視判斷、再放行執行，把「想清楚」與「動手」強制分成兩階段。
什麼時候該進 Plan Mode？三個情境特別值得。第一是第一次碰陌生 repo，你不熟架構，讓它先 Plan 一輪把地圖畫出來，比你自己一行一行 trace 快得多。第二是跨多檔重構，動到十幾個檔案那種，先看計畫再下手能避免改到一半發現方向錯，省下回滾的成本。第三是要下高風險指令前，例如刪檔、部署、改資料庫 migration，先 Plan 等於先體檢，把最壞情況攤在陽光下。日常改個 typo、補一行註解這種小修，不必每次都進 Plan，那是過度流程，反而拖慢節奏。
Plan 輸出怎麼判讀是關鍵。一份好的 Plan 會列出「要動哪些檔案、為什麼動、改動順序、有沒有要跑測試」，你讀的時候問自己三件事：它列的檔案清單合不合理、改動順序會不會踩到相依性、它有沒有漏掉測試或文件。這三個問題的答案，就是這個模型在這個任務上「判斷可信度」的體檢報告。這個流程跟做 技術健檢 很像，都是先盤點現況、列清單、再決定動哪裡，差別只在這裡盤的是程式碼而不是網站結構。模型列得越細、越能說出理由，代表它對這個任務的理解越扎實；反之它只給一句「我會改這幾個檔案」就帶過，那這份 Plan 的參考價值就有限，你得更謹慎。
Plan Mode 不是萬能。它只讀不驗證，模型看起來想得很對，實際跑起來可能爆掉，尤其是複雜邏輯或牽涉外部 API 的情境。Plan 通過不等於結果正確，這句話請記住。想兼顧判斷品質與成本，可以用 /model 指令在 Plan 階段切到 Opus 規劃、執行階段切回 Sonnet，Opus 的推理力強、Sonnet 的速度快又省，這個搭配在 Claude AI 教學 的模型段落有更完整的特性說明，這裡只談它們在 Plan 與安全上的搭配。切回執行前，建議先 /clear 或開新 session，避免 Plan 階段累積的探索上下文污染執行，這是很多人忽略的細節，但對執行品質影響很大。讀完 Plan 切回執行時，也可以順手把 Plan 文字存成一份 todo 清單，執行過程逐項打勾，這樣即使 session 中斷，你也不會迷失方向，這個習慣在長任務裡特別有用。
settings.json 權限怎麼設：allow、deny、ask 規則語法與覆蓋順序
settings.json 的 permissions 區塊是 Claude Code 權限控制的核心，用 allow（自動放行）、deny（永遠擋下）、ask（每次彈窗問你）三類規則控制它能跑什麼、能讀什麼。覆蓋順序是 deny 永遠優先，再來 allow，最末才是 ask。這個順序很重要，寫規則時先把高危指令放進 deny，即使 allow 裡有更寬的規則也照擋不誤。理解這個覆蓋順序，等於理解了整個權限系統的運作邏輯，剩下的只是把規則填進對的欄位。
規則語法不複雜，幾個最常用的：Bash(npm test) 放行某個固定指令、Bash(git status*) 用萬用字元放行某一類指令、Read(//Users/Downloads/**) 用雙斜線絕對路徑管制讀取範圍、WebFetch(domain:github.com) 限定只能抓特定網域。雙斜線是絕對路徑的標記，單星號匹配一層、雙星號 ** 匹配多層子目錄，這跟 .gitignore 的語法是同一套邏輯，會寫 gitignore 就會寫這些規則。寫規則時建議從最窄、最明確的指令開始放，確認安全再逐步放寬，而不是反過來先全開再刪，後者很容易在「再刪」那一步忘記，留下看不見的漏洞。
deny 優先級最高，這是它的超能力。把 rm -rf、curl 外傳、寫入 .env 這類指令放進 deny，就算你之後手滑在 allow 寫了 Bash(*) 全開，deny 還是會把它擋下來。這是為什麼安全設定要從 deny 開始寫，而不是從 allow 開始放。ask 規則則適合放你不確定要不要長期放行的指令，每次彈窗讓你判斷，比全 allow 安全、又比全 deny 不卡流程，是個有用的中間地帶，特別適合 npm install、docker build 這種有時候安全、有時候有副作用的指令。
寫規則時有兩個常見錯誤值得點出。第一個是萬用字元用太寬，例如 Bash(npm *) 看似只放行 npm 相關指令，但 npm 生態裡有很多會執行任意腳本的指令（如 npm run），等於間接放行了整個 package.json 裡定義的任何腳本，風險比你想的大。第二個是路徑規則沒用絕對路徑，寫成 Read(.env) 只擋當前目錄的 .env，子目錄裡的就漏掉了，正確寫法是 Read(**/.env) 用雙星號覆蓋所有層級。這兩個細節是新手最容易踩的坑，寫規則時多花一分鐘檢查萬用字元範圍與路徑覆蓋，能省下後續無數的除錯時間。
settings.json 有三層，優先級是 enterprise（公司管理員設，員工不能改）高於 project（.claude/settings.json，會進 git 給全團隊共用）高於 local（settings.local.json，放個人路徑與偏好、不進 git）。公司導入時，機敏指令的 deny 規則應該寫在 enterprise 層，這樣員工就算在自己 local 設定了相反的 allow 也會被覆蓋掉。這個三層覆蓋機制是 Claude Code 安全治理的基石，資安覆核時務必確認 enterprise 層有把該擋的擋住。想即時查看與新增規則，不必每次改檔，用 /permissions 指令能在對話中直接操作，非常方便。三層之間的優先級還有一個實務含義：當行為跟你預期不符時，先查是不是上層的規則在覆蓋你，而不是懷疑自己寫錯，這個除錯順序能省下很多冤枉時間。
可複製範本：擋住 .env、憑證與 lock 檔的 settings.json 與 PreToolUse hook
這一段是整篇最有價值的設定範本，直接取自這個 codex 倉庫真實在用的生產設定。這個倉庫本身就用 Claude Code 操作 WordPress 與 Cloudflare，settings.json 裡的 PreToolUse hook 實際擋下過對 lock 檔與機密檔案的誤改。做法是用 PreToolUse hook 在每次 Edit 或 Write 工具呼叫前檢查目標檔名，命中 .env、憑證、key、lock 檔等模式就直接 exit 1 阻擋，這比單純寫 deny 規則更可靠，因為它攔在工具實際執行前，而且可以寫任意自訂邏輯。很多教學文列了一堆安全建議，卻從來不給可複製的範本，這一段就是要補上那個洞。
先看 settings.json 的精簡範本：
{
"defaultMode": "acceptEdits",
"permissions": {
"allow": [
"Bash(npm test)",
"Bash(git status*)",
"Bash(git diff*)",
"Read(//Users/sliven/seo/**)"
],
"deny": [
"Read(.env)",
"Read(**/.env)",
"Read(**/*.pem)",
"Read(**/credentials*.json)",
"Bash(rm -rf*)",
"Bash(curl*)",
"Bash(git push*)"
],
"ask": [
"Bash(npm install*)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path // empty' | grep -qiE '(\\.env|credentials.*\\.json|\\.pem$|\\.key$|lock\\.json|\\.p12$)' && exit 1 || exit 0"
}
]
}
]
}
}這個 hook 命令的運作邏輯是這樣的：matcher: "Edit|Write" 限定它只在 Edit 或 Write 工具呼叫時觸發，讀檔或其他工具不會誤觸。hook 收到的 JSON 裡有 tool_input.file_path，用 jq 取出來，再用 grep 比對敏感檔名模式，命中就 exit 1 讓 Claude Code 直接中止這次工具呼叫並回報阻擋，沒命中就 exit 0 放行。與規則相比，hook 的優勢是攔截點更早、可以寫正規表達式做複雜判斷，而且 hook 觸發時會在終端機印出明確訊息，除錯比規則容易。你可以把敏感模式清單擴充到 .p12、.keystore、id_rsa 等任何你專案會出現的機密檔，彈性遠高於固定規則。
把這份範本存成 .claude/settings.json 進 git，團隊每個人 clone 下來就自帶護欄。個人的絕對路徑或偏好則放 settings.local.json，記得加進 .gitignore 排除，免得把自己的家目錄路徑推上去。想再收緊一層，可以用 additionalDirectories 限制 Claude Code 只能存取哪些目錄，把它關在專案資料夾裡，跨目錄亂讀的風險就沒了。這套設定不是理論，是這個倉庫每天在跑的生產配置，PreToolUse hook 真的擋下過我對 lock 檔的幾次誤改，省下不少除錯時間。鎖檔與機密管理的概念，也跟 WordPress 安全與 SEO 優化 裡強調的「最小權限」是同一件事：給的權限越剛好、越窄，出事的爆炸半徑就越小。
Claude Code 安全嗎：你的程式碼會被拿去訓練嗎？Team vs Pro vs Enterprise 對照
「我的程式碼會被拿去訓練嗎？」這是公司導入時法務一定會問的問題，答案取決於你的帳號類型，而不是工具本身。Team、Enterprise、API 這類商業方案的程式碼明確不用於模型訓練；消費者方案（Free、Pro、Max）預設可能用於訓練，但可以在帳號設定裡關閉。公司專案務必用 Team 以上方案，這是底線，不是建議。這個區別很多人搞混，以為「我用了 Claude Code 就等於把程式碼交出去」，其實關鍵在訂閱方案，不在工具。
| 方案類型 | 程式碼用於訓練 | 資料保留期 | SOC 2 / 合規 | 資料落地 |
|---|---|---|---|---|
| Free / Pro / Max（消費者） | 預設可能，可手動關 | 較長 | 無企業級認證 | 無區域選擇 |
| Team（商業） | 不用於訓練 | 較短 | 有合規措施 | 有區域選擇 |
| Enterprise / API | 不用於訓練 | 可協商控制 | SOC 2、進階合規 | 可選區域落地 |
用 Pro 帳號跑公司程式碼是常見的合規地雷。即使你手動把訓練選項關掉，稽核軌跡與責任歸屬仍然不清，出事時你無法證明「那段程式碼沒被用於訓練」，法務通常直接打回票。Team 方案的實務優勢不只是不用於訓練，還有集中帳號管理、管理員可強制統一設定、完整的審計 log，這三項才是決策者真正在意的，因為它們讓「出了事能追、能究責」這件事成立。這跟做 AEO 策略 時強調的可追溯性是同一個治理直覺：可追溯比絕對安全更務實，因為你永遠需要能在事後還原發生了什麼。
資料政策會變，這份對照寫的是查證當下的狀態（2026 年中）。正式導入前，請務必直接讀 Anthropic 官方的隱私頁與企業方案條款，確認最新政策，不要只依賴第三方文章。費用的部分我們在 Claude Code 定價相關內容有整理，這篇只談資料政策與權限，避免焦點分散。要判斷哪種方案適合你的團隊規模與合規需求，建議把「是否受法規約束」「是否有資料落地義務」「是否需要 SSO」三個問題先回答清楚，再對照上表選方案。選對方案之後，接下來的設定才有意義；方案選錯，後面 settings.json 寫得再漂亮也補不回訓練風險那道破口。
公司導入 Claude Code 前的 8 項檢查表：給技術主管與資安覆核
公司要把 Claude Code 放進開發流程，底下這 8 項走完才算到位，少做一項都可能在事故發生時被究責。這份清單是設計來直接交給資安與法務覆核的，每一項都有明確的「為什麼、怎麼做、誰負責」。把它當成導入前的簽核文件，逐項打勾，比口頭說「我們有設安全」可靠得多。
- 方案選 Team 以上。商業方案程式碼不用於訓練、有審計 log，是合規底線。負責人：法務與採購。
- 寫 enterprise settings.json 強制 deny。把
rm -rf、git push --force、外傳類指令放在 enterprise 層，員工無法覆蓋。負責人：資安。 - 裝 PreToolUse hook 擋機密檔案。用上一篇的可複製範本，擋
.env、憑證、key、lock 檔。負責人：技術。 - 機密檔案分級。把
.env、憑證、客戶資料、production 設定分類，對應不同的 deny 規則與目錄隔離。負責人：資安與技術。 - 強制 PR review 與測試。PR review 與自動化測試是 Agent Loop 回饋訊號的來源，沒有這兩項 AI 等於盲飛，改錯也沒人接。負責人：技術主管。
- 限制可存取目錄。用
additionalDirectories把 AI 關在專案目錄，禁止跨專案讀取。負責人：技術。 - 記錄與保存審計 log。Team 方案提供審計功能，定期備份與檢視誰在何時做了什麼動作。負責人：資安。
- 定期複檢資料政策與 hook 規則。政策與工具版本都會變，每季複檢一次 enterprise 設定與 hook 命令。負責人：資安與法務。
除了這 8 項，建議再加一項「事故演練」:在導入後挑一個低風險時段，故意觸發一次 PreToolUse hook 的阻擋、故意讓 deny 規則擋下一個指令，確認護欄真的會動、終端機訊息看得懂、負責人知道怎麼處理。很多團隊設了護欄卻從沒驗證過它有效，等到真正出事才發現 hook 命令有 bug、或 enterprise 規則根本沒生效，那就來不及了。演練一次的成本很低，但它能在事故發生前替你抓出設定漏洞，價值遠高於那一小時的投入。
enterprise settings.json 是公司層強制力的關鍵。它寫在企業管理後台，員工無法自己改掉，這是它跟 project、local 兩層最大的差別，也是為什麼安全規則要盡量上推到 enterprise 層。導入後第一週，建議照這份觀察清單追蹤：實際用量有多少、有沒有發生改錯檔案、PR review 退回率多高、PreToolUse hook 觸發幾次。這些數字會告訴你護欄有沒有真的發揮作用，而不是只看「有沒有出大事」這種落後指標。團隊導入的完整評估流程，我們在 Claude Code 教學 裡有更廣角的說明，這篇專注在安全與權限。
這份檢查表的概念，其實跟網站營運的標準作業很像。做 On-Page SEO 或 網站程式碼優化 時，你也會有一份上線前檢查清單：標題、meta、連結、效能、可及性逐項過。AI 工具導入也是同樣的道理，差別只在檢查項目換成權限、資料政策、hook、審計。把清單制度化，是讓安全從「靠個人記得」變成「靠流程把關」的唯一方法，這也是 標題標籤結構 之所以要規範清楚的原因：可重複、可檢核的流程，才有辦法規模化又不失誤。
進階護欄：用 Hooks 把 AI 行為上鎖，與 MCP 的權限邊界
Hooks 是 Claude Code 最強的安全護欄，能在工具執行前後自動觸發腳本，做到規則做不到的動態判斷。三大類 hook 各有觸發時機：PreToolUse 在工具執行前觸發，可以阻擋；PostToolUse 在工具執行後觸發，可以做後處理；Notification 在事件通知時觸發，例如 idle 或需要確認時提醒你。這個倉庫的 settings.json 就用了一個 Notification hook，在需要你注意時播放系統音提示，避免你切去別的視窗時錯過批准請求，這種小細節在長時間協作時能避免很多「為什麼它卡住不動」的誤會。
幾個實戰 hook 範本可以直接抄。commit 前自動跑 lint：用 PostToolUse 搭配 matcher: "Bash"，偵測到 git commit 就先跑 linter，失敗就退回。改檔前自動備份：用 PreToolUse 搭配 matcher: "Edit|Write"，在改檔前把原檔複製到 .backup 目錄，出錯能還原。idle 時通知：用 Notification hook 在等待你回應時推系統通知。這些都是規則做不到、只有 hook 能辦到的動態行為，把 hook 想成「可程式化的護欄」最貼切。
MCP 則是另一個權限邊界。每接一個 MCP server 等於幫 Claude Code 開一條對外通道，所以每一個都要單獨審查它能讀寫什麼。接資料庫的 MCP 要限唯讀帳號，接外部 API 的 MCP 要限網域與速率，接檔案系統的 MCP 要限目錄範圍。MCP 的本機整合設定，Claude Desktop 介紹 裡有完整的 MCP 設定指南，這裡只講它在 Claude Code 裡的權限控管原則。hook 與 allow/deny 規則的分工很清楚：規則管靜態黑白名單、hook 管動態條件判斷，兩者互補不重複。
實務上接 MCP server 有一個排序原則：先接唯讀、再接有限寫入、最終才考慮完整權限。例如接一個查氣象的 MCP，它只讀公開 API，風險極低，先接無妨；接一個讀資料庫的 MCP，先給唯讀帳號跑一陣子，確認它不會亂跑寫入指令，再逐步放寬；接一個能改檔案系統或發 Email 的 MCP，務必限縮目錄與收件者白名單，並搭配 PostToolUse hook 在每次動作後記 log。這個「由唯讀到寫入、由窄到寬」的漸進原則，跟前面講 allow 規則要從最窄開始放是同一個道理：權限給出去容易、收回來難，所以寧可一開始保守，也不要一次給足再來善後。
一個提醒：hook 腳本本身就是程式碼，要跟其他程式碼一樣 review，不能因為它是「安全護欄」就放它引入新的風險。一個寫得不好的 hook 可能洩漏檔案路徑、或在錯誤時放行不該放行的東西。跟 技術 SEO 裡講的「監控程式碼也要被監控」是同一個道理，護欄本身也要有護欄。建議把 hook 命令也納入 code review 流程，並在 CI 跑一次 hook 的測試案例，確保它該擋的有擋、該放的有放。這也跟 常被忽略的技術 SEO 錯誤 裡提到的「自動化也要被驗證」呼應：任何自動化的東西，包含安全護欄，都要有它自己的驗證機制，否則它失效了你也不會知道。
常見誤區與真實事故：Plan Mode 不是保險，Bypass 不是效率
兩個最常見的誤區，直接點破。第一個是以為開了 Plan Mode 就絕對安全，但 Plan 只讀不跑，它說「這樣改沒問題」不代表實際跑起來沒問題，邏輯正確性仍然要實測。第二個是以為開 Bypass 比較快，但 Bypass 在本機等於把鑰匙交出去，無審查全自動執行，一次走錯目錄的 rm -rf 就夠你痛一整週。把 Plan Mode 當保險、把 Bypass 當效率，這兩個直覺都會害你。
第三個誤區是 allow 規則寫太寬，尤其是 Bash(*) 這種全開寫法，等於沒設規則。正確做法是逐指令窄授權，只放行你確定安全的固定指令如 npm test、git status，其餘都走 ask 讓自己判斷。貪圖方便的全開規則，是事故的最大溫床，因為它把「你有機會攔截」這道防線整個拆掉。很多人以為「反正我有在看」，但問題是全開之後模型跑指令不再彈窗，你根本沒有那個「看」的機會，等於自廢武功。
真實事故多半不是 AI 變聰明主動攻擊你，而是你給了太寬的 allow 規則讓它誤刪或誤傳。常見的事故類型有幾種：誤改 lock 檔導致相依性崩潰、誤讀 .env 並透過 curl 外傳、誤跑 production 部署指令把壞版推上線。這幾種全部都能用 deny 規則加 PreToolUse hook 預防，前提是你事先把規則寫好，而不是出事才補。事前一小時的設定，抵得過事後一整天的救火，這筆帳怎麼算都划算。
給一個本倉庫的真實防護案例。這個 codex 倉庫的 PreToolUse hook，實際擋下過幾次我（作者 Sliven）對 lock 檔的誤改。當時 Claude Code 想在一次重構裡改動 lock 檔，hook 命中 lock.json 模式直接 exit 1 阻擋，終端機印出明確訊息，我才意識到那個改動會牽連整個相依樹，及時收手。這就是 hook 比規則更可靠的活生生例子，它在我動手前就把風險攔下。這種「先盤點、再動手」的紀律，跟 On-Page SEO 裡強調「先審查再發布」的流程邏輯是相通的，方向對了再下手，比事後補救省太多成本。
把 Plan Mode 與 Accept Edits 串成一個固定節奏，是進階使用者常見的高效工作流。流程是這樣：開新任務先進 Plan Mode 讓模型把計畫寫出來，你讀完確認方向、把計畫重點記下來，然後切到 Accept Edits 讓它動手改，改的過程你盯著 diff，遇到跑指令的關卡它會停下來問你。這個「Plan 規劃、Accept Edits 執行、Default 收尾高風險動作」的三段式節奏，兼顧了判斷品質、執行速度與安全底線。很多團隊把這個節奏寫進內部的 AI 協作規範，讓每個人都有一致的節奏，避免有人全程 Default 慢到爆、有人全程 Bypass 危險到爆這種兩極狀況。
內部連結的建立也是同樣道理，做 內部連結 或 內部連結優化策略 時也是先規劃連結架構、確認目標頁存在，再下手錨點，避免出現斷鏈，就跟 Claude Code 改程式碼前先 Plan、用 hook 先擋是同一套工程紀律。想看更多 AI 工具與 SEO 交會的趨勢，可以參考 SEO 趨勢與 AI 搜尋、Google AI 搜尋 SEO 指南，以及 AI SEO 與 AISO 策略，理解大環境為什麼 agentic coding 的安全設定越來越關鍵：當 AI 開始自動產內容、自動改網站，權限控管就是整條產線的保險絲。這也回扣到 SEO 與 如何提升 SEO 的核心：可持續的成長來自可控、可追溯的流程，而不是一次性衝高再翻車。
設定做完後，把規範寫進 CLAUDE.md（〈CLAUDE.md 完整教學與範本〉）讓 AI 長期遵守，再評估方案成本（〈Claude Code 費用與方案選擇〉）決定 Team 或 Pro。
常見問題（FAQ）
Claude Code Plan Mode 什麼時候用？
Plan Mode 適合碰陌生 repo、跨多檔重構、或要下高風險指令（刪檔、部署、改 migration）之前，讓 AI 先只讀檔案提出計畫，你確認方向對了再切回 Default 或 Accept Edits 執行。日常小修改不必每次都進 Plan，那是過度流程。Plan 只讀不驗證，所以它說「沒問題」不代表真的沒問題，實際執行後仍要跑測試確認。
Claude Code Bypass Permissions 危險嗎？
Bypass 讓所有動作全自動不問你，只該用在 CI/CD 或隔離容器。在本機常駐 Bypass 等於把檔案系統與終端機的完整控制權交出去，一次誤刪或誤部署就無法挽回。如果你追求的是效率，Accept Edits 模式改檔自動、指令仍要你點頭，才是兼顧速度與安全的正解，Bypass 不是效率是賭博。
settings.json 要放哪一層？
三層各有用途。enterprise（公司管理員設）優先級最高、員工不能改；project 的 .claude/settings.json 進 git 給全團隊共用；settings.local.json 放個人路徑與偏好、不進 git。公司導入主要靠 enterprise 層強制安全規則，project 層放團隊共用的 allow/deny，local 層只放不影響安全的個人偏好。想確認目前生效的規則，用 /permissions 指令查。
Claude Code Pro 帳號可以跑公司程式碼嗎？
不建議。Pro 是消費者方案，程式碼預設可能用於模型訓練，即使你手動關閉訓練選項，稽核軌跡與責任歸屬也不清，法務通常不接受。公司專案務必用 Team 以上方案，商業方案明確不用於訓練、有審計 log、有合規措施，這三項缺一不可。省那點訂閱費，換來的是無法究責的合規風險，不划算。
怎麼讓 Claude Code 永遠讀不到 .env 與憑證？
兩層防護最可靠。第一層在 settings.json 的 permissions.deny 加入 Read(.env)、Read(**/*.pem)、Read(**/credentials*.json) 等規則。第二層搭配 PreToolUse hook，在每次 Edit/Write 前用 grep 檢查檔名，命中就 exit 1 阻擋。deny 規則管靜態讀取、hook 管動態寫入，雙保險才能真正做到「永遠讀不到」。本篇中段的範本可以直接複製來用。
Claude Code Team 跟 Enterprise 差在哪？
Team 適合小團隊，有集中管理與審計 log、程式碼不用於訓練，是公司導入的入門門檻。Enterprise 再加上 SSO 單一登入、進階合規認證（如 SOC 2）、資料落地區域選擇與更長保留期控制，適合有法規要求或跨國營運的組織。規模小、沒有特殊法規需求，Team 就夠；要過 ISO 或有資料落地義務，就得上 Enterprise。
指令被 Claude Code 擋下來怎麼排查？
分三步。先用 /permissions 查目前生效的 allow/deny/ask 規則，確認是不是被 deny 或 enterprise 層擋。若是 hook 擋的，終端機的 BLOCK 訊息會寫明命中哪條規則或哪個檔名模式。確認安全、確認不是誤擋後，再決定是加 allow 規則、還是調整 hook 命令。切記不要為了「讓它能跑」就把 deny 改成全開，那等於拆掉護欄。
結論：把權限設對，Claude Code 就是可靠的自動化夥伴
回頭看整篇，Claude Code 安不安全這件事，答案從頭到尾都是同一句：取決於你開的權限，而不是工具本身。預設 Default 模式每步都問你，這個狀態比你想的安全；Accept Edits 是兼顧速度與安全的甜蜜點；Plan Mode 讓你先看計畫再動手；Bypass 只該留在 CI 容器裡。settings.json 的 deny 永遠優先、allow 次之、ask 最末，把高危指令放 deny 是第一條守則。三層設定裡，enterprise 層是公司強制力的來源，機敏規則盡量上推到那裡。
可複製的 PreToolUse hook 範本是這篇的核心交付，它直接取自這個 codex 倉庫的生產設定，實際擋下過對 lock 檔與機密檔案的誤改。你拿去改成自己專案的檔名模式就能用，不必從頭研究。公司導入前把那 8 項檢查表走完，方案選 Team 以上、enterprise settings.json 強制 deny、裝 hook、強制 PR review，這幾項到位，Claude Code 就能放進開發流程而不變成資安破口。
想更全面理解 Claude Code 的能力版圖，從安裝、常用指令到模型選擇的總覽，回到 pillar Claude Code 完整教學。要把安全設定落地，從這篇的 settings.json 範本開始改，是最快的路。設定一次到位，之後就是享受 agentic coding 帶來的產能紅利，而不必每天擔心 AI 改錯檔案。安全設定跟 SEO 一樣，不是設一次就永久有效，工具版本會變、政策會變、團隊會擴大，定期複檢 enterprise 設定與 hook 規則，才是讓護欄持續有效的關鍵紀律。把權限設對，Claude Code 就是那個會幫你把繁瑣工作做掉、又不會偷偷捅你一刀的可靠夥伴。
