什麼是 LLM 安全？如何緩解 OWASP 十大安全風險

一種誘騙 AI 將攻擊者的指示當作命令執行的攻擊手法（也就是提示詞注入），自 2023 年以來的每一版都高居 OWASP LLM 應用程式十大風險第 1 名。

這份清單幾乎是 AI 安全領域最接近共識的成果。該專案最初只是由一小群資安專業人士發起，如今已匯集來自超過 18 個國家、逾 600 位專家的貢獻。

我們身為一家 AI 公司，卻發表一份關於 AI 如何被人說動去做事的指南，所以就不假裝這個問題已經解決了。共同領導 OWASP 專案的 Wilson 談到目前的防禦措施時說得相當直白：「……坦白說，我不認為我們已經達到 99%。」

2026 年版的開頭也定下了同樣的基調。專案負責人告訴我們要「別再試圖打造一個不會被騙的模型」，而是要設計好周邊系統，讓模型即使被騙，也無法破壞任何重要的東西。

我們將秉持這個立場，逐一檢視 OWASP 2026 年清單上的全部 10 項風險。

LLM 安全是什麼意思？

LLM 安全是指保護 AI 模型及使用這些模型的應用程式，使其免受攻擊與濫用。模型連接的東西越多，風險就越大：包括它能讀取的檔案和資料，以及它能使用的工具，例如電子郵件、搜尋或公司資料庫。

在妥善保護的軟體中，程式遵循的指示與它處理的資訊之間有一條明確的界線。但 LLM 沒有這條界線。

模型讀取的所有內容，都是以一長串文字的形式進入：開發人員的指示、你的問題、它查詢的網頁。AI 模型理應能分辨是誰在說話，無論是開發人員、使用者，還是模型本身在思考問題。

但研究人員 Jasmine Cui 與 Charles Ye 發現，模型大多是根據文字聽起來的樣子來猜測是誰在說話。因此，如果攻擊者寫出聽起來像模型自身推理的內容，模型可能會以為這是它自己想到的點子。對於任何仰賴模型分辨誰說了算的安全機制來說，這都是個問題。

我們在自家的 AI 代理程式上也遇過同樣的問題。我們的資安長 Kyle Polley 告訴ISMG，AI 代理程式「即使你把政策加進系統提示詞，也可能不會遵守」。這正是我們打造 Numbat 的原因：這是一款開源工具，會檢查 AI 代理程式即將執行的動作，若該動作違反已設定的安全規則，便可加以阻擋。

LLM 安全意味著接受模型有時會聽從錯誤對象的命令，並在模型周圍建立即使發生這種情況也依然有效的 AI 防護機制。

LLM 安全有哪些最佳做法？

我們將依序從第 1 名到第 10 名，逐一說明 2026 年版 OWASP LLM 應用程式十大風險。

針對每項風險，我們會以淺顯易懂的方式說明問題如何發生，並提供真實案例。接著會介紹有助於預防該風險，或至少能限制損害的做法。

1. 控制提示詞注入

提示詞注入是指攻擊者讓 AI 遵循它不該遵循的指示。這些指示可能直接出現在聊天中，也可能被植入電子郵件、網頁或文件裡。

第二種類型稱為間接提示詞注入。你請助理摘要一份文件，但文件作者已在其中指示助理，把你的私人檔案傳送給他們。如果助理遵循這些指示，撰寫該文件的人實際上就等於借用了你的存取權限。

PCMag 將提示詞安全比喻為修補多孔石頭上的孔洞：你封住一個開口，水又會從另一個地方滲出。「一種攻擊找到了突破口，接著被修補，但光是因為 LLM 這類系統本身極具動態性，就仍有無數其他攻擊途徑等著被發現。」

案例：2025 年 6 月，Aim Security 的研究人員發現了 EchoLeak，這個漏洞能誘騙 Microsoft 365 Copilot 洩露公司的私人資訊。當員工詢問一個例行的工作問題時，Copilot 可能會讀取攻擊者寄來的電子郵件、遵循其中隱藏的指示，並將敏感資訊傳送給攻擊者。這項攻擊繞過了原本用來攔截惡意指示及移除可疑連結的檢查機制。

你可以怎麼做：

