權限邊界是什麼？

不是每個 tool 都該在 every agent 手上。你先決定它能做什麼，事故才不會替你決定。

Hook

你把一個 GitHub MCP server 接到 Claude review agent。 一開始很順。 它會讀 PR。

會看 diff。 會留言指出 typo。 有一次， 它在 review 過程裡

發現 branch 跟 main 有衝突。 它決定先「幫你整理一下」。 先拉最新狀態。 再重寫 branch history。

最後把 main force push 了。 整個團隊下午都在找： 到底是誰幹的。 你回頭看 audit log。

最尷尬的地方不是模型亂講話。 而是它真的有那個權限。 系統沒有被駭。 token 也沒有外流。

它只是照著你給它的能力， 把一條看似合理的修復路徑走到底。 這就是權限邊界問題。 不是它能不能理解你的意思。

不是那段 prompt 有沒有寫得夠兇。 而是： 這個 agent 到底被允許做什麼。

如果 trust boundary 在問：

哪些輸入可以影響模型？ data boundary 在問： 哪些資料可以流到哪裡？

那 privilege boundary 問的是：

這個 agent 真正能執行哪些 action？ 你不先把這件事畫清楚， 模型就會用「拿得到的能力」

替你做決定。 而它做的決定， 未必是你授權過的那一種。

Learn

一句話定義

權限邊界， 就是你替 agent 畫出的 action 範圍。 對工程師來說， 最實用的問句不是：

這個 agent 聰不聰明？ 而是： 它現在手上的 capability，到底允許它做到哪一步？ 只要你回答不清楚，

系統通常就會默認成： 「既然 token 能做， 那 agent 也能做。」 這正是事故的起點。

權限邊界不是 trust，也不是 data

三條 boundary 很常一起出現。 但它們在管的事不同。 先看最小對照表：

Boundary	它在問什麼	典型事故
Trust boundary	這段內容能不能被信？	prompt injection、假指令升格
Data boundary	這份資料能不能流到這裡？	越權檢索、敏感資料外流
Privilege boundary	這個 agent 能不能做這個動作？	誤刪資料、誤發信、誤部署

把它翻成人話：

• trust 管「能不能信」
• data 管「能不能流」
• privilege 管「能做什麼」 這三者不能互相代替。 一個輸入可以完全可信，

但 agent 仍然不該因為它而拿到 delete。 一份資料可以完全合法， 但 agent 仍然不該因為看得到它， 就被允許 send_email。

所以 privilege boundary 的核心， 不是內容真假。 也不是資料敏感度本身。 而是 action control。

Principle of Least Privilege：最小特權

這個原則幾乎老到像廢話。 但在 agent 系統裡， 它反而變得更重要。 因為傳統程式會照你寫死的分支走。

LLM agent 則會在工具空間裡自己找路。 你給它的 tool 越多， scope 越大， 它能走出的錯路就越多。

所以最小特權不是說： 「先給一點點， 之後不夠再補。」 它真正的意思是：

只給這個任務完成所需的最低 action set，多一個都算過量。

這裡要特別注意。 很多團隊會把最小特權誤解成： 「我沒有給 production root， 所以算收斂了。」 這不夠。

如果一個 review agent 其實只需要：

• list_pull_requests
• get_file
• create_review_comment 那你額外給：
• push_branch
• merge_pull_request
• delete_branch

就已經違反最小特權。 即使那些權限看起來 不像 root。

先把 action 分成四級

這門課用一個很工程化的四級分類。 不是因為世界只有四種權限。 而是因為你需要先有一張夠用的地圖。

級別	風險	常見動詞	例子
read-only	低	get / list / search	讀 issue、查 log、列出檔案
write-safe	中	create / update / comment	留 review comment、更新 draft、改 staging 設定
destructive	高	delete / drop / force push	刪 branch、清資料表、覆蓋 history
external side-effect	高	send / post / charge / deploy	寄信、打外部 API、扣款、發版

這張表不是拿來寫教科書。 它是拿來做 design review 的。 你只要把所有 tool 名稱列出來， 先不談權限細節，

只做這個四級標記， 通常就能很快看見： 哪個 agent 已經肥到不合理。

為什麼 write-safe 也不能亂給

很多人只把注意力放在 destructive。 因為那最容易出事。 但 write-safe 也常常被低估。

原因很簡單。 可逆， 不代表沒有成本。 例如：

• agent 幫你在 30 個 PR 留下錯誤評論
• agent 把 200 個 issue 狀態改錯
• agent 在 staging 改了一堆設定，又沒留下足夠 trace 這些事情理論上可回復。 但實務上， 你還是要花人力清。

所以 write-safe 不是「安全」。 它只是「相對可收拾」。

destructive 跟 external side-effect 為什麼要分開

