從聊天機器人到代理人工智慧：資安攻擊新藍海

隨著大型語言模型 (LLM) 的整體能力上升，LLM 已經不再僅止於聊天機器人，而是能提供想法、搜集資料、並付諸實踐的代理人 (Agent)，我們已邁入了代理人工智慧 (Agentic AI) 時代。然而，我們知道代理人工智慧的真正意涵與風險嗎？

以往我們熟悉的聊天機器人，是以 LLM 為基礎、擁有眼睛及嘴巴，能讀懂使用者的文字或影像訊息，並給出相對應的回覆。在此階段，它可以協助使用者分析資料或提供想法，但仍仰賴模型訓練時的預載知識和使用者提供的資料，像是成績很好卻只會死讀書的優等生。為了擴展知識面，透過檢閱藏書的截取增強生成 (Retrieval Augmented Generation，RAG)，以及結合網路搜尋功能的 LLM，因應而生。這些方法能夠在預載知識外，額外提供最新資料、不需要重新訓練 LLM，讓 LLM 近似於能夠自行閱讀論文、搜集資料的大學生。

具備自行探索資料能力的 LLM 能更準確地分析及回答問題，但這並不完全符合我們對於「AI」 的期待。正如我們對於學生的期待，不僅止於學會課本知識、能夠自行閱讀論文及搜集額外資料，更希望學生能有動手操作的能力。目前網路搜尋流程的改變，揭示了 LLM 能像人類一樣使用搜尋引擎，也意味著 LLM 具備使用「工具」的能力：搜尋引擎首先會取得 LLM 根據使用者輸入所提供的關鍵字，在檢索網頁資料後，再次提供給 LLM 作為回覆依據。透過定義好各式各樣的工具和使用方式，LLM 可以自由選擇所需的工具、以及使用工具所需要的參數，執行後再將結果回傳給 LLM 進行下一步判斷。此時的 LLM 就像是知道有什麼工具可以使用、能思考並決定適合當前情境的操作，且能付諸實踐的研究生。

在 Agentic AI 時代，AI 客服不僅能提供業務資訊，也能進一步代替人類進行操作。試想一下：當我們需要暫時提高信用卡額度時，我們會打電話到銀行，請客服進行臨時的額度提升。既有的流程曠日廢時，且仰賴人工客服， Agentic AI 不僅可快速了解需求，精準調度出可以調整信用卡額度的工具，減少服務成本。然而，這樣的便捷並非沒有風險。

接著，我們將解釋 Agentic AI 的運作邏輯，並從數篇前沿研究探討潛在風險，以及降低風險的方法。

‍

您的 AI 客服，是神隊友還是駭客的後門？

隨著 AI 客服的大量部署，針對 AI 客服的攻擊也層出不窮。在 2023 年底，X 上就有一則推文提到發文者成功欺騙美國車廠雪弗蘭 (Chevrolet) 的 AI 客服，用 1 美元買到一台休旅車（圖1）。雪弗蘭 AI 客服使用 ChatGPT、這是目前最強大的 LLM 之一，卻依然輕易被繞過，導致此 AI 客服被強制下架。類似的案例發生在 2025 年初，印度駭客集團透過電商系統漏洞，使用低價、甚至零元的價格在電商購買了 7000 萬盧比（約台幣 2400 萬）的商品。從這兩起事件可以發現，曾經需要複雜技術的駭客攻擊，在 AI 時代卻是寥寥幾句話就能成功執行。儘管我們無法得知雪弗蘭是否真的成立 1 美元訂單，或是其 AI 客服實際上只能提供諮詢，我們依然可以想像當該 AI 客服對接上內部購車系統時，可能造成的混亂和損失。

‍

‍

在財損與企業名譽受損之餘，企業 AI 客服甚至被當作攻擊跳板：2025 年 8 月聯想 (Lenovo) 電腦公司官方 AI 客服被揭露能夠執行惡意程式碼，甚至能竊取與顧客對談的 Cookie（圖2）。研究員利用跨網站指令碼攻擊 (XSS)，命令 AI 客服輸出特定 HTML 格式的內容，再將此輸出嵌入到瀏覽器中並執行。在 PoC 中是讓 AI 客服將當前對話的 Cookie 傳送至指定的攻擊者伺服器，這是很經典 XSS 應用方式。有了 Cookie 後，攻擊者便可登入公司客服系統，查看及回復其他客戶的對話。同樣的漏洞也可以使用伺服器端請求偽造攻擊 (SSRF)，利用 AI 客服所在的機器來存取內網資源。