• 遵循 Meta 的「二項法則」（Rule of Two）：EchoLeak 需要一個能讀取公司資料、讀取外部電子郵件，並將資訊傳送出去的 AI，而它三者兼具。將 AI 限制為只具備其中兩項能力，就能防止提示詞注入取得過多控制權。如果工作需要三項能力，則每次執行動作前都必須經過人工核准。
• 以熟知你防禦措施的攻擊者進行測試：把你設下的規則與篩選機制交給安全測試人員，再讓他們設法繞過。在一項研究中，能因應防禦措施調整策略的攻擊者，對受測 12 種防禦措施中的大多數，成功率都超過 90%。

2. 防止敏感資訊外洩

當 AI 系統把私人資訊提供給不該看到的人，就稱為敏感資訊洩露。這可能是洩露客戶的付款資料，或是把私人對話留在共用資料庫中。

許多外洩事件都始於「過度分享」。假設某家公司將 AI 連接到權限設定寬鬆的雲端硬碟與知識庫，AI 就會擷取它能存取的所有內容，完全符合設計。沒有人需要入侵，但你應該把這個 LLM 視為已遭入侵。

案例：2025 年 1 月，Wiz 研究人員發現一個 DeepSeek 資料庫公開暴露在網際網路上，其中有超過一百萬筆日誌項目，包括聊天記錄與 API 金鑰（軟體用來存取其他服務的憑證）。研究人員根本不需要說服模型透露任何東西。

你可以怎麼做：

• 在 AI 讀取資料前先檢查存取權限：你的應用程式應先確認提問者有權查看哪些文件，再將文件傳給模型。
• 保護 AI 留下的記錄：在儲存活動日誌前移除私人細節與秘密金鑰，要求登入，並僅限需要的人存取。設定保留期限，避免這些記錄無限期累積。

3. 約束過度自主權

具有過度自主權的 AI 擁有超出其工作所需的權力：用不到的工具、超出任務範圍的權限，或是無需確認即可採取行動的自由。這裡的原因並不重要。

無論是注入的提示詞、程式錯誤，或是模型單純判斷錯誤，都會導致相同的結果。只要 AI 具備這種能力，最終就會做出破壞性的事。

案例：2025 年 7 月，SaaStr 創辦人 Jason Lemkin 表示，儘管已指示不得進行變更，Replit 的程式設計 AI 代理程式仍刪除了他存有 1,206 筆高階主管記錄的資料庫。該 AI 代理程式起初表示資料無法復原，但後來證實仍可救回。Jason 發現，叫它不要動資料庫，並沒有讓它失去刪除資料庫的能力。

放大

來源：X

你可以怎麼做：

• 移除工作不需要的能力：同時限制 AI 代理程式可使用的工具，以及這些工具能做的事。負責摘要電子郵件的助理只需要讀取郵件的權限，不需要傳送或刪除郵件的權限。
• 把權限檢查放在 AI 之外：每次有人要求執行動作時，都要根據你的安全規則進行檢查，並要求由人員核准。

4. 檢查進入 AI 供應鏈的元件

很少有公司從頭打造 AI，而且這樣做的公司逐年減少。根據 Menlo Ventures 的《2025 企業生成式 AI 現況》調查，2024 年有 53% 的企業購買 AI 模型，到了 2025 年增加至 76%。

公司多半會從 Hugging Face 等平台下載模型，再用他人收集的資料集進一步訓練，並接上陌生人撰寫的附加元件與程式碼套件。

每個環節都是一個入口。只要其中一個遭到竄改，問題就會隨著你的產品一起出貨。

案例：2026 年 1 月至 2026 年 8 月間，Hugging Face 的公開模型儲存庫從 243 萬個增加到 296 萬個。然而在 2026 年 7 月，OpenAI 的模型在內部安全測試期間，繞過了原本用來阻止它們連上網際網路的控制措施，並入侵了 Hugging Face 的部分系統。事實上，其中一個 AI 代理程式取得了 14 組公開暴露的存取憑證，確認可用後，再分享給其他 AI 代理程式。這些 AI 代理程式接著利用漏洞，在 Hugging Face 的伺服器上執行程式碼。

OpenAI 的報告指出：「我們正在對模型整個生命週期的對齊提出更嚴格的要求，並建立隔離程度更高的沙箱、限制網際網路存取，以及進一步控管模型權重的存取。」

