在本次Help Net Security訪談中，The Motley Fool應用與云安全總監Paolo del Mundo探討了企業如何通過建立防護機制來擴展AI應用規模，同時降低提示注入、不安全輸出和數據泄露等生成式AI特有風險。

已部署AI功能團隊的首步審計重點

生成式AI以傳統威脅模型常忽視的方式擴大了攻擊面。新入行的安全從業者應首先了解這類新型漏洞及其防御方法。OWASP大語言模型（LLM）十大風險清單是理想起點，其中列舉了提示注入、數據泄露和不安全插件設計等常見漏洞。

這些AI安全問題已引起應用安全負責人的高度警覺。ArmorCode最新調查顯示：在使用AI工具遭遇問題的受訪者中，92%提及不安全代碼問題，83%將缺乏透明度列為首要擔憂。同時55%的受訪者認為生成式AI相關威脅是其最關注的問題。

企業要確保負責任地使用生成式AI，首先應清點LLM使用情況：調用托管模型、微調自有模型還是運行RAG（檢索增強生成）流程？用戶群體是內部還是外部？是否涉及敏感數據暴露？是否部署細粒度授權機制？

對待LLM應用應如任何新服務：記錄輸入輸出、訪問控制及故障模式。投資能幫助繪制可視化數據流的工具，這些工作應先于部署復雜防御措施。

企業應用集成LLM時的輸入/輸出凈化實踐

如同傳統Web應用使用WAF識別惡意流量，生成式AI應用也需類似防護機制。這些安全護欄會對輸入輸出進行雙重檢查：

• 輸入側：系統在請求到達AI模型前，就能檢測提示注入嘗試、策略違規及越權查詢
• 輸出側：過濾模型不應泄露的信息，包括個人身份信息（PII）、內部文檔或超出設定范圍的回答。例如專用于入職指導的LLM，不應回答薪資等級或財務數據等咨詢

這些實時執行的策略邊界構成最后防線。雖不能替代訪問控制，但能大幅降低漏洞利用可能性。

自研LLM微調與托管的關鍵安全考量

微調（Fine-tuning）是通過專業數據集繼續訓練預訓練模型的過程，可能暴露代碼、內部文檔乃至敏感客戶數據等知識產權。若無防護措施，攻擊者可通過特定話術提取這些信息。

前述調查中37%的受訪者認為，軟件開發缺乏生成式AI監管是最大應用安全挑戰。因此以下安全要素尤為重要：

• 訓練數據凈化：微調前清除數據集中的密鑰、憑證、PII及專有信息
• 模型輸出測試：通過紅隊設計的提示詞主動測試模型是否存在記憶內容泄露
• 訪問控制與審計日志：限制模型訪問權限，記錄所有使用行為以便事件響應
• 模型部署衛生：確保API等服務基礎設施能防御注入、速率限制繞過等常見Web威脅
• 安全模型托管：防止底層模型文件及權重參數遭篡改或外泄
• 數據溯源追蹤：保留模型訓練數據記錄以滿足合規要求

安全團隊應將LLM視為高價值資產進行保護。

生成式AI紅隊測試工具推薦

生成式AI投入生產環境時，紅隊測試應納入軟件開發生命周期（SDLC）。Lakera Red和Straiker Ascend AI等平臺能自動化發現LLM應用的漏洞，模擬提示注入、越獄攻擊和代理逃逸等攻擊場景，堪稱持續運行的專屬滲透測試工具。

關鍵是要將這些工具集成至發布流程，而非作為一次性檢查。ArmorCode等應用安全態勢管理（ASPM）平臺還能整合滲透測試結果，通過AI輔助研判修復優先級。

Lakera的Gandalf等教育類工具雖非正式測試平臺，但能讓開發團隊親身體驗LLM如何被輕易操縱——安全意識教育始終是防御體系的重要組成部分。

AI功能部署至生產環境的CI/CD管道控制要點

所有影響模型行為的要素（如提示詞、系統消息、檢索邏輯）都應視同代碼管理：進行版本控制、代碼審查，并納入標準變更管理流程。

自動化測試需覆蓋功能與行為驗證。若更新導致模型產生敏感信息幻覺或違反策略，應在預發布環境而非生產環境捕獲問題。

掃描微調輸入中的PII或風險內容，驗證模型制品后再部署，嚴格限制生產環境推理設置和提示模板的修改權限。變更聊天機器人行為應比部署后端服務更具管控難度——LLM應遵循同等安全標準。