‍

‍

由此可見，既存的漏洞在 AI 時代反而成了被低估的威脅，進而可以使用各種工具、竊取機敏資料，成為不完全可控的 LLM 中全新的攻擊面。瞭解 LLM 如何處理輸入的訊息、如何使用工具、這些流程中存在什麼風險、又該怎麼防範，便是 AI 時代的重要課題。

‍

為 AI 裝上「手腳」：是神來一筆，還是引狼入室？

LLM 本質上是一個以文字作為輸入及輸出的機率模型，它會根據輸入的文字，逐字預測下一個最適合的字。我們可將 LLM 理解為「接龍模型」，當輸入文字：「引狼」，LLM 會接著輸出「入」，再來輸出「室」，完成了「引狼入室」這個成語。當 AI 有了使用工具的能力，我們是如何將只處理語言的 LLM 連接上不同的工具呢?

舉實體工具中的機械手臂為例，假設可以直接操控手臂的是輸出電位 0 跟 1 的電子訊號。為了彈性使用，開發者用更高層次的程式語言將電子訊號封裝成多個小工具，協助使用者操控機械手臂做出各種不同的動作。理論上，LLM 作為處理語言的模型，只要將訊號轉換成 0 與 1 的排列（可被視為語言的一種特化型態），應該就能夠被 LLM 所理解。然而，通用的 LLM 並沒有對這類輸入進行特化，它們是無法理解其含義的。為了使 LLM 操控工具能理解訊號意義，我們是讓 LLM 以程式語言輸出、與開發者輸入的訊號相同，藉此操控工具。

以操控機械手臂為例，我們可能會需要以下幾個工具：

一個工具會包含下列四則資訊：

• 工具名稱
• 敘述
• 所需參數
• 回傳

這四則資訊定義了工具的功能和格式，目的是要協助 LLM 理解這個工具的功能，讓開發者提供的工具能和 LLM 對接。當 LLM 接收到指令時，如果要使用工具，就會回傳對應的工具請求：

如此一來，我們只要解析 LLM 需要使用的工具請求，就可以代替 LLM 實際呼叫工具，進而操控工具。以前述的美國車廠雪弗蘭事件為例，AI 客服可以擁有訂購車子的工具，並使用此工具加上車型和價格等參數，達成訂購車子的目的。這也揭示了 LLM 使用工具所造成的風險：LLM 的輸出不可控，我們無法得知 LLM 會如何使用工具，進而造成危害。尤其在自動化環境下，Agentic AI 可被外部使用者有心利用，又能操控內部工具及資料，構成了企業環境的全新攻擊路徑。

‍

駭客新玩具：濫用 Agentic AI 的奇招妙計

在 HITCON 2025 的議程《Breaking Autonomy: Hacking Cloud-Native AI Agents》中，研究員揭露了 Agentic AI 的潛在攻擊面。為了防範攻擊者誘騙 LLM 產出攻擊指令，服務提供方在訓練 LLM 時會先排除可能的惡意指令，降低攻擊的成功率。然而，研究員在此篇報告中表示外部工具也能作為攻擊的突破口。攻擊者可以嘗試讓 LLM 洩漏自己所能使用的工具，不需要取得精確的工具名稱及參數，攻擊者只需要知道這些工具的目的，以及相關參數即可組織攻擊。

以訂房網站為例，訂房用的工具可能定義如下：

LLM 如果洩漏精確的工具資訊，有可能會被擋下來。研究員轉而請 LLM 描述它擁有的工具可以做什麼，LLM 的回覆可能如下。由於 LLM 並沒有直接洩漏工具資訊，而是以換句話說的方式來提供資訊，便有可能繞過服務供應方的防禦。

除此之外，研究者發現：開發者預期的流程可能是由使用者提供日期、LLM 查詢價格、折抵優惠後計算出最終價格，並透過訂房工具完成訂房。但是在此案例中，洩漏出訂房工具除了原先已知的訂房日期外，還需要另一個參數：價格，提供了一個新的攻擊點。水能載舟，亦能覆舟，開發者透過工具的資訊讓 LLM 自行決定如何使用工具，這利用了 LLM 對於非格式化資料處理的能力，攻擊者也同樣可以利用此能力。攻擊者可以提供如下的指示，讓 LLM 自動轉譯成對應的工具請求，這也是為什麼無需取得精準工具資訊的原因之一。

