Lethal Trifecta 重訪：拆權限的藝術

安全不是背三要素，而是學會在真系統裡砍掉其中一個。

Hook

你做了一個 auto-reply email agent。 它可以讀 Gmail。 可以整理 thread。 可以判斷是不是需要回覆。

也可以直接發信。 你覺得這很合理。 因為如果只能讀不能回， 自動化價值會打折。

為了讓它真的省時間， 你把 human gate 拿掉了。 新信一進來， 它就自動分析、 自動草擬、 自動送出。

一週後， 你收到一封轉寄。 agent 把一段本來只存在於內部 escalations thread 的內容， 寄給了一個外部陌生收件人。

你第一時間可能想問： 是誰 prompt 它的？ 是 Gmail API 有 bug 嗎？ 還是模型又 hallucinate 了？

但這個場景真正的答案更無聊。 它同時具備了三件事：

• 讀敏感資料
• 執行真實 action
• 完全自動 也就是 lethal trifecta。

這個概念在 trust-boundary-101 Lesson 02 已經介紹過。

所以這一課不重講定義。 這一課要講的是： 當你已經看到 trifecta， 到底該拆哪一面，

又該怎麼拆。

Learn

先快速複習，但只複習必要的

lethal trifecta 的三要素是：

• Tools
• Sensitive data
• Full autonomy 三者同時在場時， 風險不是加法。

比較接近乘法。 因為 agent 不只知道事實。 也不只拿得到工具。 它還能不經人類確認就把決策送進真實世界。

這一課的重點， 不是再把這三句背一遍。 而是要建立另一個反射：

看到 trifecta，不要問怎麼把 prompt 寫得更嚴；先問我要砍哪一個面向。

三選二，風險會差很多

很多場景做不到完全無風險。 你未必能把所有敏感資料都移走。 也未必能把所有 write tool 全拿掉。 但只要你能把三要素裡的任一項拆掉，

風險通常就會降一大截。 因為 agent 不再同時具備：

• 看見敏感內容
• 做出高影響動作
• 不經任何 gate 自動執行 所以實務上，

你設計的重點不是追求完美純淨。 而是判斷： 哪一項最適合先砍。

先砍哪一項，不是抽象哲學，而是成本問題

工程現場裡， 最常見也最務實的問法是：

我現在只能先動一刀，砍哪裡最便宜、最有效？ 答案通常不是固定的。

但大多數情況下， 你會先評估這三條路：

要拆的面向	常見做法	成本	典型效果
autonomy	human approval、dry-run、time-delay	低	立刻把最危險的自動 side effect 拿掉
data	tag / namespace / purpose-scoped token	中	讓 agent 看不到最敏感那層內容
tools	改成 propose-only、read-only、draft-only	高	從根本移除高風險 action
這張表不是法律。

但它非常好用。 因為它提醒你： 拆 trifecta 常常是一個成本排序問題。

不是純理論對錯。

為什麼最常先砍 autonomy

這通常是最便宜的一刀。 你不一定要重做資料層。 也不一定要重簽新 token。 很多時候，

你只要把：

• 自動送出
• 自動 merge
• 自動 deploy 改成：
• 先產生 plan
• 先產生 draft
• 先產生 diff
• 等人按 confirm

風險就會立刻降很多。 最常見的 pattern 包括：

• dry-run + confirm
• second-agent approval
• time-delay with cancel window
• human-in-the-loop queue 這些做法的共同點，

不是它們多聰明。 而是它們把最後一步 execution 從模型手上拿回來。

dry-run + confirm 為什麼這麼常見

因為它幾乎是所有團隊都能負擔的最低成本模式。 你先讓 agent 做：

• 分析輸入
• 擬定行動
• 準備參數 但不要立刻送出。

只把 plan 顯示給人看。 人類確認後， 再執行真實 tool。 看起來只是多一步。

實際上， 你已經把 full autonomy 改成 conditional autonomy。 這往往是從危險區退一步的最快方法。

什麼時候該拆 data

如果你的場景最大風險 不是 agent 做 action， 而是它看見不該看的東西， 那你就應該優先拆 data。

典型例子包括：

• knowledge agent 不該看到法務資料夾
• monitoring agent 不該讀 raw user content
• analytics agent 不該摸 restricted namespace 這種時候， 就算你把 autonomy 拿掉，

它還是可能先看到高敏資料， 再把內容抄進 draft、 log、 內部 comment。 所以 data boundary 的縮權方式 會長成：

• per-purpose token
• namespace allowlist
• tag-based retrieval gate
• only-summary-no-raw-content 核心不是讓模型更乖。 而是讓它從頭就看不到那塊東西。

什麼時候該拆 tools

這一刀通常最痛。 因為它最容易直接影響功能感受。 如果你把 agent 從 send_email 改成只會產 draft，

產品體驗一定變慢。 如果你把 customer support agent 從 issue_refund 改成只會 propose refund，