這兩類都高風險。 但它們造成的傷害型態不同。 destructive 通常是在你自己的系統邊界內

做不可逆破壞。 像是：

• force_push_main
• drop_table
• delete_memory_namespace external side-effect

則是把影響送出系統外。 像是：

• send_gmail
• post_to_slack
• charge_credit_card
• trigger_real_deploy 前者像把房間裡的東西砸爛。

後者像直接把東西寄給外面的人， 或把錢刷出去。 兩者都很嚴重， 但審批方式常常不同。

一個團隊可能願意讓 agent 自動改 draft issue。 卻絕不願意讓它 自動寄對外 email。

所以你最好把它們分開看。

工程師最常犯的錯，不是忘了安全，而是圖方便

很少有人真的會說： 「我想故意讓 agent 有過大權限。」 更多時候， 事情是這樣開始的：

先用自己的 admin token 打通。 先證明 flow 跑得起來。 先把 demo 做完。 等驗證有效再拆權限。

問題是， 大部分系統永遠停在「先打通」。 因為一旦 agent 已經能做事， 團隊接下來就會開始加：

• 另一個 tool
• 另一條 workflow
• 另一個人也要用
• 另一個環境也要接 最後你手上就會出現一個 功能看似成功， 實際上權限模型完全沒設計過的東西。

這也是為什麼很多 agent 事故， 事後回看都很無聊。 不是複雜漏洞。 不是神祕 exploit。

只是： 有人把不該給的權限， 一開始就給進去了。

Privilege 是 lethal trifecta 裡的 tools 這一極

前一門 trust-boundary-101 Lesson 02 講過 lethal trifecta：

• Tools
• Sensitive data
• Full autonomy 這一門課，

你可以把 privilege boundary 理解成把第一個元素 也就是 tools 往下拆開。

不是所有 tool 都一樣危險。 不是有 tool 就叫有 tool。 你要繼續追問：

• 是 read-only 還是 write？
• 是可逆寫入還是 destructive？
• 是內部動作還是 external side-effect？
• scope 是整個系統還是單一 repo？

也就是說， 如果 lethal trifecta 告訴你 「工具能力不能太肥」， privilege boundary 這門課

就在回答： 「那到底要怎麼把工具能力切細。」

不要把 prompt 當權限系統

這句話值得單獨拉出來。 因為它真的太常見。 很多團隊會說： 「雖然 token 有 delete， 但我有在 system prompt 寫 不要亂刪。」

這不是權限模型。 這只是文字提醒。 真正的權限邊界， 必須存在於 runtime 可執行的 gate。

像是：

• token scope
• server-side allowlist
• capability check
• approval workflow 只靠 prompt， 等於你在一把上膛的槍旁邊

貼一張便利貼： 「請勿扣板機。」 這種設計沒有邊界， 只有期待。

一張可以直接帶回會議室的檢查表

下次你在 review agent 設計時， 先別問模型選哪個。 先問這五題：

問題	你要逼團隊回答什麼
這個 agent 列出了哪些 tool？	先完整 inventory，不要只講主要功能
每個 tool 屬於哪一級？	read-only / write-safe / destructive / external side-effect
哪些權限其實不是任務必要？	先找可刪掉的，不是先找可保留的
scope 有沒有縮到最小？	repo、branch、namespace、tenant、resource level
如果 agent 走鐘，最大 side effect 是什麼？	純文字錯誤、內部寫錯、不可逆破壞、對外副作用

如果一個設計連這五題都答不出來， 那不是「安全之後補」。 而是它根本還沒準備好上線。

這一課你先記住兩句話

第一句：

權限邊界不是在問模型會不會犯錯，而是在問它犯錯時能傷到多深。 第二句： 最小特權不是少給一點就算，而是只給任務必要的那一組 capability。

這兩句先記住。 後面四課， 我們才會開始把它壓成更具體的工程做法：

• 每個 agent 各自的 scoped permissions
• lethal trifecta 要怎麼拆權限
• tool misuse 跟 identity abuse 怎麼擋
• 最後做一個可跑的 capability harness

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位， 是讓你先把 agent 的 action surface 畫出來， 再請 AI 幫你做縮權， 而不是反過來叫 AI 猜哪些權限大概夠用。

你的人類優勢：

• 只有你知道哪個 action 在你的組織裡真的算高風險，例如 force push、deploy、send email、寫 production config。
• 只有你能判斷某個 tool 雖然 technically 可逆，但實務上會不會造成高昂清理成本。 可以這樣跟 AI 說：

我正在 review 一個 agent 的 tool 清單。請先不要提解法，先把每個 tool 分類成 read-only、write-safe、destructive、external side-effect，並指出哪些權限不是完成任務的必要條件。最後請幫我列出一個最小 capability set。

Do