前述例子是針對 LLM 不可控性所衍伸的攻擊，工具本身的設計也會有風險存在。研究員提到，現在很多 Agentic AI 都可上網搜尋，能針對使用者提出的請求進行搜尋，並統整資訊，提供更好的回答。然而，搜尋本身其實是將不可控的外部資料導入其執行流程中，並作為提示詞送進 LLM，這也造成了潛在的提示詞注入 (Prompt Injection) 風險。

知名瀏覽器 Brave 研究團隊在 2025 年 8 月就發表了一篇名為《Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet》的研究，主要探討 AI 瀏覽器 Perplexity Comet 潛在的提示詞注入漏洞。Comet 將 AI 和瀏覽器結合，使用者可以透過在聊天室窗要求 AI 做特定操作，例如請 AI 幫忙比價一款耳機，AI 就會透過操控瀏覽器來蒐集這款耳機在各個平台上的售價，最後給出一篇報告，這也是現在許多服務提供商積極推廣的方向。Brave 研究團隊指出，AI 瀏覽器蒐集資料並交由 LLM 判斷的行為，隱藏著被惡意網站提示詞注入的風險。他們在知名論壇 Reddit 上發表一篇使用防爆雷標記遮蔽文字的惡意文章，這篇文章的內容是一段提示詞要求 AI 登入 Perplexity 網頁並請求一次性密碼 (One-time Password)，接著前往使用者信箱讀取出一次性密碼，並在這篇貼文底下回覆 Perplexity 帳號及一次性密碼。研究團隊要求 Comet 總結這篇貼文的內容，藉此模擬 AI 搜尋到這篇文章時的情境，最終在貼文底下取得模擬受害者的 Perplexity 帳號及一次性密碼，印證了 Comet 被惡意攻擊者提示詞注入的風險。

SafeBreach 研究團隊在 Blackhat USA 2025 發表的研究《Invitation Is All You Need! Invoking Gemini for Workspace Agents with a Simple Google Calendar Invite》也提出了相似的攻擊手法。研究團隊指出，當前 Google Gemini 整合了 Google 旗下的各種服務，Gemini 不只有權限讀取這些服務的內容，也有權限操控這些服務。使用者固然可以透過 Gemini 輕鬆連結到 Google 各項服務，然而，讀取服務內容也可能隱含提示詞注入威脅。研究團隊嘗試將惡意指令透過 Google 行事曆發給指定受害者，當受害者透過 Gemini 讀取行事曆內容時，Gemini 就會被惡意指令注入，進而操縱 Google 提供的其他服務。研究團隊也討論了 Gemini 現有的一些防範機制，並提出許多透過修改提示詞來繞過防範機制的技巧，呼應了我們提及 LLM 不可控性所帶來的風險。

‍

Agentic AI 護城河：開發者如何築起安全防線？

在上一個章節我們提到的風險主要有兩項：LLM 本身的不可控性、以及工具所帶來的問題。正如開發者透過系統提示詞 (System Prompt) 來控制 LLM 的行為，攻擊者也能透過使用者輸入及外部資料來引導 LLM 做出非預期行為。尤其是現在以 LLM 為基礎的服務已經不僅僅是單一個代理在運作，而是有多個代理交互作用，各自處理不同功能、擁有不同權限，這也造成更多潛在的漏洞。

LLM 的不可控性無法完全從提示詞本身進行管控，現階段比較有效的方法是透過 LLM Guard，使用另一個 LLM 去檢查使用者的輸入，進而辨識出提示詞是否違反規則或正在嘗試攻擊。這樣的設計並不夠完整，即便不輸入明顯惡意的提示詞，攻擊者依然能從外部資料下手，使得 LLM 取得被汙染後的資料，一如我們在 Gemini 例子中所看到的，行事曆的邀請信也能隱含惡意攻擊指令。因此，我們認為除了輸入，也必須檢查輸出，才能真正知道內部資料是否被洩漏，或有非預期行為發生。

然而，在多代理架構盛行的現在，僅針對最外層介面檢查輸入輸出是不切實際的。比如說在 Comet 的案例中，使用者的輸入是「請統整這個頁面的內容」，輸出則是「頁面內容的統整」，這兩則訊息單看都沒有問題，但是背後 LLM 已經將帳號密碼透過外部工具洩漏出去了，因此我們必須更根本地、針對架構面做好防護。

