致命三要素：Lethal Trifecta

真正危險的不是 agent 很強，而是它剛好同時強在三個方向。

Hook

想像你做了一個自動回信 agent。

它會讀 Gmail。

它會整理收件匣。

它也會根據內容自動幫你回信。

一開始你覺得很爽。

每天早上起床，

未讀信少一半。

你甚至跟同事說：

「這個東西終於把那些重複工作吃掉了。」

一週後，

法務跑來問你一件事。

為什麼有一封內部郵件的摘要，

被轉寄到一個完全不認識的外部地址？

你一查 log，發現 agent 做了三件事：

先讀到了含客戶資料的郵件
再把郵件裡一段看似合理的內容當成工作指示
最後自己呼叫寄信 API，沒有任何人工確認

它不是單點出包。

它是整個組合出包。

如果你只盯著 prompt 看，

你會以為這是模型判斷錯誤。

但如果你退一步看權限組合，

你會發現它早就湊齊了一組很不妙的條件。

這組條件，

工程圈通常叫它 Lethal Trifecta。

名字有點戲劇化。

但它好記，

而且非常實用。

因為它逼你不要再把「這只是小工具」當藉口。

Learn

先背下來：三要素是什麼

Lethal trifecta 指的是三件事同時出現在同一個 agent 身上：

要素	中文	一句話意思
`Tools`	能呼叫外部 action	不只會想，還真的做得到
`Sensitive data`	能碰到敏感資料	例如 email、env、客戶資料、內部文件
`Full autonomy`	沒有人類 gate	可以自己跑完，不需要 approve

單看任何一個，

都不一定構成災難。

工具本身不邪惡。

資料存取本身也不邪惡。

自動化更不是原罪。

真正危險的是：

這三件事同時存在時，

外部輸入一旦穿過信任邊界，

它就能直接把「讀到的東西」變成「做出去的事」。

為什麼是乘法，不是加法

很多人做風險評估時，

會把這三要素當成 feature checklist。

有工具，+1。

有資料，+1。

有自動化，+1。

然後覺得總分 3 分也還好。

這是錯的。

因為它們不是三個獨立能力。

它們互相放大。

你可以把它想成一條完整攻擊鏈：

攻擊者先把惡意 instruction 混進不可信輸入
agent 讀到了敏感資訊或高權限上下文
agent 再用 tool 把結果送出去或做成 side effect
過程中沒有任何人攔下來

如果少掉其中任何一步，

傷害都會下降很多。

但當三步都在，

那不是「可能有風險」。

而是你在設計上已經允許最糟路徑成立。

三要素拆開看，差別很大

先看幾個常見組合。

組合	危險程度	為什麼
Tools + autonomy，沒有 sensitive data	中	可能亂做事，但資料外洩面較小
Sensitive data + autonomy，沒有 tools	中	可能亂講敏感內容，但 side effect 有限
Tools + sensitive data，沒有 autonomy	中低	有破壞潛力，但至少還有人類 gate
Tools + sensitive data + autonomy	高	外部內容一旦進來，就有完整事故路徑

這個表的重點不是數學分數。

而是你要開始習慣用「鏈路」看風險。

不是問：

「這個 agent 會不會犯錯？」

而是問：

「它犯錯時，最糟可以一路走到哪裡？」

通常最便宜的拆法：先砍 autonomy

理論上你可以拆任何一項。

你可以把敏感資料拿掉。

你也可以把工具權限縮很死。

但實務上，

先砍 autonomy 往往成本最低。

原因很單純：

你不用立刻重構整個資料層
你不用立刻重做所有 tool permission
你只要在關鍵步驟前多一個 human approval 或 review gate

這個做法很不性感。

但非常有效。

因為它把原本的「全自動攻擊鏈」，

硬生生插進一個人類檢查點。

而很多 prompt injection、

很多上下文誤判，

只要有人在最後看一眼，

就能在最便宜的地方被攔下來。

例子一：auto-reply email agent 怎麼拆

先看最典型的 email agent。

它常見的能力是：

讀收件匣
抓附件
摘要內容
自動回信
自動轉寄

如果這個系統還能讀聯絡人、

存取內部知識庫、

甚至抓到一些 CRM context，

那它幾乎一定同時碰到 tools 和 sensitive data。

這時最划算的拆法通常是：

原設計	問題	建議拆法
直接自動寄出回覆	full autonomy 太完整	改成草稿模式，最後由人按送出
自動轉寄到外部	外送風險高	外部寄送一律人工批准
可直接引用整封原文	可能夾帶敏感資訊	預設只帶最小摘要，不帶原文全文

換句話說，

你不一定要先把 agent 做笨。

你只是先把最後那一步收回來。

例子二：coding agent 怎麼拆

再看 coding agent。

它的敏感資料可能不是客戶 email。

而是：

repo 裡的 secrets
deployment token
production config
可寫入的基礎設施腳本

它的 tools 也不是寄信 API。

而是：

shell
git
CI
deploy command
cloud console wrapper

這種 agent 的拆法通常跟 email agent 不一樣。

你不一定每一步都要人工 approve。

因為那樣會失去自動化價值。

更常見的做法是：

能力	保留什麼	先拿掉什麼
讀 repo、改 code、跑測試	可以保留	這些通常屬於低到中風險
直接 push main	先拿掉	改成開 PR 或產生 patch
直接 deploy production	先拿掉	改成 staging only 或人工 gate
讀 production secrets	先拿掉	改成 mock、sandbox、限定 scope

所以 coding agent 的關鍵，

不是完全取消 autonomy。

而是把 autonomy 限縮在可逆、可 review 的範圍內。

讓它能自動做到：

「讀、改、測、提案」，

但先不要自動做到：

「推正式、碰正式資料、做不可逆操作」。

一個很實用的 review 問法

下次你看到任何 agent 設計，

你可以直接問三句：

問題	你想逼對方回答什麼
它有哪些 tool 可以造成真實世界 side effect？	先把 action 面列出來
它能讀到哪些不該亂外送的資料？	找出 sensitive data 面
哪一步沒有人工 gate？	確認 autonomy 面是否過大

如果三個答案都偏大，

那你就不用再跟自己辯論「應該沒那麼容易出事吧」。

那就是 lethal trifecta。

這一課先記兩個實務判斷

第一個判斷：

不是所有自動化都危險，

但所有同時擁有工具、敏感資料、完全自主的 agent，

都應該先被當成高風險系統對待。

第二個判斷：

不是每次都要大改架構，

很多時候你只要先加一個人類 gate，

就能用最小成本把乘法效應拆掉。

所以這一課最重要的 takeaway 不是恐嚇。

而是這句：

拆三要素時，先砍 autonomy，通常是 ROI 最高的第一刀。

下一課我們就來看，

當你知道外部內容不能信時，

到底該怎麼把它標成 untrusted。

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

這個技能在 AI 協作中的定位，是幫你在設計 agent 之前，先用結構化方式盤點「它到底危險在哪一種組合」。

你的人類優勢：

只有你知道哪個工具或資料一旦誤用，會真的造成法律、金流、客戶或 production 事故。
只有你能決定某條工作流到底能不能接受多一個人工 gate，以及那個 gate 應該放在哪一步。

可以這樣跟 AI 說：

請把下面這個 agent 設計拆成 Tools、Sensitive data、Full autonomy 三欄。每欄列出具體項目，不要抽象描述。接著告訴我：如果只能先砍一項，哪一項最便宜、最有效，並說明是加 human approval、縮權限，還是移除資料存取。[貼上你的 agent flow]