營運團隊一定會覺得效率下降。 但這一刀在某些場景仍然必要。 尤其當外部 side effect 本身代價極高時。

例如：

• 發正式法律通知
• 扣款
• 關停服務
• 對外發布事故公告 這些行為一旦送出， 就不是「晚點補回來」的問題。

此時把 tool 改成 propose-only 往往比拼命加 prompt 更實際。

三種常見 agent，要優先砍哪裡

這裡給你三個很常見的判斷模板。

Agent 類型	最常優先拆哪一面	為什麼
coding agent	autonomy	它需要讀 code、也需要提出改動，但最後 diff 最適合人類 review
customer support / external comms agent	tools	對外送出一旦發生，損害常比內部延遲更大
monitoring / observability agent	data	它要看 metrics，不一定需要看 raw user content
這不是唯一答案。
但它是一個很好的起點。

因為它是從代價與可承受風險出發， 不是從抽象偏好出發。

拆 autonomy 的常見做法

如果你決定先砍 autonomy， 可以先從這三種做法挑一個：

1. human approval gate
2. second-agent approval
3. delayed execution 第一種最直覺。

人看完 plan 才放行。 第二種適合較高頻流程。 例如 planner agent 提議， executor agent 只在 policy 檢查通過時執行。

第三種則是給系統一個反悔窗口。 像「10 分鐘內未取消才真的發出」。 它們的共同點都是： execution 不再是單一模型的一步到位。

拆 data 的常見做法

如果你決定先砍 data， 常見手段有：

• 將資料改成 tag-based retrieval
• 按 tenant / namespace 切 token
• 只提供 redacted summary
• 對不同任務給不同 data view 很多時候，

你不需要完全移除資料。 你只需要把最敏感的那一層 從預設上下文抽掉。 例如 monitoring agent

仍然可以看：

• error count
• latency
• service name 但不必看：
• 完整 user message
• 原始附件內容
• 整段 internal escalation thread

這樣就已經大幅縮小風險面。

拆 tools 的常見做法

如果你決定先砍 tools， 常見做法是把真實 side effect 改成較弱的近似行為。 例如：

• send_email 改 draft_email
• merge_pr 改 open_pr
• delete_row 改 mark_for_delete
• deploy_prod 改 build_release_plan 這種設計的好處是： agent 仍然能替你完成前 80% 的準備工作。 但最後的不可逆步驟

不再由它直接做。

反模式：我用更兇的 prompt 防一下就好

這一點必須講得很直接。 當 trifecta 三要素齊備時， 你靠 prompt 補強， 不是沒有用。

但它不構成結構性防線。 理由很簡單。 模型會：

• 誤解情境
• 受注入影響
• 忘記規則
• 在模糊目標下自己補推論

所以當它同時看得到敏感資料、 拿得到高風險 tools、 又能自動送出時， 問題不是「會不會出事」。 更像是： 「什麼時候、 在哪個角落、 用哪一種方式出事。」

這就是為什麼 prompt 不能代替拆面。

一張你可以帶回會議室的判斷表

下次你看到一個高風險 agent， 先問這五題：

問題	你要找的答案
它拿得到哪些真實 tools？	read、write、destructive、external side-effect？
它看得到哪些敏感資料？	raw content、internal note、restricted doc？
最後一步是自動還是有人 gate？	autonomy 有沒有被拆掉？
三面裡哪一面最便宜先砍？	autonomy、data、還是 tools？
如果只砍一面，體驗損失在哪裡？	慢一點、少一點資料、還是要人工送出？
如果你能答清楚這五題，

你通常就已經能找到一個 可落地的拆法。

這一課你先帶走兩句話

第一句：

看到 lethal trifecta，不要先想 prompt；先想我能拆掉哪一個面向。 第二句： 在多數真系統裡，最先拆、也最便宜拆的，通常是 autonomy。

下一課， 我們會接著看另一個很容易跟權限混在一起的問題： tool misuse 與 identity abuse。 也就是：

agent 用誰的身份、 帶著什麼參數、 留下什麼 audit。

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

這個技能在 AI 協作中的定位， 是讓你要求 AI 幫你找出 trifecta 三面裡最適合先拆的一面， 而不是讓它抽象地說「安全很重要」。 你的人類優勢：

• 只有你知道哪一種體驗損失在你的產品裡可接受，例如多一個 approval、少一個自動寄信、還是少看一層資料。
• 只有你能決定哪個 side effect 一旦送出就代價極高，因此一定要從 tool 層拿回來。 可以這樣跟 AI 說：

我有一個 agent，同時能讀敏感資料、呼叫 write tool，而且現在是全自動。請你先把它拆成 tools / data / autonomy 三面，評估哪一面最便宜先砍，並說明體驗損失與風險下降各是什麼。先不要給我大而全的架構，只要最小可落地版本。

Do