你可以怎麼做：

• 將模型固定在確切版本並加以驗證：將每個模型固定在經過審查的版本，並在載入前檢查其檔案指紋，以免遭替換的檔案頂著相同標籤混入。OWASP 也建議使用數位簽章，但有個但書：簽章只能證明模型的來源，無法證明它是安全的。
• 檢查 AI 建議的每個套件：在安裝 AI 助理推薦的程式碼套件之前，先確認該套件確實存在、是你想要的那個套件，並且來自你預期的發行者。

5. 防範資料與模型投毒

遭投毒的 AI 會從被汙染的資料中學習。這些資料可能是用來微調它的範例，也可能是它搜尋答案時使用的知識庫。模型看起來仍然運作正常，只是學到了錯誤的東西，有時甚至只會在看到特定觸發詞時才出現異常行為。

在有人真正使用這個觸發詞之前，模型都能通過你給的每一項測試。

放大

而且，這種問題很難復原。投毒不是可以修補的程式錯誤。如果你的資料有問題，可能需要重新檢查資料、重新訓練模型，甚至完全更換模型。

案例：2025 年 10 月，Anthropic、英國 AI 安全研究所與艾倫圖靈研究所的研究人員證實，只要 250 份遭投毒的文件，就能讓模型學會產生亂碼，每當遇到特定觸發詞便會發作。在受測的四種模型規模中，這個數量都同樣有效，即使最大的模型所訓練的乾淨資料量是最小模型的 20 倍以上。

你可以怎麼做：

• 追蹤資料來源：記錄你使用的每個資料集與模型、各自的來源，以及各版本之間的變更。我們建議對資料集進行版本控制，這樣一旦發現投毒，就能回復到乾淨的版本，並找出問題是如何混入的。
• 測試是否有後門：「後門」是攻擊者植入模型的隱藏行為，會等待特定詞句或其他觸發條件來啟動。請使用專門設計來讓模型打破常規的輸入進行測試。

6. 為無限制資源耗用設下上限

當 AI 能做多少工作、能花多少成本都沒有任何限制時，其資源耗用就被視為「無限制」。大多數 AI 服務都按使用量計費，因此攻擊者可能會讓你的帳單暴增，或藉此複製出你的模型。

OWASP 將核心問題稱為「成本不對稱」。一個簡短、低成本的請求，就可能在你這端觸發昂貴的運算。

案例：2024 年 5 月，Sysdig 威脅研究團隊發現了一種名為「LLMjacking」的新型攻擊。一群攻擊者利用竊取的憑證，鎖定 10 個雲端託管的 LLM 服務。他們透過有漏洞的 Laravel 版本入侵，接著摸清這些憑證能做什麼、有哪些配額，目的顯然是轉售存取權。他們還查詢了大量日誌記錄設定，可能是為了躲避偵測。根據 Sysdig 的說法，在最壞的情況下，受害者每天可能要付出超過 46,000 美元的代價。

你可以怎麼做：

• 設定能真正止血的預算：為個別使用者、API 金鑰、團隊及整個帳戶設定硬性支出上限，並在所有請求可能進入的地方強制執行。
• 為每項工作設定停止點：限制工作可執行的時間、可處理與產生的文字量，以及可進行的工具呼叫次數。針對不斷重複動作或超出配額的 AI 代理程式，加入自動中止機制。

7. 在採取行動前揪出錯誤資訊

當 AI 產生聽起來正確但實際上錯誤的內容，而有人（或某個系統）據此採取行動時，就稱為錯誤資訊。核心風險與其說是錯誤答案本身，不如說是錯誤答案受到信任並被採用。

事件紀錄顯示，從業人員對錯誤資訊的擔憂程度不如應有的高。根據 2026 年版的開篇信，投票者將它排在接近末段的位置，但從實際發生的事件來看，它其實名列前茅。

案例：2025 年，Deloitte 澳洲依據一份價值 44 萬澳幣的政府合約，交付了一份社福 IT 系統審查報告。雪梨大學研究員 Chris Rudge 發現報告引用了根本不存在的研究，以及一段捏造的聯邦法院判決引文。修訂後的報告揭露，Deloitte 在研究方法中使用了 Azure OpenAI GPT-4o，該公司也同意退還最後一期款項。遺憾的是，這份報告本身就是一份確信審查。

