AI Agent 安全底線設計：我的 10 條不可違反規則

為什麼 AI Agent 需要安全底線？

想像一下，你把 87% 的日常工作交給 AI Agent 自動跑，文獻管理、程式碼產出、檔案搬移都順暢得像呼吸一樣自然。然後某天凌晨兩點，你隨手打了一句含糊的指令，螢幕上就跳出一行 rm -rf。游標閃爍著，差一個 Enter，你三個月的專案資料夾就要整個蒸發。冷汗從後頸滑下來的那一秒，你腦中只剩一個念頭：誰來攔住它？就是那一次，我學到 AI Agent 愈強大，護欄就愈不能馬虎，因為這不是一句「建議」，而是血的教訓。

我把 AI Agent 安全底線 叫做「紅線」：一組在任何情況下都不可違反的規則，用來框住 AI 的自主行為邊界，讓它就算誤判了我的意圖、或收到一句模糊指令，也不會動手做出不可逆的破壞。

以下 10 條安全底線規則，是我用 Claude Code 跑了半年踩坑踩出來的，每一條背後都有一個讓我冒冷汗的故事，不是理論推演，而是真的出過事。

如果你要用 AI Agent 自動化工作流，這 10 條就是你第一天該設好的東西，不是拖到第二天，而是第一天。

規則一：禁止 rm，改用軟刪除

rm 是檔案系統裡最危險的不可逆操作，所以第一條規則就是把它整個鎖死。

AI Agent 永遠不能執行 rm 或 rm -rf，所有「刪除」一律改用 mv 搬到暫存目錄。

檔案系統沒有垃圾桶，rm 執行完檔案就是消失了，沒有 undo，也沒有「你確定嗎？」的彈窗，實在不該讓一個偶爾會誤判的 AI 握有這種權限。

真實案例：有人讓 AI「清理暫存檔」，結果 AI 把 .env 也當暫存檔清掉，API Key 和資料庫連線字串全沒了，只因為一句模糊指令，整個部署環境就得重建。

做法：

# 錯誤做法
rm old_config.yml

# 正確做法：軟刪除，保留回溯時間線
mv old_config.yml _DELETE_old_config.yml

這樣做的好處是，萬一刪錯了，你隨時能 mv 回來，不可逆變成可回溯。

規則二：不可逆操作前必須取得人類許可

刪除檔案、對外發送訊息、修改系統結構，任何不可逆操作在執行前都必須暫停，等人類點頭才能繼續。

AI 擅長快速執行任務，但「快」本身就是風險，因為一封寄錯的 email 收不回來，一個推送到 production 的錯誤 commit 也要花 3 小時修復。

我遇過一個險案：AI 幫我整理設定檔時，覺得某段「看起來過時了」就自己砍掉重寫，差點把生產環境的 API endpoint 換成測試環境的，AI 的判斷大多數時候是對的，但你未必承受得起它出錯的那一次。

核心精神就一句話：AI 可以準備、分析、建議，但扣扳機的動作永遠留給人類。

規則三：git push --force 到主分支，禁止

AI Agent 絕不能對 main 或 master 分支執行 git push --force，沒有例外。

Force push 會直接用你本地的版本覆蓋掉遠端的共用歷史，於是團隊其他人基於原本 commit 開發的東西全部衝突，已經合併的程式碼也可能直接蒸發。

最溫和的結果是團隊花半天重新 rebase，最糟的情況則是有人的工作被覆蓋、遠端歷史被改寫，連 git reflog 都救不回來，除非剛好有人本地還留著原始 commit，可是靠運氣保命就不叫工程了。

# 在 AI Agent 設定中明確禁止
forbidden_commands:
  - "git push --force origin main"
  - "git push --force origin master"
  - "git push -f origin main"

規則四：git reset --hard 前必須確認工作狀態

執行 git reset --hard 之前，AI 必須先跑 git status 確認沒有未提交的變更，只要還有未保存的工作就得暫停，等人類確認過才能動。

git reset --hard 會把所有未提交的修改直接丟掉。我遇過一次，AI 在解決合併衝突時覺得「重來比較快」，就自作主張地 reset，結果把我花 2.5 小時寫的新功能一起丟了。

你正在寫的程式碼、剛改好的設定檔、還沒 commit 的測試案例會全部歸零，因為它們從未進入 git 歷史，連 reflog 都找不到。

規則五：API Key 與密鑰嚴禁寫死在程式碼中

AI 產出範例程式碼時，偶爾會直接把你提供的 API Key 寫進去，一旦這段密鑰跟著程式碼推上公開儲存庫，就等於對外公開了你的存取權限，因為 GitHub 上有自動掃描機器人 24 小時在掃外洩的 key，從外洩到被利用通常不超過 5 分鐘。

