當 API 成為 AI 系統的標準配備：我們真的準備好應對新的攻擊面了嗎？

當我們談論 GPT-4 等大型語言模型（LLM）的新 API 功能時，我們直覺上會為它們帶來的便利性與無限可能性感到興奮。從讓模型能呼叫外部工具的 Function Calling，到客製化模型行為的 Fine-tuning，乃至於整合私有知識庫的 Assistants API，這些進展無疑大幅拓展了 AI 應用的邊界。然而，我認為，當 AI 與現代軟體系統越來越依賴 API、tool use 與跨系統整合時，真正被放大的往往不是功能，而是攻擊面、信任邊界與治理成本。這些新功能在簡化開發流程的同時，也以我們尚未完全理解的方式，引入了新的系統性風險。如果我們只看到功能的便利，卻忽略了其背後模糊化的信任邊界與擴張的攻擊向量，我們正在為未來更複雜、更難以偵錯的安全事件埋下伏筆。

為什麼便利的 API 反而讓系統邊界更模糊？

在傳統軟體系統中，我們對信任邊界（Trust Boundary）有著相對清晰的定義：哪些是我們的程式碼、哪些是使用者輸入、哪些是第三方服務。然而，LLM API 的整合，特別是其新功能，正逐步模糊這些界線。一份針對 GPT-4 API 的研究 (Zhan et al., 2023) 就揭示了幾個值得警惕的案例。

首先是微調（Fine-tuning）。研究發現，僅需 15 個有害範例，就可能移除 GPT-4 的核心防護機制。更令人不安的是，即便是 100 個看似無害的良性範例，也可能在無意中削弱其內建的安全護欄。這意味著，我們過去信賴的「模型供應商會做好基礎安全」這條邊界，在我們傳入自訂資料後，便不再可靠。微調資料的品質與意圖，直接穿透了原有的安全假設。

其次是知識檢索（Knowledge Retrieval），也就是常見的 RAG（Retrieval-Augmented Generation）應用場景。過去我們可能認為，只要過濾好使用者的 prompt，就能大致確保安全。但上述研究指出，攻擊者可以將惡意指令注入到被檢索的文件中。當 LLM 讀取這些「受信任」的內部文件時，指令注入就可能發生。這徹底顛覆了傳統的威脅模型：攻擊向量不再只是外部輸入，連我們自己的知識庫都可能成為特洛伊木馬。系統的信任邊界從「內部 vs. 外部」模糊成了「意圖 vs. 內容」的混沌狀態。

當 LLM 開始使用工具，誰來定義權限與責任？

Function Calling 與 Assistants API 讓 LLM 從單純的語言產生器，進化為一個能執行實際動作的 Agent。它可以查詢資料庫、發送 email、呼叫內部服務。這非常強大，但也極度危險。同一份研究 (Zhan et al., 2023) 提到，GPT-4 Assistants 可能會洩漏其可用的函數綱要（function call schema），甚至被誘騙執行任意的函數呼叫。

這直接將傳統的 API 安全問題帶入了 AI 領域。當一個 Agent 可以自主決定呼叫哪個工具、傳入什麼參數時，我們等於是給予了它一把鑰匙。問題是，這把鑰匙能打開多少扇門？我們是否遵循了「最小權限原則」（Principle of Least Privilege）？

在設計 Agent 的工具集時，我們必須像設計 IAM（Identity and Access Management）政策一樣謹慎。我認為，至少需要考慮以下幾點：

• 首先，權限範疇（Scope）必須嚴格限制。Agent 能存取的工具，應該僅限於完成當前任務所需的最小集合，而非將所有可用的 API 都暴露給它。
• 其次，參數驗證（Parameter Validation）是不可或缺的環節。我們絕對不能完全信任 LLM 產生的參數；在執行任何 API 呼叫前，後端系統必須設有嚴格的驗證層，仔細檢查參數的型別、範圍與業務邏輯。
• 再者，使用者情境綁定（User Context Binding）確保了權責對應。Agent 的操作權限，應嚴格綁定觸發它的使用者身份，絕不能執行超越該使用者權限的操作。
• 最後，對於刪除資料、發送訊息等高風險操作（Confirmation for High-risk Actions），務必設計需要使用者明確確認的機制，而非讓 Agent 自動完成。

如果沒有這些配套的治理機制，我們所謂的「AI Agent」，本質上只是一個擁有過高權限、行為卻不完全可控的內部服務帳號（service account），這在任何安全框架下都是一個惡夢。

如何從單點防禦走向系統性風險建模？

面對這些新型態的風險，僅僅依賴模型供應商（例如 OpenAI 的使用政策）或是在 prompt 層面進行過濾，是遠遠不夠的。我們需要將思維從「防範惡意 prompt」這種單點防禦，提升到「系統性風險建模」的層次。

這意味著我們必須將整個 AI application 視為一個完整的系統，去分析其中每個元件的信任關係與潛在的漏洞。例如，我們應該建立一個獨立於 LLM 之外的「生產護欄」（Production Guardrails）。這個護欄層可以是一個中介服務，負責在 LLM 做出決策（例如決定呼叫某個 API）和實際執行動作之間，進行最後的檢查與過濾。它可以根據業務規則、使用者權限、行為頻率等，來否決 LLM 的不當決策。例如，OpenAI 在其 Assistants API 文件中雖然提供了工具使用的框架，但如何安全地實現這些工具的後端邏輯，責任完全在開發者身上。

這種 defense-in-depth 的架構，承認了 LLM 本身是一個不可完全預測的「灰盒子」。我們不把所有信任都寄託在它身上，而是在系統的其他部分建立可控、可預測的檢查點。

我們該如何建立更具韌性的 AI Agent 系統？

總結來說，API 的便利性是一把雙面刃。要駕馭它，我們需要用更成熟的系統工程思維來取代單純的功能開發思維。在導入任何新的 AI API 功能，特別是涉及外部工具或資料整合時，我建議團隊先問自己幾個問題：

1. 首先，我們的信任邊界究竟在哪裡？ 我們信任哪些部分（例如系統 prompt、程式碼），又不信任哪些部分（例如使用者輸入、LLM 回應、檢索的文件）？這些邊界是否清晰且能被有效強制執行？
2. 其次，工具的權限是否已最小化？ 我們提供給 Agent 的工具，是否嚴格遵循了最小權限原則？我們是否有足夠的機制來防止其被濫用？
3. 再者，我們是否建立了獨立的監控與護欄？ 除了 LLM 內建的安全機制，我們是否有獨立的系統來監控 Agent 的行為，並在必要時介入？從 Assistants API v1 到 v2，功能不斷演進，我們的監控能力也必須同步提升。
4. 最後，我們的紅隊演練（Red-Teaming）是否足夠？ 我們是否定期且系統性地從攻擊者視角，測試我們系統的潛在弱點？前述提到的研究，便是一個絕佳的外部紅隊演練範例。

AI Agent 和多系統整合是不可逆的趨勢。然而，建立一個功能強大的 Agent 只是第一步。真正的挑戰在於如何建立一個安全、可靠、且行為可控的 Agent。這需要我們從產品、工程到治理，都用一種更嚴謹、更具系統觀的視角，去審視每一個我們引入的「便利」功能背後的隱藏成本。

延伸閱讀

• Exploiting Novel GPT-4 APIs (Zhan et al., 2023)
• OpenAI Function Calling Documentation
• OWASP Top 10 for Large Language Model Applications

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。