當 AI 系統邊界模糊：被低估的 API 整合層攻擊面

當 AI 系統從單純的聊天機器人進化為能透過 API 與外部工具互動的 Agent 時，真正的安全風險已不再是模型本身，而是其與外部世界互動的「整合層」。這正是為何，即使是看似無害的 API 新增功能，也可能創造出意想不到的漏洞，尤其當攻擊者擁有「灰盒存取」權限時。最近一篇針對 GPT-4 API 的研究報告 (arXiv:2312.14302) 便強而有力地揭示了這一點，指出當攻擊者能夠存取這些 API 時，他們能如何系統性地瓦解模型的安全防護，而這正是當前 AI 系統建構者最容易低估的威脅。

為什麼說真正的風險不在模型，而在整合層？

過去，我們談論大型語言模型（LLM）的攻擊，多半聚焦於「黑盒攻擊」。這類攻擊者對模型內部結構一無所知，只能透過精心設計的提示詞，試圖誘導模型產生有害或非預期的輸出。然而，隨著 OpenAI 等廠商將更多進階功能，例如微調（Fine-tuning）、函數呼叫（Function Calling）與知識檢索（Knowledge Retrieval），透過 API 開放給開發者，攻擊的場景也從單純的黑盒轉向了更具威脅的「灰盒」情境。

在灰盒情境下，攻擊者雖然無法取得完整的模型權重或內部架構，但他們擁有與一般開發者無異的 API 存取權限。這意味著他們可以合法地呼叫這些功能，並利用它們來探測、繞過甚至破壞模型的安全邊界。這些功能極大地擴展了 AI 系統的能力，但也同時將系統的邊界從受嚴密保護的模型本身，延伸到了外部數據、工具與函式庫。每一次 API 呼叫、每一次外部工具的啟用，都可能成為一個潛在的漏洞。整合層的複雜性與其與外部世界的緊密連結，使其成為整個 AI 系統中最脆弱的一環。

微調（Fine-tuning）如何成為最直接的後門？

微調的初衷是讓開發者能用自有數據，客製化模型的風格、語氣或特定知識，使其更符合特定應用場景。然而，前述研究 (arXiv:2312.14302) 揭露了一個令人警惕的事實：攻擊者僅需 15 個有害範例，就能透過微調成功移除 GPT-4 模型中大部分的核心安全防護機制。這相當於為模型植入了一個持久性的後門，讓其在特定條件下，能夠繞過原有的安全限制。

這與傳統的提示注入有著本質上的不同，其威脅程度更高：

• 持久性：提示注入是一次性的，每次都需要重新設計提示來嘗試繞過防護。但透過微調植入的漏洞是永久性的，除非重新訓練或調整，否則會一直存在於該客製化模型中。
• 隱蔽性：被微調「污染」過的模型，從外部呼叫時可能看起來與正常模型無異，但只要觸發特定情境，就會繞過安全限制，執行有害指令。

這對任何提供 AI 服務的企業來說都是一個嚴峻的警訊。如果我們沒有對微調的數據來源與流程進行嚴格的治理與審查，等於是將修改系統核心行為的權限，拱手讓給了潛在的攻擊者。這也意味著，單純依賴模型供應商（如 OpenAI）的內容過濾器是遠遠不夠的，因為攻擊者可以直接在模型層面繞過這些防護。

當 Function Calling 成為 Agent 的手腳，誰來確保它的安全？

自從 OpenAI 在 gpt-4-0613 版本中正式引入 Function Calling 功能後，LLM 才真正從一個「語言模型」進化為一個能與外部世界互動的「Agent」。我們可以讓模型查詢資料庫、發送 email、呼叫內部 API，這賦予了 AI 系統前所未有的能力。但同時，這也代表我們授權模型去「執行」程式碼，將其從單純的資訊處理者變成了具備操作能力的執行者。

研究 (arXiv:2312.14302) 指出，攻擊者可以透過巧妙的提示，欺騙模型呼叫非預期的函數，或是在合法的函數中傳入惡意參數，從而導致資訊洩漏、服務阻斷（DoS）甚至遠端程式碼執行（RCE）。想像一個場景：你的 AI Agent 被授權可以查詢訂單，但攻擊者透過用戶輸入，誘導 Agent 呼叫了一個未經嚴格限制的內部管理 API，進而刪除了所有用戶資料。這類攻擊的風險點，在於模型本身缺乏「安全意識」，其決策完全基於機率分佈，而非對安全後果的判斷。

這類風險的核心在於，我們往往過度信任模型在選擇工具與決定參數時的判斷力。因此，將模型與外部工具直接串連，卻沒有在中間建立一個強健的驗證與授權層，無異於將系統的控制權交給一個聰明但天真的實習生，其潛在的破壞力不容小覷。

我們該如何重新思考 AI 系統的邊界與治理？

面對整合層帶來的全新攻擊面，我們必須將安全思維從「保護模型」轉向「設計一個安全的系統邊界」。這不再只是演算法工程師的任務，更是產品經理、系統架構師與資安專家的共同責任。以下是我認為幾個關鍵的實務方向，有助於建立更強健的 AI 系統安全防線：

1. 將 API Gateway 視為第一道防線：所有由 LLM 發起的工具呼叫，都應被視為不可信的外部請求。它們必須通過一個 API Gateway，進行嚴格的 schema 驗證、參數清洗（sanitization）、權限檢查與速率限制。這能有效阻擋惡意或非預期的呼叫。
2. 實施最小權限原則（Principle of Least Privilege）：為每一個 Agent 或工具（tool）定義極其狹窄且明確的權限範圍。一個只能讀取天氣資訊的工具，就不應該擁有寫入資料庫的權限。這能將潛在的損害範圍降到最低。
3. 建立輸入與輸出的「消毒」層：永遠不要直接將用戶的原始輸入傳遞給 Agent 的決策核心，也不要將 Agent 的輸出直接傳遞給另一個系統或 API。中間必須有一層「消毒」機制，過濾掉潛在的惡意指令或敏感資訊，例如參考 OWASP Top 10 for Large Language Model Applications 的建議。
4. 強化監控與日誌審計：詳細記錄每一次的工具呼叫、參數內容以及模型的決策路徑。這不僅有助於事後追蹤問題，也能透過異常偵測，即時發現潛在的攻擊行為，並為未來的安全策略提供寶貴數據。

這場安全攻防戰的重心，已經從模型內部轉移到它與世界互動的邊界上。從這篇發表於 2023 年 12 月的研究中可以清楚看到，當我們賦予 AI 系統越多的能力與自由度，就越需要用更嚴謹的工程紀律與系統設計，為它戴上「鐐銬」。否則，我們親手打造的強大工具，最終可能成為擊垮我們自己的特洛伊木馬。

延伸閱讀

• Exploiting Novel GPT-4 APIs (arXiv:2312.14302)：本次討論的核心研究論文。
• OWASP Top 10 for Large Language Model Applications：針對 LLM 應用安全的權威性指引。
• OpenAI Assistants API Overview：官方文件，說明了 Function Calling 與 Knowledge Retrieval 等功能的整合方式。

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