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

誘使 AI 把攻擊者的指示當成命令執行的攻擊——即提示注入——自 2023 年起，每一版都位居 OWASP LLM 應用程式十大風險（OWASP Top 10 for LLM Applications）第 1 位。

在 AI 安全領域，這份清單可說是最接近共識的成果。這個項目起初只是一小群安全專業人士的努力，如今已匯聚來自超過 18 個國家、逾 600 名專家的貢獻。

我們是一家 AI 公司，卻要發佈一份講述 AI 如何被人誘導行事的指南，所以就不假裝這個問題已經解決了。共同領導這個 OWASP 項目的 Wilson 談到現時的防禦措施時說得相當直白：「……坦白說，我不認為我們已經做到 99%。」

2026 年版亦以同樣的基調開篇。項目負責人告訴我們要「停止嘗試打造一個不會被愚弄的模型」，而是應設計好周邊系統，讓即使被愚弄的模型也無法破壞任何重要的東西。

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

LLM 安全是指甚麼？

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

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

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

但研究人員 Jasmine Cui 和 Charles Ye 發現，模型大多是根據文字聽起來的感覺來猜測說話者是誰。因此，如果攻擊者寫出一些聽起來像模型自身推理的內容，模型可能會以為那是自己想出來的主意。對於任何依賴模型分清誰在主導的安全機制來說，這都是一個問題。

我們在自家的 AI 代理程式上也遇到同樣的問題。我們的資訊安全總監（CISO）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——而 Copilot 三者兼備。把 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 現況》（The State of Generative AI in the Enterprise）調查，2024 年有 53% 的企業購買 AI 模型，到 2025 年更增至 76%。

公司往往會從 Hugging Face 等平台下載模型，再以他人收集的數據集進一步訓練，並接入由陌生人編寫的附加元件和程式碼套件。

這些部分每一個都是入侵途徑。只要其中一個遭到篡改，問題就會隨你的產品一併推出。

例子：2026 年 1 月至 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 萬澳元的政府合約，提交了一份福利資訊科技系統審查報告。悉尼大學研究員 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 使用向量搜尋在公司文件中尋找答案時，它並非直接搜尋文字。文件會先轉換成「嵌入」，即一長串能捕捉每段內容含義的數字，並儲存在向量資料庫中。問題亦會以同樣方式轉換，然後系統會找出數字最接近的段落。

OWASP 歸納了四種失效方式：投毒令系統出錯，反演令資料外洩，干擾令系統沉默，而存取控制失效則令系統把任何內容交給任何人。

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

例子：在 USENIX Security 2025 發表的研究中，研究人員展示了只需一份精心設計的文件，就能令 AI 無法回答某個特定問題。他們把這份文件加入 AI 搜尋的文件集合中。當 AI 找到它時，可能會表示資料不足，或表示回答並不安全。這份文件甚至不需要指示 AI 忽略其規則。這稱為「檢索干擾」。

你可以怎樣做：

• 為公開和私人資料分別維護索引：不要把從網上擷取的內容與合作夥伴資料或內部機密文件混在一起。應按信任級別進行實體分隔，而非在同一個索引中為內容加上標籤，因為這樣能杜絕一整類設定錯誤，從互聯網擷取的內容亦不會出現在你的董事會文件旁邊。
• 像對待原始文件一樣對待嵌入：將嵌入加密，像保護來源檔案一樣保護向量資料庫的備份，並在刪除原始文件時一併刪除嵌入。嵌入服務的 API 金鑰亦應妥善保密。

10. 傳遞 AI 輸出前先作檢查

每當應用程式把 AI 輸出傳遞到另一個系統，卻沒有核實該輸出能否在那裡安全使用，就屬於 LLM 輸出處理不當。

這一項亦涵蓋 AI 編程助手大量生成的不安全程式碼。因此，助手寫下的每一行程式碼同樣屬於輸出。

例子：2025 年，研究人員 Johann Rehberger 展示了 Sourcegraph 的 Amp 編程助手如何僅透過顯示一張圖片就洩露聊天內容。他利用提示詞注入，令 Amp 將私人資料放進圖片的網址中。應用程式隨即自動擷取該圖片，把資料傳送到他的伺服器。輸出處理的失誤正是那個自動請求——模型生成的文字變成了連往外部伺服器的連線，並把私人資料一併帶走。

你可以怎樣做：

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

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 安全嗎？

在某些方面較為安全，但並非預設如此。如果你在自己的基礎設施或雲端環境中運行模型，就能更好地掌控資料處理方式。然而，並沒有自動的方法可以防止提示詞注入、過度代理權、投毒或錯誤資訊。

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