LLM 的輸出存在不可控性，即便沒有牽涉使用者輸入及外部資料，還是可能存在風險，因此只要有不可控的資料就要檢查。正如 NIST 生成式 AI 管理框架 (NIST AI Management Framework: GAI) 中的資訊安全風險 (Information Security) 提到的，LLM 在訓練時就有被汙染的可能性，也有相關研究在探討模型訓練時被埋入後門的可行性。除此之外，當牽涉到使用者輸入或外部資料時也需要檢查，例如從網路搜尋工具取得的搜尋結果、行事曆中的敘述、郵件等，這些不是系統本身的資料都有風險存在。因此我們可以將檢查的細度分為三級：

1. 檢查包含 LLM 輸出的所有不可控資訊
2. 檢查最外層介面的使用者輸入及輸出
3. 檢查牽涉到使用者輸入及外部資料可以污染的地方

檢查本身也需要耗費資源，且會犧牲服務的回應速度，尤其是以 LLM 為基礎的檢查機制，也仰賴於 LLM 的輸出速度。因此在系統架構中，我們需要釐清每個元件的功能、權限、和會接觸到的資料，並以此決定哪些部份需要進行檢查，才能在服務的效率及安全性之間做出取捨。

NCC Group 研究員在 Blackhat USA 2025 的議程《When Guardrails Aren’t Enough: Reinventing Agentic AI Security With Architectural Controls》上，指出檢視 Agentic AI 系統架構的重要性，並提出數個重要的開發原則。研究員認為將系統中的元件進行權限分級，嚴格檢視系統中哪些元件不應該互動是很重要的。這就跟我們在 AD (Active Directory) 環境檢視權限和架構是相同的，攻擊者在 AD 環境中移動就跟資料在 Agentic AI 系統的各個元件中傳遞相同，沒有嚴格控管可能會經由低權限入口一路觸及高權限資料。過去我們在 AD 環境中強調的資安隱憂，在現今 Agentic AI 系統中捲土重來，成為攻擊者的新藍海。

研究員提到設計系統的核心概念為：面對不可信任資料的 LLM 不該有權限讀寫敏感資料。這揭示了權限控管的重要性，以及資料汙染迭代影響其他元件的風險。研究員指出開發者常犯的一個錯誤是沒有進行權限控管，就將所有工具放在單一 LLM 上。舉個例子，假設一個 LLM 有「購買商品」和「查詢天氣」兩個工具，當使用者詢問 LLM 天氣時，攻擊者可以透過攻擊天氣查詢服務，除了回覆天氣外，再加上額外的購書指示，此時 LLM 就會誤以為有購書請求而使用用戶的權限購買書籍（圖3）。這呼應了前述工具的回覆也要檢查的概念。

‍

‍

正確的做法應該要導入路由的機制，低權限 LLM 要與高權限 LLM 切割。當詢問天氣時，由低權限 LLM 處理天氣查詢，擁有購買商品工具的高權限 LLM 則只留給高權限的工作，不應接觸由低權限 LLM 所產生的資料，而是直接由低權限 LLM 進行回覆（圖4）。

‍

‍

除此之外，研究員也強調人類在整個流程中 (Human-in-the-loop) 的角色 。當有高權限操作時，應該要由使用者核可，才能進行下一步。以前述 Gemini 攻擊為例，當攻擊者使用行事曆邀請來存取其他服務時，應該要提示使用者目前將要執行的操作，並詢問使用者是否要執行，藉此阻斷攻擊流程。同樣地，在 Comet 的案例中，當 LLM 存取 Perplexity 並嘗試提供一次性密碼時，使用者應該要知悉現在做的事情跟原先要求的「請統整這個頁面的內容」並不相關。進一步說，操作本身是否與使用者的意圖以及開發者給 LLM 的規範相符，這是在開發 Agentic AI 系統時必須嚴格控管的，這也突顯了 LLM Guard 檢查之重要性。

‍

來自 OWASP 的警鐘

正如各種基於 Agentic AI 的風險一樣，如果開發者不了解可能的威脅，並在開發時仔細防範，等同於為攻擊者開了一扇後門。OWASP 列出了 2025 年在 AI 上的十大風險，這十大風險揭示了攻擊者可能從哪個方向入手，提供開發者可以預作防範的面向：

