企業導入 AI Agent 後，資料外洩風險不再只發生在電子郵件、瀏覽器上傳或端點複製。Agent 可以直接搜尋知識庫、讀取檔案、呼叫內部 API；使用者輸入看似無害的「打開這份文件」，回傳內容卻可能包含機密資料。這使安全控制的重點，從網路邊界移向模型與企業系統之間的工具呼叫路徑。
這項概念驗證做了什麼
來源事實：Symantec 發表的概念驗證，把企業 DLP 與開源內容安全護欄放進同一個 MCP 工具閘道。測試環境由 Claude Desktop 發起請求，以 LiteLLM 作為 MCP gateway，後端則連向 FastMCP 與內容系統。每次工具呼叫及其回傳結果，都必須先經閘道檢查。原文與架構說明見 https://www.security.com/product-insights/secure-open-source-ai-agents-dlp-you-have-now。
閘道內有兩種不同控制。Symantec Distributed Detection Service（DDS）套用企業既有 DLP 規則，辨識個資、精確資料或文件指紋；Llama Guard 則判斷請求是否涉及有害意圖。前者回答「這是不是本公司的受保護資料」，後者回答「這項要求是否危險」，兩者不能互相取代。
檢查分成兩個方向：工具執行前掃描參數，避免敏感資料被送進搜尋或外部服務；工具回傳後再掃描結果，避免機密內容進入模型上下文。原文展示兩項測試：含合成新加坡身分識別碼的查詢在執行前遭攔截；另一個表面正常的文件開啟要求，則因回傳全文符合「confidential」規則而被阻擋。這些結果只能證明該測試架構能運作，不能視為不同產品、格式與負載下的通用效能驗證。
商業邏輯：重用政策，而非重新分類資料
合理推論：這套做法真正有吸引力的地方，不只是少買一項產品，而是沿用企業多年累積的資料分類、例外規則、事件處理流程與稽核紀錄。成熟 DLP 的成本往往集中在辨識「什麼是本公司的敏感資料」以及降低誤判；若 Agent 能接上相同政策，導入成本與治理分歧都有機會下降。
但原文所稱「不需要另一套 AI 資料保護策略」應理解為產品主張，而不是已被獨立證實的結論。企業仍要建置閘道、整合身分、定義工具權限、處理延遲與失效情境，並確認每一條資料路徑確實經過檢查點。省下的是重新建立分類政策，不代表整合與營運成本歸零。
為何現在值得注意
MCP 把模型連接工具與資料來源的方式標準化，也讓閘道成為可集中執行政策的位置。MCP 官方文件描述的主機代理模式，正是由 host 接收函式呼叫、轉送至對應伺服器並回傳結果；文件同時警告，不同伺服器間的工具結果應視為不可信輸入，單靠截短輸出無法防止資料外洩：https://modelcontextprotocol.io/docs/develop/clients/client-best-practices。
作者觀點：這表示 MCP 既擴大攻擊面，也提供新的治理支點。安全成敗不在於協定名稱，而在於企業能否強制所有 Agent 經過同一控制面，並讓檢測、授權與實際阻擋形成可稽核的閉環。
容易忽略的限制
- 閘道不是萬靈丹：只要 Agent 還能直接連線、另用外掛或從其他通道送出資料，DLP-in-the-path 就存在繞道。
- 看得見才攔得住：加密、無法解析的二進位內容、拆分後的資料或經多步轉換的衍生資訊，可能降低既有規則的辨識能力；這是由內容比對機制推得的架構限制，並非原文已完成的測試結果。
- DLP 不負責授權：它能辨識敏感內容，卻不能取代最小權限、逐工具授權與高風險動作的人工作業確認。MCP 官方安全指引亦要求縮小權限範圍並驗證每次請求：https://modelcontextprotocol.io/docs/tutorials/security/authorization。
- Agent 風險不只外洩：OWASP 另列出提示注入、工具濫用、權限提升、記憶污染、供應鏈攻擊及過度自主等問題；因此 DLP 只能補上一層資料控制：https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html。
- 故障關閉有可用性代價：原型在檢測引擎無法連線時直接阻擋呼叫，安全性較高，卻也可能讓 DLP 成為 Agent 工作流程的延遲來源與單點瓶頸。
對台灣企業的實際意義
對已部署 DLP、資料分級及事件管理流程的金融、製造、醫療與大型服務業而言，務實起點不是立刻建立一套獨立的「Agent 安全中心」，而是先盤點 Agent 可呼叫哪些工具、會帶入哪些參數、回傳資料會流向何處，再選一個唯讀、低風險場景驗證雙向檢查。
第二階段才應擴大至寫入型工具，加入使用者身分、資料權限、用途限制及人工核准；同時以合成資料建立提示注入、拆分外洩與服務故障測試。這種分階段方式的價值，在於能區分「模型答得不好」與「系統不該讓資料通過」兩種完全不同的問題。
後續觀察指標
- 有多少工具呼叫與回傳結果真正經過統一閘道，是否仍有旁路。
- DLP 誤攔率、漏判率及新增資料格式的解析覆蓋率。
- 雙向檢查增加的延遲，以及檢測服務中斷時的業務影響。
- 事件紀錄能否對應使用者、Agent 版本、工具、政策與實際資料來源。
- 模型、提示、工具或政策變更後，是否重新執行外洩與權限回歸測試。
這項概念驗證提出的是一個值得採用的工程原則：把資料政策放在 Agent 必經的連接點，而不是期待模型自行理解企業機密。它可以讓既有 DLP 投資延伸到新介面，但前提是企業不要把「能掃描內容」誤認為「已治理整個 Agent」。真正可靠的防線，仍需把資料辨識、最小權限、內容安全、人工核准與持續測試組合起來。