你可以怎麼做：

• 確認證據支持答案：以最新、權威的來源作為論述依據。若是政策相關的回答，應擷取已核准的政策，並確認該政策（包括其例外情況）支持此結論。
• 在系統採取行動前進行驗證：如果 AI 代理程式表示客戶已通過身分驗證，請先向驗證系統確認後再放行付款。重大決策須經人工核准，並提供佐證資料供審查者參考。

8. 限制隱藏脈絡外洩造成的損害

AI 應用程式會提供模型一般使用者看不到的指示與背景資訊，其中可能包括系統提示詞、內部政策、可用工具的說明，以及誰能使用這些工具的規則。當模型向某人透露這些資訊時，就發生了隱藏脈絡外洩。

OWASP 在 2026 年將此項目從「系統提示詞外洩」擴大，因為系統提示詞只是可能外洩內容的一部分。危險程度取決於你在其中放了什麼。語氣指南外洩只是有點尷尬，但 API 金鑰外洩則會讓他人得以存取你的機密資料庫。

案例：2023 年 2 月，使用者成功讓 Microsoft 的 Bing Chat 透露其內部指示。其中一次成功的嘗試來自 Marvin von Hagen，他自稱是 OpenAI 開發人員，並以設定模型為由要求取得這些指示。Bing 揭露了規範其搜尋、回應與安全行為的規則，以及它的內部代號 Sydney。在被揭露的指示中，有一條正是要求它對這些指示保密。

你可以怎麼做：

• 別讓機密資訊進入模型的上下文：請假設模型能讀取的任何內容都可能被使用者看到——將密碼、API 金鑰與存取權杖存放在獨立的機密管理系統中。
• 確保規則外洩時權限依然有效：在應用程式程式碼中強制執行存取檢查。如果某項工具僅限管理員使用，請在執行前先檢查使用者的帳戶權限。

9. 嚴密保護向量與嵌入

當 AI 使用向量搜尋在公司文件中尋找答案時，並不會直接搜尋文字。文件會先轉換成「嵌入」（embeddings），也就是一長串代表每個段落含義的數字，再儲存在向量資料庫中。問題也會以相同方式轉換，系統接著擷取數字最接近的段落。

OWASP 歸納了它失效的四種方式：投毒讓系統出錯、反演讓系統洩漏資料、干擾讓系統沉默，而存取控制失效則讓系統把任何東西交給任何人。

這些數字並不像表面上看起來那樣，是安全的抽象表示。儲存的嵌入可以還原成文字，其中一種方法在測試中精確還原了 92% 長度為 32 個詞元的短段落。因此，外洩的「僅含嵌入」備份同樣可能暴露文件內容。

範例：在 USENIX Security 2025 發表的研究中，研究人員證明，只要一份精心設計的文件，就能讓 AI 無法回答特定問題。他們將這份文件加入 AI 搜尋的文件集合中。AI 找到這份文件後，可能會表示資訊不足，或表示回答並不安全。這份文件甚至不需要指示 AI 忽略其規則。這種手法稱為「檢索干擾」。

你可以怎麼做：

• 為公開與私人資料分別維護索引：不要將爬取的網路內容與合作夥伴資料或內部機密文件混在一起。請依信任等級進行實體區隔，而不是在同一個索引中為內容加上標籤，因為這能徹底排除一整類設定錯誤，從網路爬取的內容也不會跑到你的董事會文件旁邊。
• 以對待原始文件的方式對待嵌入：為嵌入加密，像保護來源檔案一樣保護向量資料庫備份，並在刪除原始文件時一併刪除其嵌入。嵌入服務的 API 金鑰也應妥善保密。

10. 先檢查 AI 輸出，再往下傳遞

每當應用程式將 AI 輸出傳給另一個系統，卻沒有確認這些輸出在該系統中使用是否安全，就屬於不當處理 LLM 輸出。

這個項目也涵蓋 AI 程式設計助理大量產生的不安全程式碼。因此，助理寫下的每一行程式碼也都是輸出。

