GenAI 安全的「毒三角」：Akamai 技術長教你判斷哪些 AI 部署最危險
Akamai 技術長 Patrick Sullivan 提出 GenAI 風險評估的「毒三角」框架：當外部資料、內部機密資料與對外通訊管道三者齊聚，風險就會爆表。他建議資安團隊從質問業務單位開始——你真的需要一個完整的 LLM 嗎？
本文整理自 FS-ISAC「FinCyber Today」Podcast 2026 年 2 月播出的單集，由 FS-ISAC 首席企業事務長 Elizabeth Heathfield 專訪 Akamai 副總裁暨技術長 Patrick Sullivan。
{{< youtube rXbtcfPjq7g >}}
{{< spotify "episode/17NWPcuSm0bvkAjSzYJGnA" >}}
{{< apple-podcast "us/podcast/patrick-sullivan-powerful-but-unpredictable-what-leaders/id1663562190?i=1000750191699" >}}
同一個攻擊，跑兩次結果不同
傳統軟體有一個讓資安人員安心的特性：確定性。同樣的輸入，永遠產生同樣的輸出。你跑一次滲透測試，如果通過了，你有理由相信系統是安全的。
GenAI 打破了這個假設。
Patrick Sullivan 在訪談一開始就切入核心：GenAI 模型的本質是機率性的下一個 token 預測。即使模型權重完全不變，同一組輸入在不同次執行時會產生不同的輸出。這對資安測試的意義非常直接——一個 prompt injection 攻擊載荷第一次沒有觸發，不代表系統安全，因為同一個載荷在下一次執行時可能就會爆開。
Sullivan 強調，光是在智識上理解非確定性還不夠。他建議資安團隊必須親手操作、親眼見證這個現象：看著同一個攻擊載荷在第一次靜默無聲，第二次卻成功觸發。他認為這種「眼見為信」的體驗，是讓團隊真正內化風險意識的唯一方式。
「毒三角」：三個條件齊聚就是高風險
這集最有價值的框架，是 Sullivan 提出的「毒三角」（Toxic Trifecta）風險模型。他把 GenAI 部署的風險拆解為三個條件：
第一角：外部資料輸入。 使用者的查詢、訓練資料、或任何攻擊者可以操控的外部輸入。使用前沿模型的系統天生就帶有這一角——模型本身就吸收了大量外部資料。
第二角：內部機密資料。 透過 RAG 或類似機制存取企業內部的機密資料。這些資料在今天有嚴格的存取控制規則，但一旦接上 GenAI，邊界就開始模糊。
第三角：對外通訊管道。 API 存取（最危險的情況）、電子郵件、Slack、公開程式碼庫——任何讓 AI 能把資訊傳出去的通道。
Sullivan 的核心建議很明確：盡量把系統限制在三角中的兩角。 當三個條件同時存在時，你就需要非常強大的對策來平衡風險。這個框架的優點在於簡單好用——任何資安團隊在評估一個新的 GenAI 部署時，都可以快速數一下：這個系統觸及了幾角？
永遠自信，偶爾錯誤
Sullivan 用一句話精準概括了 GenAI 幻覺問題的本質：這些系統「經常對，偶爾錯，但永遠自信。」
面對這個問題，他列舉了幾種補償性控制：
- 模型監督模型：用第二個模型監控主模型的輸出，偵測與過去回應的顯著偏差。
- 人類在迴圈中：對高關鍵性決策保留人工審核。Sullivan 自嘲這很諷刺——資安領域一直說人類是最薄弱的環節，結果現在反而要仰賴人類來把關 AI。
- AI 評估框架：用自動化框架進行品質檢查。
沒有完美解法。但 Sullivan 的態度很務實：根據業務的關鍵程度選擇適當的控制層級，不需要對每個場景都套用最高規格。
你真的需要一個 LLM 嗎？
Sullivan 對資安團隊提出的最實用建議，是學會向業務單位提出尖銳的問題：
這個場景真的需要非確定性嗎？ 法務、會計這類應用不需要「創意」。把模型溫度設為零，強制確定性輸出，可能就夠了。
這個場景真的需要完整的 LLM 嗎？ 小型語言模型（SLM）對特定、範圍明確的任務可能同樣有效，但攻擊面小得多。Sullivan 直言，對 LLM 做威脅建模簡直是瘋狂的事——因為你現在必須考慮「一個金融應用程式是否可以被要求回答如何製造大規模殺傷性武器」這種問題。
能不能把工作流程拆解？ 把複雜的 AI Agent 工作流拆成一個個原子級的子任務，每個子代理只負責一件事。這類似傳統的「職責分離」原則，但好處更直接——當某個環節出錯時，你能精確定位問題所在。
Agent 對 Agent：黑箱堆疊的供應鏈風險
Sullivan 也點出了一個快速浮現的新問題：當 API 和網路應用開始服務的對象從人類變成 AI Agent，委託身份（delegated identity）的驗證就成了全新的挑戰。
一個合法使用者授權 Agent 代為行動，但接收端如何驗證這個 Agent 的身份和權限？Sullivan 坦言這個問題目前還在非常早期的階段。
更棘手的是供應鏈風險的指數級放大。你的 Agent 呼叫第三方 Agent，第三方又呼叫第 N 方的服務——每一層都是黑箱。Sullivan 形容這是「黑箱堆在黑箱上面」，呼籲 SaaS 供應商必須提供更多下游透明度。
歷史會重演，但未必要以悲劇收場
Sullivan 在結尾拉出了一個歷史視角：電子商務興起時帶來了 SQL injection 的浪潮，雲端遷移時帶來了錯誤配置的疫情。每一次技術浪潮都伴隨著新的資安災難。
但他保持樂觀——這一次，產業有機會從過去的教訓中主動學習，而不是等到重大資料外洩事件發生後才亡羊補牢。
他的最終建議回到原點：在整個資安與合規組織中建立基線級的 AI 實作訓練。不是讓少數專家衝在前面，而是確保從稽核到紅隊到應用安全的每一個人，都親手體驗過非確定性的現象。
因為資安團隊其實已經具備了應對 GenAI 風險所需的「第一原則」——資產清冊、存取控制、職責分離。他們缺的只是對 AI 行為的基礎理解，好讓他們知道該在哪裡、怎麼套用這些原則。
AINEXT 觀察：三件台灣企業現在就該做的事
Sullivan 的框架是從金融業的角度出發，但裡面有幾個觀點，放到台灣企業的現場會更尖銳。
第一，「你真的需要 LLM 嗎」這個問題，在台灣特別需要有人敢問。 過去一年，我們觀察到太多台灣企業導入 AI 的決策邏輯是「老闆在論壇上看到了」或「競爭對手好像有在用」，而不是「這個場景的確需要非確定性的生成能力」。Sullivan 提供了一個很好的檢核清單：這個任務需要創意嗎？如果不需要，溫度設零。需要通用知識嗎？如果不需要，用 SLM。能不能拆成子任務？如果可以，就別用一個大模型包山包海。台灣企業的資安團隊如果能學會用這三個問題去挑戰業務單位，光是這一步就能擋掉大量不必要的風險暴露。
第二，確定性和創意的取捨不是非黑即白，但防守方不能自廢武功。 Sullivan 和主持人 Heathfield 都提到了一個微妙的張力：威脅行為者正在利用 GenAI 的非確定性來「spray and pray」——大量生成變異攻擊，期望其中一個能突破防線。如果防守方把所有系統都鎖死成溫度為零的確定性模式，等於是單方面放棄了 AI 最有價值的能力，反而讓攻擊者佔據優勢。正確的做法不是全面二選一，而是按場景分級：法務合規用確定性模式，威脅偵測和紅隊演練則保留非確定性的探索空間。這個「分級管理」的概念說起來直覺，但實作上需要企業先完成 AI 資產清冊——你連哪些部門在用什麼 AI 都不知道，就無從分級。
第三，Agent 身份驗證的真空地帶，可能是下一個「雲端錯誤配置」等級的災難。 Sullivan 談到的 Agent 對 Agent 供應鏈風險，和我們現在看到的 MCP（Model Context Protocol）生態快速擴張高度相關。Anthropic 的 MCP、OpenAI 的 function calling、Google 的 tool use——這些協定讓 AI Agent 能呼叫外部工具和服務，生態正在爆炸式成長。但 Agent 的身份驗證和授權標準幾乎為零。誰在定義一個 Agent 可以代替使用者做什麼？當你的 Agent 透過 MCP 連接到第三方服務，那個服務又連接到更多服務時，Sullivan 說的「黑箱堆在黑箱上面」就不是比喻，而是每天都在發生的事。回想十年前雲端遷移的歷史：S3 bucket 公開存取、IAM 權限過度授予、跨帳戶存取控制混亂——這些「錯誤配置」造成的資料外洩事件至今仍層出不窮。Agent 生態正在走一模一樣的路，只是速度更快。現在就開始思考 Agent 的身份、授權和可追溯性，不是太早，是剛好。