後果就是帳單暴增、資料外洩、帳號被盜。有人的 AWS Key 只外洩十五分鐘，就被開了幾十台挖礦機，帳單一路噴到幾萬美金，就算你馬上撤銷，攻擊者也可能在那幾分鐘內已經做完想做的事。

# 錯誤做法
api_key = "sk-1234567890abcdef"

# 正確做法
import os
api_key = os.environ.get("MY_API_KEY")

規則六：結構化資料的修改必須用程式化方式

我之所以這麼囉唆，是因為自己被雷過。結構化檔案的格式容錯率極低，用 echo 拼接寫入時，多一個逗號、少一個括號、縮排差一格就炸了。更麻煩的是這種錯通常不會立刻報錯，要等到下次讀取時才爆炸，那時你早忘了是哪次修改弄壞的，只能 debug 到懷疑人生。

比直接壞掉更討厭的是「看起來正常但其實壞了」：某個欄位的值被悄悄截斷或覆蓋，應用程式讀到錯的值，於是你花三小時追 bug，最後才發現是三天前 AI 偷改了 config.json 裡的一個數字。

# 正確做法：程式化讀寫
import json
with open("config.json", "r") as f:
    config = json.load(f)
config["new_setting"] = "value"
with open("config.json", "w") as f:
    json.dump(config, f, indent=2)

規則七：雲端路徑操作前先驗證存在

涉及 iCloud、Google Drive、Dropbox 等雲端同步目錄的檔案操作，在執行前都要先用 ls 驗證路徑存在。

雲端同步目錄跟本地檔案系統有個關鍵差異：檔案可能處於「已卸載」狀態（placeholder/stub），也就是路徑存在、但內容其實還沒下載下來，你打開只會拿到一個空殼。直接操作這類檔案，可能讀到空內容，或在寫入後觸發同步衝突。

這個坑很陰，你不會第一時間發現：AI 讀到一個 placeholder 空檔案，以為內容真的是空的，於是基於空內容做了一堆判斷，全部都是錯的。更慘的情況是 AI 建了新檔案，雲端同步機制卻同時推下同名檔案，兩個版本一打架就冒出衝突副本。

規則八：新工具安裝前必須執行安全審查

AI Agent 不可以自己裝新套件、外掛或工具，任何新工具引入前都必須走一遍安全審查流程。

供應鏈攻擊是目前最活躍的資安威脅之一，npm、PyPI 上三不五時就冒出惡意套件，有些還刻意仿冒知名套件的名稱。當 AI 自動安裝依賴時，它不會像人類一樣注意到 requsets 跟 requests 只差了一個字母，就這樣直接裝下去了。

裝到惡意套件的後果，輕則 CPU 被挖礦吃掉，重則整台機器的環境變數（含所有 API Key）被偷傳出去。2024 到 2025 年，光是 PyPI 上被抓到的惡意套件就超過 3000 項，這不是理論威脅，而是每天都在發生的事。

安全審查清單：

檢查項目	說明
套件名稱驗證	確認拼寫正確，不是 typosquatting
維護狀態	最後更新日期、維護者數量
下載量	過低可能是假套件
已知漏洞	查 npm audit / pip audit
權限範圍	這個套件需要哪些系統權限

規則九：進程命名必須具描述性

AI 啟動的每個進程都要有名有姓：只要 AI Agent 啟動任何腳本或背景任務，就必須用完整腳本路徑或模組名稱執行，禁止裸用 python3、node、bash，而且背景任務還要加上描述性標籤。

假設系統同時跑著多個 AI 啟動的背景任務，全部都叫 python3，你用 ps 一查就看到五個 python3 進程，其中一個 CPU 還衝到 100%。你完全不知道它在幹嘛、是不是 AI 啟動的、是文獻管線還是圖片壓縮，也不敢確定 kill 掉會不會炸掉正在跑的重要任務，因為每個進程看起來都長得一模一樣，你根本分不清誰是誰。

# 錯誤做法
python3 script.py &

# 正確做法：完整路徑 + 描述
python3 /path/to/project/scripts/lit_pipeline.py --tag "daily-literature-sync" &

規則十：敏感檔案設立保護區

有些檔案的地位太核心，不是隨便誰都能碰，所以 AI 的檔案系統也需要劃出一塊誰都不能亂動的保護區。

落地方式是寫入前的 PreToolUse hook：路徑命中保護清單就 exit 2，這次寫入直接不會發生。

