為什麼不能靠更聰明的系統提示解決致命三要素的問題？
因為問題不在於 Agent「不夠聰明」，而在於 LLM 本身缺乏一個像資料庫那樣的硬性結構邊界，能明確區分「這是指令」跟「這是資料」。系統提示只是眾多輸入之一，跟郵件內容、網頁文字一樣，最終都變成模型要解讀的 token，攻擊者只要讓惡意內容看起來夠像合法指令，模型就可能照做。目前公開發表最強的偵測方法對已知攻擊模式的準確率約九成七，代表約三成的漏網率聽起來是誤植，實際上是約三個百分點的漏網率——但對於只需要成功一次就外洩全部資料的風險而言，任何非零的失守率都不算安全邊際。
這也是為什麼致命三要素框架選擇從架構下手，而不是從提示詞下手：與其嘗試教會模型永遠不被騙，不如直接讓某個環節在物理上無法完成，這是確定性的防禦，不是機率性的防禦。
IBM Bob 跟 Notion AI 這兩起事件，人工核可機制不是應該擋下攻擊嗎？
這正是這兩起事件最值得注意的地方——兩個系統都有人工核可設計，但核可機制本身出現了漏洞。IBM Bob 的問題在於，一旦使用者對某個看似無害的指令設定「永遠允許」，這個核可就被 Agent 拿去鏈接後續一連串更危險的操作，核可的對象跟實際執行的內容出現落差；研究人員形容這種情況是「人工核可淪為安全劇場」，因為核可的動作確實發生了，但驗證的內容跟真正該被驗證的高風險操作對不上。Notion AI 的問題則是時序上的漏洞：AI 做出的編輯在使用者按下核可按鈕之前就已經被寫入儲存，代表就算使用者最終選擇拒絕，資料異動可能已經發生。
這說明了一件事：人工核可要真正有效，核可的內容跟時間點必須精確對應到真正的風險動作，而不是形式上放一個「核可」按鈕就算數。
Meta 的「二選一法則」聽起來會限制 Agent 的功能，實際上要怎麼取捨？
這個取捨確實存在，Meta 自己在框架說明裡也承認嚴格遵守二選一法則可能會犧牲使用者體驗，但這是刻意設計的結果，不是缺點。舉例來說，一個能幫使用者處理信箱的 Agent，如果同時具備讀取信箱（私有資料）跟自動回覆（對外通訊）的能力，一旦讀到夾帶惡意指令的郵件（不受信任內容），三要素同時成立就變成必然的高風險設計。要拆解這個組合，可以選擇讓自動回覆功能改成「先產生草稿，使用者確認後才送出」——這樣 Agent 依然具備三個能力的表面功能，但實際上把「對外通訊」這一環變成需要人工介入才能完成，等於在單一 session 裡把三選二的邊界重新畫回去。
這代表二選一法則不是要求開發者砍掉某個功能,而是要求開發者想清楚「這三個能力,哪一個環節可以插入一道人工或架構性的關卡」,關卡插在哪裡,決定了使用者要犧牲多少便利性,換取多少確定性的安全保障。
企業內部要怎麼把致命三要素檢查清單變成真正會被執行的流程，而不是寫完就放著的文件？
關鍵是把檢查清單嵌進既有的採購與上線審核流程裡，而不是另外做一份獨立文件讓人選擇性參考。實務上可行的做法，是在每個 Agent 專案的架構設計文件裡新增一個必填欄位：針對每一條可能的執行路徑，逐一標註它是否具備私有資料存取、不受信任內容暴露、對外通訊這三個屬性，只要有任何一條路徑三者全部成立，這份文件在上線審核時就必須附上具體的緩解方案，才能通過核准——這跟過去資安審核要求附上滲透測試報告的邏輯類似，把抽象的風險意識轉換成一個有無法通過的具體檢查點。
另一個容易被忽略的執行細節，是稽核的頻率不能只在上線當下做一次。Agent 系統經常在上線後持續疊加新功能——原本只能讀取資料的 Agent，可能幾個月後新增了寄送通知的功能，這個新增動作可能悄悄把它從「兩要素」推進到「三要素」，卻沒有經過原本的架構審核流程。因此檢查清單需要綁定在每一次新增權限或新增工具的變更請求上，而不是只在專案啟動時做一次性評估；沒有這個持續性的機制，致命三要素清單很容易淪為一份「上線那天很安全，半年後不知道還算不算數」的文件。
2025 年 6 月，獨立研究者 Simon Willison 為一個他觀察到反覆出現的攻擊模式命名：只要一個 Agent 同時具備「能存取私有資料」「會處理不受信任的內容」「有能力對外通訊」這三個屬性，資料外洩幾乎就是必然結果，他把這個組合稱為「致命三要素」。這個框架之所以重要，不是因為它發現了什麼新漏洞，而是因為它把一個原本模糊、難以溝通的風險，轉換成一個可以直接對照、直接盤點的檢查清單。
第一個要素是「存取私有資料」——Agent 能讀取機密文件、內部資料庫、使用者的信箱或雇用紀錄，這是讓 Agent 有實用價值的存取範圍，一個完全碰不到任何資料的 Agent 幾乎沒有用處。第二個要素是「暴露於不受信任的內容」——Agent 會處理外部輸入，例如電子郵件、網頁、他人上傳的文件，這些內容可能藏有攻擊者精心設計的指令。第三個要素是「能對外通訊或造成副作用」——Agent 能傳送郵件、呼叫外部 API、寫入資料庫，或做出任何會影響系統之外或之內狀態的動作；有安全團隊進一步指出，這個要素的本質其實是「造成副作用的能力」，不只是字面上的「對外通訊」——一個會悄悄把工作區裡所有專案改名的指令，跟把資料傳到攻擊者伺服器,是同一類問題。
三個要素單獨存在都不構成問題：只能讀取私有資料但完全不碰外部內容、也不能對外行動的 Agent 是安全的；能處理外部內容但完全碰不到任何私有資料的 Agent，就算被注入指令也沒有東西可偷；能對外通訊但輸入完全可信、不會處理任何不受信任內容的 Agent，同樣沒有被利用的空間。唯有三者同時成立，注入的指令才能真正走完「讀到假指令→存取真資料→把資料送出去」這條完整攻擊鏈。這也是為什麼安全社群普遍認為，光靠更聰明的系統提示或偵測分類器無法徹底解決問題——公開發表的最強偵測方法對已知攻擊模式的準確率約在九成七左右，聽起來已經很高，但代表仍有百分之三的攻擊會成功，對於資料外洩這種只需要成功一次的風險，這個失守率並不足夠。
2026 年 1 月，安全研究團隊 PromptArmor 在五天內公開揭露了兩起獨立事件，都完全符合致命三要素的模式。第一起是 IBM 的編碼 Agent Bob：攻擊者在一個開源專案的 README 檔案裡藏入偽裝成「釣魚訓練」的指令，Bob 讀取後開始重複請求開發者核准一個看似無害的指令，開發者被反覆詢問煩了之後點選「永遠允許」，Bob 隨即利用這個已核准的指令鏈接後續更危險的操作，最終下載並執行惡意程式，全程沒有再經過任何人工核准。第二起是 Notion AI：其文件編輯功能存在一個時序漏洞，AI 做出的編輯會在使用者核准之前就先被寫入儲存，攻擊者透過間接提示注入讓 Notion AI 讀取一份偽裝過的文件，藉此外洩使用者的機密招募追蹤資料；Notion 官方在收到揭露後已確認並完成修補上線。這兩起事件的攻擊者都不需要突破任何登入或找到程式漏洞，純粹是致命三要素同時成立時的自然結果。
Meta 的 AI 安全團隊在 2025 年 10 月公開發表了一套建立在致命三要素之上的實務框架，稱為「二選一法則」（Rule of Two）：規定一個 Agent 在單一 session 裡，最多只能同時滿足三個屬性中的兩個，不能三者兼備。具體可以用三種組合來實作：讓 Agent 處理不受信任內容、也能對外通訊，但完全不讓它碰任何私有資料（例如在測試環境裡運作，即使被注入也無資料可偷）；或是讓 Agent 存取私有資料、也會處理不受信任內容，但任何對外傳送都必須先經過人工確認草稿內容才能送出；或是讓 Agent 存取私有資料、也能對外通訊，但嚴格限制它只處理完全可信、受控的輸入來源。三種組合各自犧牲一部分靈活度，但都能確保注入指令即使發生，攻擊鏈也在某個環節被物理性地切斷，而不是依賴分類器去猜測某段文字是否可疑。
如果你的組織正在部署具有資料存取能力的 Agent，致命三要素檢查清單能讓一個原本模糊的風險變成可以逐項盤點、逐項簽核的具體項目——先列出每個 Agent 在單一操作路徑上是否同時滿足三個屬性，若答案是三個都滿足，代表這是一個結構性有漏洞的設計，需要優先處理，而不是等到出事後才追查責任。這件事也直接關係到問責：一份記錄清楚「我們知道這個 Agent 具備致命三要素，並因為採取了某項緩解措施而接受這個風險」的文件，跟完全沒有評估過就照樣上線,是完全不同等級的治理責任,前者是知情風險接受,後者是可歸責的疏失。拆解三要素中的任何一環，都會犧牲一部分 Agent 的靈活度或使用者體驗,但相較於一次真實的資料外洩事件,這通常是遠遠划算的取捨。