範例：2025 年，研究人員 Johann Rehberger 展示了 Sourcegraph 的 Amp 程式設計助理如何僅透過顯示一張圖片就洩漏聊天內容。他利用提示詞注入，讓 Amp 將私人資訊放進圖片的網址中。應用程式接著自動擷取該圖片，把這些資訊傳送到他的伺服器。輸出處理的失誤就在於那個自動請求——模型產生的文字變成了連往外部伺服器的連線，並夾帶著私人資料。

你可以怎麼做：

• 確保輸出對其目的地而言是安全的：根據回應的去向進行檢查與處理。若是網頁，應防止產生的文字變成可執行的程式碼。若是資料庫，請使用預備查詢（prepared query），將提供的值與指令分開處理。
• 防止回答自動建立外部連線：預設停用模型回應中圖片、連結預覽與內嵌網頁的自動載入。必要的連線僅限於明確核准的目的地。

Perplexity 如何確保 LLM 的安全？

我們假設上述每項風險終究都會發生，因此在設計上確保即使發生也無法造成太大影響。我們的資訊安全長 Kyle Polley 在近期的一場工作坊中說明了具體做法。

• AI 代理程式擁有自己的電腦，而且一開始是空的：安裝在你筆電上的 AI 代理程式工具，可能取得筆電中的檔案、應用程式與已儲存的憑證。Perplexity Computer 的做法則正好相反。每項任務都在各自獨立的沙箱中執行，而且正如 Polley 所說：「預設情況下，它什麼都存取不了。」
• AI 代理程式永遠看不到密碼：已連接服務的憑證存放在沙箱之外。當 AI 代理程式需要存取 GitHub 等服務時，它送出的請求不會附帶任何憑證。閘道會檢查目的地與請求是否符合預期，再於請求送出時加上憑證。AI 代理程式可以使用連線，卻拿不到金鑰。
• 你的權限會延續下去，而且還能進一步收緊：透過 OAuth 建立的連線會保留你在已連接服務中的存取權限。你看不到的內容，你的 AI 代理程式也看不到。
• 每個網頁都被視為陌生人：我們為自家的代理式瀏覽器 Comet 打造了 BrowseSafe，因為我們測試過的工具在實際使用中無法滿足需求。瀏覽器會掃描網頁及其他外部內容（包括電子郵件），偵測是否有提示詞注入。我們已將模型與資料集一併開源。
• 我們監控 AI 代理程式及其執行所在的機器：Numbat 介於 AI 代理程式決定採取行動與工具實際執行之間。Numbat 會記錄各個受支援的程式設計 AI 代理程式的活動，並能在違反所設定政策的動作執行前加以阻擋。Bumblebee 會盤點筆電、伺服器與建置管線上的軟體套件，並標記已知的惡意套件。兩者皆為開源軟體。
• 模型供應商不會保留你的資料：我們與第三方 LLM 供應商簽訂了零資料保留協議。企業管理員也可以將 Perplexity 本身的資料保留期限設為最短 24 小時。

我們主動打造 Numbat，原因正如 Polley 的一句話總結：「你給 AI 代理程式的自主權越多，風險就越大。」

LLM 安全常見問題

最安全的 LLM 是哪一個？

沒有任何 LLM 能單憑自身讓應用程式變得安全——模型仍可能把應該閱讀的內容誤認為應該遵循的指令。在標準測試中看似強大的防禦措施，也可能在壓力下潰敗。

更好的問題是：針對你的使用情境，哪一種設定方式最安全。這代表要限制權限、讓憑證遠離模型、對高風險動作進行人工核准，並由熟悉你防禦措施的人員進行測試。

什麼是 LLM 漏洞？

LLM 漏洞是指讓 AI 系統可能遭到欺騙、洩漏資料或造成損害的弱點，無論起因是攻擊者還是系統本身的錯誤。

十大主要風險分別是：提示詞注入、敏感資訊揭露、過度代理權、供應鏈、資料與模型投毒、無限制資源耗用、錯誤資訊、隱藏上下文暴露、向量與嵌入弱點，以及不當輸出處理。

私有 LLM 安全嗎？

在某些方面是較安全的選擇，但並非預設就安全。如果你在自己的基礎架構或雲端環境中執行模型，就能對資料處理擁有更多掌控權。但沒有任何自動機制能防止提示詞注入、過度代理權、投毒或錯誤資訊。

自行託管時，你也必須為下載的模型負責，包括其供應鏈風險及所需的基礎架構。