在采訪中，諾丁漢大學副教授Michael Pound分享了他對與大型語言模型(LLM)相關的網絡安全風險的見解。他討論了CISO和安全團隊在LLM使用方面存在的理解或準備上的最大差距，以及在將LLMs集成到業務運營中時保護敏感數據所需的預防措施。

1.你認為在LLM使用方面，CISO和安全團隊在理解或準備上存在的最大差距是什么?

許多安全專業人員——相當合理地——對LLM背后的機器學習原理并不精通。對于過去的技術來說，這并不是什么大問題，但LLM表面上看起來如此強大，以至于可能會誤導我們認為它們不會被欺騙。我們可能會急于構建考慮不周的系統，最終在實際應用中崩潰。或許最重要的是要記住，大多數GenAI，包括LLM，都是概率性的——它們的行為具有隨機性，這意味著它們很有可能按你的意愿行事，但這個概率很少是100%。

推銷AI解決方案的公司會談論AI保障措施和一致性，以暗示他們已經以某種方式開發了這些模型，使它們不會出錯，實際上，這僅僅意味著一家公司已經嘗試訓練LLM拒絕一系列他們自己設計的惡意提示，這降低了異常行為的可能性，但并未降至零。我們無法確定LLM是否會拒絕一個全新且未見過的提示，直到它真的發生，存在許多新奇且令人驚訝的方法來說服LLM做壞事。

2.企業在向LLM輸入數據時最常見的錯誤是什么，尤其是在涉及敏感或專有信息時?

短期內，公司應確定誰在內部使用這些工具、使用哪些工具以及如何使用它們。許多最終用戶并未意識到，他們輸入到這些模型中的查詢會被上傳到云端，在某些服務上，這些查詢可能會最終成為訓練數據的一部分。很容易在不經意間上傳機密客戶或公司信息，而沒有真正考慮后果。最近的模型擁有足夠的參數來學習你的私人數據，并樂于將其發送給新用戶。像處理電子郵件或日程安排的生產力應用，根據定義，可以訪問這些信息。這些信息會流向哪里?這些工具的付費許可證通常具有更強的使用控制和協議——這些值得探索。

與歷史上的SQL攻擊類似，你必須非常小心不受控制的用戶輸入。在測試中，你可能會問LLM同一個問題100次，答案雖然不同但保持一致，然而，一旦發布，有人可能會以稍微不同的方式提問，或者更糟的是，可能會故意引導LLM進行惡意行為。對于傳統代碼，你可以控制這一點，可以指定“如果輸入不符合這個精確格式，就拒絕它”，但對于LLM來說，很容易編寫出繞過保障措施的有效提示。這個問題實際上比SQL嚴重得多。對于SQL注入，你可以構建輸入凈化、參數化查詢等機制來防止濫用，但對于LLM來說，這幾乎是不可能的。語言模型沒有提示與它們正在使用的數據之間的概念區分，它們都是一樣的。這也意味著用戶上傳的文檔或其他文件可能是惡意提示的來源，而不僅僅是直接的文本輸入。

如果LLM能夠訪問工具——與其他代碼和API的連接，風險就會增加。如果LLM可以發起網絡請求，就有可能通過markdown或其他URL泄露數據。如果LLM可以訪問你的任何私人數據，那么風險就會增加。

3.目前，在降低LLM被對抗性輸入操縱的風險方面，哪些防御或緩解措施最有效?

大多數嘗試訓練模型以避免惡意提示的努力，在一段時間后就會被人想出不同的策略來繞過保障措施。你的防御將取決于你希望LLM做什么。如果你希望用它來總結文檔或檢索數據，那么你需要仔細控制它可以讀取的文檔，以確保它們不包含惡意提示。

如果你的AI直接響應用戶輸入——例如你的客戶，那么不可避免地，有人會在某個時候測試保障措施。你應該定期測試你的LLM，看看它們如何反應，你還可以使用其他功能來檢測和剔除有問題的提示。在某些方面，SQL注入的原則仍然適用——最小權限原則和基于角色的訪問控制。設置你的AI系統，以便即使LLM試圖造成損害，也無法做到。

4.你推薦哪些框架或指南來安全地將LLM集成到業務工作流程中?

盡管我們似乎已經談論LLM很長時間了，但它們實際上只有幾年歷史。系統是新的，流行的庫經常變化。目前不錯的選擇包括Haystack、LangChain和Llama-Index。其中大多數都是基于運行你自己的本地模型的想法，如果你擔心數據隱私，這特別有用。

最大的模型需要巨大的資源，但大多數適中的模型在標準硬件上表現出色。如果你想在本地測試模型，可以嘗試Ollama。如果你想重新訓練模型，這可以是一種非常有效地更精確控制輸出的方式，可以看看Unsloth。像Copilot、ChatGPT和Anthropic Claude這樣的商業產品也很可靠，但成本更高。

5.隨著LLM越來越深入地集成到基礎設施中，我們可以預期哪些長期或系統性的網絡安全問題?

我們正處于一個將LLM嵌入越來越多系統的時代，而人們還不習慣這些模型與正常軟件開發的不同之處。想象一下編寫一段有時根本不起作用或輸出意外結果的代碼。即使是一個幾乎完美的LLM，在99.999%的情況下都是正確的，從數學上講，每1000次調用中也會失敗一次。我們需要徹底重新思考如何構建軟件，以確保不穩定的LLM可以在穩定的系統中使用。就像我們花了數年時間來填補SQL注入的漏洞一樣，最近在2015年還發生了重大泄露事件，我們將長期聽到意外提示導致LLM以災難性方式出錯的故事。