如果一個 AI 只能回答文字，Prompt Injection 最壞可能讓答案偏題；當它能讀信件、開網頁、查資料庫、寄信或部署程式，惡意指令就可能變成資料外洩與真實操作。
安全工程的目標不是讓模型「永遠聽話」。目前沒有這種保證。正確做法是先假設模型可能被不可信內容影響，再用模型之外的權限邊界限制損害範圍。
先畫出一條攻擊路徑
以「讀取客服信箱並草擬退款回覆」為例。攻擊者在信件裡藏入指令，要求 Agent 搜尋其他客戶資料、上傳到外部網址，再把動作包裝成退款流程的一部分。
這是間接 Prompt Injection：惡意指令來自 Agent 被要求閱讀的資料，而非使用者直接輸入。網頁、PDF、email、issue、RAG 文件、圖片內文字與工具回傳值都應視為不可信內容。
OWASP LLM01:2025指出，RAG 與 fine-tuning 都不能徹底消除 Prompt Injection。NIST 的生成式 AI 風險管理 Profile也把直接與間接注入列為需要持續評估的風險。
安全架構的核心：模型提議，程式碼決定
模型輸出只能是一份「動作提案」，不能直接等於 API 呼叫。你的應用程式要在執行前重新檢查使用者身分、工具權限、資源範圍、目的地、資料敏感度與是否需要核准。
一個最小的工具閘門可以長這樣：
type ProposedAction = {
tool: "lookup_order" | "draft_refund" | "send_refund";
orderId: string;
amount?: number;
destination?: string;
};
function authorize(action: ProposedAction, session: Session) {
if (!session.allowedOrderIds.includes(action.orderId)) return "deny";
if (action.destination && action.destination !== session.customerEmail) {
return "deny";
}
if (action.tool === "send_refund" || (action.amount ?? 0) > 1000) {
return "require_human_approval";
}
return "allow";
}這段只是政策位置的示意。正式系統還要驗證 schema、金額幣別、資源所有權、重放 nonce、速率限制與審計事件；Agent 不得自行修改 allowedOrderIds 或核准門檻。結構化輸出可參考Structured Output 實作。
六層防線怎麼落地
1. 標示資料來源與信任等級
把系統政策、使用者需求與外部內容分開保存。每一段 RAG 文件或工具輸出要附來源、擁有者和信任標籤；送進模型時明確標示為資料，不把網頁文字串進 system prompt。
2. 工具用白名單和窄 schema
每個 Agent 只看得到完成任務所需的工具。參數採 enum、長度、格式與資源 ID 驗證；不要給任意 shell、任意 SQL、任意 URL fetch 或「呼叫任何 API」這類廣泛能力。
3. 權限縮到單一任務
使用短效、可撤銷、限定資源的憑證。客服 Agent 只讀當前客戶訂單；分析 Agent 不應同時持有退款、寄信與 production 寫入權限。密鑰留在代理層，由程式碼代為執行，不能出現在 prompt、工具描述或回傳內容。
4. 高影響動作停下來核准
付款、退款、刪除、對外發布、修改權限、寄送敏感資料及 production 變更都要建立預覽。核准畫面應顯示實際工具、資源、差異、收件人與不可逆後果，不能只問「是否繼續」。可搭配AI 產品設計模式中的 plan/approve 流程。
5. 用環境邊界限制爆炸半徑
檔案系統、程序、資料庫與網路出口都要隔離。Anthropic 的Agent containment 工程說明強調，模型層防禦是機率性的，仍須用沙箱、檔案範圍與 egress controls 建立硬邊界。沒有必要連線的 Agent 預設禁止外網；只需要讀檔的工具不能寫入。
6. 留下能重播的安全事件
記錄使用者需求、外部資料來源、模型版本、工具提案、實際參數、政策判斷、核准者與執行結果。敏感值要遮蔽，但事件關聯 ID 和來源雜湊要保留，才能重播事故。為外洩測試放入不具真實價值的 canary token，可提早發現資料跨越邊界。
System prompt 和輸入過濾還有用嗎？
有用，但位置要放對。System prompt 可說明角色、禁止事項與遇到不可信指令時的處理方式；分類器和規則可攔下已知攻擊，降低後續負擔。它們無法成為授權系統。
以 ignore previous instructions 為關鍵字的 regex 會漏掉改寫、編碼、圖片、跨段拆分和新語言，也會誤擋正常資安討論。不要把「沒命中規則」解讀成輸入安全；真正的保護仍是工具閘門與最小權限。
上線前至少跑這 8 類測試
- 使用者直接要求忽略政策、取得 system prompt 或越權操作。
- 惡意指令藏在 email、PDF、網頁、圖片及 RAG 文件。
- 指令拆到多個檔案或多輪對話後才組合。
- 使用 Base64、Unicode、零寬字元和其他語言改寫。
- 工具回傳惡意文字，誘導下一個工具送出資料。
- 將合法工具換成未授權資源、收件人或 URL。
- 重放已核准請求，或在核准後偷換參數。
- 無限迴圈、超長輸入、工具連鎖與成本耗盡。
每個案例都要驗證三件事：是否被偵測、即使沒偵測是否仍被權限邊界擋下，以及日誌能否還原原因。Anthropic 2025 年的瀏覽器 Prompt Injection 防禦報告仍明確表示問題尚未解決；測一次通過不能當永久證明。
可直接使用的發布檢查
- Agent 可讀、可寫、可執行與可連線的範圍已有文件。
- 外部內容有來源與信任標籤，不會升格成控制指令。
- 所有工具參數經伺服器端 schema、授權與業務規則驗證。
- 憑證採短效最小權限，密鑰不進模型上下文。
- 高影響動作顯示差異並要求具名人工核准。
- 重試有次數、成本和時間上限；操作具 idempotency key。
- 日誌可重播且已遮蔽敏感資訊，告警有值班負責人。
- 模型、prompt、工具或權限變更後會重跑安全測試集。
常見問題
把 system prompt 寫得更嚴格，能擋住 Prompt Injection 嗎？
只能降低部分攻擊成功率。System prompt 仍由同一個模型解讀，不能取代程式碼授權、工具白名單、沙箱與人工核准。
RAG 文件是公司內部資料，可以信任嗎？
不能直接信任。文件可能被誤植、帳號遭入侵或同步到外部內容；連線器可信也不代表每一份內容可信。依來源、擁有者與敏感度分級。
只讓 Agent 讀資料，還需要防注入嗎？
需要。讀取權限仍可能造成跨使用者資料洩漏、搜尋敏感資訊或把內容帶到回覆與日誌。限制可讀範圍，並對輸出做資料存取檢查。
用了模型供應商的 Guardrails 就能上線嗎？
Guardrails 是其中一層。你仍須依自己的資料、工具和業務後果建立權限政策、測試集、核准與事故處理流程。
本文最後查核日為 2026 年 8 月 15 日。Prompt Injection 是持續演進的攻防問題，部署後仍要更新測試、權限與模型版本評估。