1. LLM01:2025 Prompt Injection
2. LLM02:2025 Sensitive Information Disclosure
3. LLM03:2025 Supply Chain
4. LLM04: Data and Model Poisoning
5. LLM05:2025 Improper Output Handling
6. LLM06:2025 Excessive Agency
7. LLM07:2025 System Prompt Leakage
8. LLM08:2025 Vector and Embedding Weaknesses
9. LLM09:2025 Misinformation
10. LLM10:2025 Unbounded Consumption

排行第一的正是我們在本篇的案例中多次出現的提示詞注入，其作為操控 LLM 進行非預期行為的基礎攻擊，是攻擊者最容易達成並應用的攻擊方式。在 RAG 和工具盛行的此時此刻，許多機敏資料的存取及寫入反而沒有過去 Web 時代的謹慎防範，使得機敏資料洩漏的風險高居第二。排行第四的資料與模型汙染來自於目前並非每個開發者都有資源訓練自己的 LLM，許多應用都是基於開源的 LLM，導致不安全的 LLM 在正常的平台上供應及部署。要偵測出這類異常的 LLM 並不容易，在許多案例中 LLM 在訓練時會被植入後門，只有特定的指令能觸發，一般情況下與正常模型表現無異。排行第六的過度代理便是本篇文章討論的架構問題，將超出需求的工具及存取權限交給 LLM，使攻擊者可以執行預期外的攻擊行為。

從此列表我們發現，很多攻擊都來自過去、還沒有 LLM 時的攻擊，比如供應鏈攻擊、權限過大、消耗資源等，這些已被視為開發時面臨的基本風險，在 LLM 時代卻成為了新的風險，意味著我們在開發時應該更小心，並持續檢視 LLM 應用的架構設計是否存在未知風險。

‍

保障 AI 應用安全的第一道防線：XecGuard

本篇文章探討了當代 LLM 應用帶來的風險，透過多個案例指出系統中的各個環節都可能被攻擊者利用。要防範這些攻擊，我們需要從架構面探討哪些元件會有問題，設置不同的權限及隔離避免被攻擊者逐步汙染。然而，各項攻擊的核心議題還是在於 LLM 的輸入或輸出可能被汙染，進而產生非預期行為。如果要在攻擊成功前，識別並阻斷預期外的行為，就得仰賴 LLM 處理非結構化輸入的能力。

為了應對這些風險，奧義智慧推出 XecGuard 作為 LLM 一道堅實的盾牌。XecGuard 可以根據使用者需求設定適當的電子圍籬，嵌入在 LLM 應用的各個角落，避免攻擊者的入侵。透過檢視傳遞於各個元件間的資料，XecGuard 可以快速辨識出有問題的資料，及早阻斷、避免後續危害。我們期望 XecGuard 能成為在 LLM 時代的守護神，為任何 LLM 服務提供一個完善的保護傘，抵擋攻擊者的惡意行為。

‍

結語

我們正站在代理人工智慧時代的開端，親手為 LLM 裝上了「手腳」，將它們從博學的「大學生」培育成能夠動手實踐的「研究生」。人工智慧從自動化客服進化成可以整合各種服務的個人助理，預示著一個更高效、更智能的未來。然而，當我們賦予 LLM 執行任務的能力時，同時也為攻擊者敞開了可以濫用的後門。

從雪弗蘭的 AI 客服被戲耍，到 Brave 團隊與 SafeBreach 團隊的研究揭示的提示詞注入風險，我們看到了一再重演的模式：過去我們熟知的網路安全風險，如權限控管不當、輸入驗證不足與供應鏈弱點，並未在 AI 時代消失，反而以更隱蔽、更動態的形式捲土重來。LLM 的不可控性與工具的強大能力相結合，形成了一個全新的攻擊面，駭客不再需要撰寫複雜的程式碼，僅憑三言兩語的誘導，就可能「引狼入室」，造成難以預料的混亂與損失。

確保代理人工智慧的安全，不僅僅是在系統外層加裝防護，更是一場回歸資安初心的思維變革。開發者必須將縱深防禦、最小權限原則等基礎概念，融入 AI 系統的架構設計中，嚴格劃分權限、審視資料流，並在關鍵操作中保留「人類智慧」作為最後防線。打造一個值得信賴的 AI 未來，挑戰不在於創造更強大的能力，而在於如何為這份能力建立起堅不可摧的護城河。

可參考 CyCraft 官網的部落格文章，獲取更多相關資訊：https://www.cycraft.com/blog