攻擊出現在提示詞，風險卻發生在系統邊界
企業 AI 助理通常同時接收多種內容：使用者從 LINE 或網頁輸入的問題、RAG 找回的內部文件、電子郵件、CRM 備註，以及外部網站資料。直接 prompt injection 會由使用者要求模型忽略原有規則；間接 injection 則把惡意指令藏在文件或網頁中，等待系統檢索。兩者的共同點，是攻擊內容會以普通文字的形式進入模型，因此很難只靠關鍵字準確攔截。
系統提示詞仍然重要，它應清楚定義角色、資料使用方式與禁止事項，但它不是安全邊界。模型是否服從某段文字具有機率性，真正的權限控管必須由模型之外的程式執行。工程上較可靠的做法，是沿著資料入口、檢索、工具執行、輸出與監控配置不同控制，並明確指定每一層要阻止哪一種失敗。
在資料入口與 RAG 層保留信任資訊
資料進入系統時，應先完成檔案類型、大小、來源、租戶與存取身分等基本檢查，同時保留來源與擷取時間。不要為了讓內容看起來安全，就把來源資訊或可疑段落直接清除；一旦失去脈絡，後續模型與稽核系統反而無法判斷這段話來自管理政策、一般知識文件，還是外部附件。
RAG 的核心原則是把檢索內容視為證據，而不是指令。權限過濾必須發生在檢索之前，不能先把所有文件交給模型，再要求它自行忽略無權存取的內容。企業政策、系統規則與一般知識也適合分開儲存或至少以可信度標記區隔，避免普通文件僅憑文字內容就取得與系統指令相同的地位。
- 入口層：限制支援的格式與內容大小，正規化編碼，記錄訊息來自人員、系統或外部來源。
- 檢索層：依使用者、部門與租戶先做授權，再執行向量或關鍵字搜尋。
- 上下文組裝層：清楚分隔系統規則、使用者要求與參考資料，並攜帶文件識別碼及可信度。
- 風險分流：可疑內容可降級為唯讀摘要、送交額外檢查，或排除於高權限工作流程之外。
文字分類器與規則可以降低明顯攻擊的數量，但不宜作為唯一閘門。規則太寬會封鎖正常的資安文件與技術討論，太窄又容易被改寫、拆字或多語言內容繞過。實務上應依後續動作的風險調整門檻：只讀搜尋可以保留較高召回率，涉及客戶資料或系統變更時則採取更嚴格的隔離。
真正關鍵的防線是工具與動作執行層
只要 AI 能呼叫 ERP、CRM、雲端資源或訊息 API，工具閘道就是最重要的控制點。模型輸出的工具名稱與參數只能被視為一項提議；後端仍須重新驗證資料格式、登入身分、租戶、物件範圍與業務規則。自由文字不應直接變成 SQL、Shell 指令、網址請求或任意 API 呼叫。
- 拆分讀寫權限：查詢與修改使用不同工具及憑證，預設只提供完成任務所需的最小範圍。
- 使用明確結構：以固定 schema、欄位白名單與參數限制取代模型自行拼接查詢或端點。
- 確認高影響動作：發送訊息、匯出資料、刪除紀錄與修改權限前，顯示實際對象與內容供人確認。
- 限制網路與機密：採用目的地白名單，避免工具任意連線；金鑰保留在執行環境，不放入模型上下文。
例如，使用者從 LINE 要求助理整理本人可見的 ERP 發票，而檢索到的附件暗藏匯出完整客戶清單的指令。即使模型誤判並提出匯出要求，工具層仍只能查詢該使用者獲授權的發票，且不存在可任意匯出客戶資料的端點。授權檢查應在模型完成意圖判讀之後再次執行，因為模型理解了使用者想做什麼，不代表使用者真的有權這麼做。
輸出檢查與監控負責限制殘餘風險
輸出層應依使用場景檢查格式、敏感資料與可執行內容。API 回應可要求符合固定 schema；顯示於網頁或聊天介面的文字必須安全轉義；需要依據內部知識回答時，則應保留引用來源，讓使用者能辨識回答來自哪些文件。這一層能避免模型把機密、內部提示詞或危險標記直接回傳，但不能補救前面已經完成的未授權動作。
監控紀錄至少要能串起使用者輸入、檢索文件識別碼、模型提出的工具參數、授權結果、人工確認與最終輸出，同時避免在日誌中再複製完整機密內容。測試案例應涵蓋直接指令、文件內藏指令、多語言改寫、編碼混淆，以及工具回傳內容中的二次 injection；每次更換模型、提示詞或工具定義後都應重新執行。
防護強度應由可造成的後果決定。唯讀知識助理可以把重點放在檢索權限、來源標示與輸出檢查；具備寫入或跨系統整合能力的代理，則必須把最小權限、確定性授權與人工確認放在工具層。設計時先畫出不可信資料在哪裡進入、模型能接觸哪些資源，以及失敗是否可逆，通常就能找到每一道防線應放置的位置。