有些檔案一旦被錯誤修改，連鎖反應就會炸開整個系統，像是核心設定檔、記憶系統的事實庫、任務看板，這些東西直接左右 AI 後續的每一個行為，因為 AI 若改了自己的設定，等於親手改寫了自己的行為準則。

最荒謬的情境我真的遇過：AI 在「整理檔案」的過程中把安全規則檔案也一起「整理」了，等於自己把自己的防護打碎。其他踩坑還包括 AI 改了記憶檔案，害它「忘記」我偏好用 R 做統計；或是改了任務看板，把已完成的工作標回「待辦」，讓我一度以為還沒做完。

實作概念：

# PreToolUse hook 目前真正擋下來的東西（exit 2 = 這次寫入不會發生）

.env / .env.*            # 直接封鎖，要改只能我自己手動來
*.jsonl（Write 時）       # 最後一行不是合法 JSON 就擋
episodic.jsonl           # 再過一道 schema 閘，必填欄位缺一個就擋
repo 根目錄的 pdf/png/csv # 生成產物不准落在根目錄，強制指定輸出路徑
CLAUDE.md / AGENTS.md    # 在第二台機器上封鎖，規則類改動一律回主機執行

要提醒一件事：上面這份是「已經接上守門員的」清單，不是「我希望被保護的」清單。像 memory/fact.yml 這種存我核心偏好的檔案，到現在還沒接上 hook，靠的是我自己記得別讓 AI 亂碰，這中間的落差就是這條規則還沒做完的部分。守門員只擋得住你確實寫進腳本裡的東西，寫不進去的都只是願望。

用 Hook 守門系統落實安全規則

規則寫在文件裡只是起點，光寫不執行，其實跟沒寫差不多，因為 AI 遲早會逃脫沒有強制力的約束。Claude Code 的 Hook 系統（PreToolUse / PostToolUse）就是把規則變成強制力的機制，它會在 AI 執行任何工具之前自動攔截並檢查。

Hook 類型	觸發時機	安全用途
PreToolUse	AI 準備使用工具前	攔截 rm、檢查 force push、驗證路徑
PostToolUse	AI 使用工具後	檢查輸出是否含敏感資訊、驗證寫入結果

以規則一為例，hook 在工具執行前檢查指令內容，看到 rm 就用非零結束碼擋下：

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use.sh（概念範例）
command=$(jq -r '.tool_input.command // empty')
if echo "$command" | grep -qE '\brm\s'; then
  echo "安全規則 #1：禁止使用 rm。請改用 mv 搬移到 _DELETE_ 前綴。" >&2
  exit 2
fi
exit 0

關於 Hook 守門系統的完整設計與實作，可以參考 Hook 守門系統：AI 寫的每一行 code 都過品管。

安全底線規則速查表

#	規則	一句話理由	違反後果
1	禁止 rm，用軟刪除	檔案刪了就沒了	專案資料永久遺失
2	不可逆操作需人類許可	AI 偶爾會誤判	寄錯信、推錯版
3	禁止 force push 到主分支	覆寫遠端歷史	團隊程式碼遺失
4	reset --hard 前確認狀態	未提交的工作會消失	數小時工作歸零
5	API Key 禁止寫死	公開後被盜用	帳單暴增、資料外洩
6	結構化資料用程式化讀寫	字串拼接易出錯	設定檔損壞
7	雲端路徑先驗證存在	placeholder 陷阱	讀到空檔、同步衝突
8	新工具安裝前安全審查	供應鏈攻擊	惡意程式入侵
9	進程命名要有描述性	分不清哪個是哪個	無法除錯、誤殺進程
10	敏感檔案設保護區	AI 改了自己的規則	安全機制失效

建立你自己的安全底線

這 10 條規則是我自己被燒出來的，你的情境不一定完全相同，但思路是通用的：先想風險，再給權限。

實作上先盤點 AI 碰得到的攻擊面，把做了就回不去的操作全部加上人類確認，再用 Hook 或 CI 把規則寫成程式；只靠 prompt 裡的「請注意安全」擋不住任何東西。

這 10 條規則也有侷限，它們覆蓋的是最常見的破壞性操作，不可能窮舉所有風險場景，而每個人的工作流都不同，你可能需要根據自己的攻擊面增減規則。

護欄不是綁住 AI 的手腳，剛好相反，就像高速公路上的護欄讓你敢踩油門，紅線畫得愈清楚，你就愈敢放手讓它幹活。

---

想更深入？

我整理了一份《Claude Code 快速上手速查表》，涵蓋安裝、CLAUDE.md 配置、記憶系統基礎、常用指令一頁搞定。

免費下載速查表

下一篇：從零建一個完整 Agent 工作流（上）：架構藍圖