LLM-Redactor 論文閱讀分析：真正該保護的，可能不是傳輸中的 Prompt，而是它送出前那整條 request pipeline

論文基本資訊

• 論文標題：An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests
• 系統名稱：LLM-Redactor
• 作者：Justice Owusu Agyemang、Jerry John Kponyo、Elliot Amponsah、Godfred Manu Addo Boakye、Kwame Opuni-Boachie Obour Agyekum
• 年份：2026
• arXiv：https://arxiv.org/abs/2604.12064
• DOI：10.48550/arXiv.2604.12064
• 主題：AI Coding Agents、Prompt Privacy、Data Redaction、MCP、LLM Security、Privacy Engineering

如果前一批 agent security 論文主要在問「外部內容會不會劫持 agent」、「tool metadata 會不會變控制面」、「coding agent 會不會把 prompt injection 一路帶到 terminal」，那 LLM-Redactor 這篇論文補的是另一個其實更日常、但也更容易被低估的洞：很多敏感資料根本不是在模型回答之後才外洩，而是在送去雲端模型的那一刻就已經出去了。

這篇最值得看的地方，不是它又做了一個「隱私友善 middleware」，而是它把問題講得很直白：TLS 只能防路上被偷看，DLP 大多在守資料靜態儲存，secret scanner 通常在 commit 前後補漏；可是真正每天把公司內部程式碼、姓名、信箱、員工編號、API key 與專案脈絡送去模型的那條 prompt request pipeline，常常根本沒被當成第一級安全邊界。

對現在一堆 coding agent、MCP client、內部 AI copilot 來說，這個 framing 很重要。因為很多團隊還停在「我們有 HTTPS」、「我們有 vendor policy」、「我們有不要用來訓練的合約」這種安心感，但論文提醒的是：只要 prompt 明文已經進 vendor log、observability SDK、除錯記錄或法律調取範圍，你前面那些網路層保護其實都沒有碰到真正該防的東西。

這篇論文想解決什麼問題？

作者要解的不是抽象的「LLM 隱私很重要」，而是一個非常工程化的問題：

當 coding agent 或各種 LLM-powered app 必須呼叫雲端模型時，有沒有一套能直接插進 request path 的隱私保護框架，讓敏感內容在出機前就先被處理，而不是把風險全丟給供應商承諾？

這個問題之所以關鍵，是因為今天很多工作流早就不是「人手動複製一段 prompt 去網頁聊天框」，而是：

• IDE / coding agent 自動蒐集 workspace 內容
• MCP tool 回傳內部資料與檔案片段
• 系統把 log、設定檔、程式碼、客戶資訊一起組進 prompt
• 再把整包內容送往雲端 API

一旦流程長這樣，風險就不再只是「模型會不會回錯」，而是送出的內容本身就是資料外送面。這篇論文做的事情，就是把這條 outbound prompt pipeline 拉回來當成可以被治理、量測與優化的安全系統。

LLM-Redactor 的核心觀點：真正該守的是 request pipeline，不只是 transport

作者把現有做法分得很清楚：

• TLS：只防被動竊聽者，不防雲端供應商本身。
• 組織級 DLP：多半守資料落地、版本控制或檔案層，不守即時 prompt 內容。
• Secret scanner：對已知 pattern 有幫助，但不會在每一次 live LLM request 前把關。

所以作者提出的不是單一防禦，而是一個支援 MCP 與 OpenAI-compatible API 的 shim / proxy：所有雲端請求先過這層，再決定是要本地回答、先做 redaction、先做語意改寫、加噪、或改走更強的保護路徑。

這個想法其實很對味：在 agent 時代，真正該被安全化的不是 prompt 字串本身，而是 prompt 被組裝、檢查、變形、送出的那條執行鏈。

論文怎麼拆這個問題？八種保護路線同場比較

這篇論文最大的優點，是它沒有只推自己最愛的單一路線，而是直接把 8 種 privacy-preserving LLM request 技術 拉到同一個 benchmark 上比：

• A — Local-only inference：能本地做的就別送出去。
• B — Redaction with placeholder restoration：先抓敏感 span，替換成 typed placeholder，回來再還原。
• C — Semantic rephrasing：在本地把 prompt 改寫成較不暴露身分與脈絡的版本。
• D — TEE-hosted inference：把雲端推理放進可信執行環境。
• E — Split inference：本地跑前段，遠端只吃 activation。
• F — Fully homomorphic encryption：密文上運算。
• G — Secret sharing / MPC：把輸入切給多方共同計算。
• H — Differential-privacy noise：對內容加可校準噪音。

但作者也很老實：真正今天能落地、能進 developer workflow 的，主要還是 A、B、C、H 以及它們的組合。D 到 G 有理論價值，也有未來潛力，但不是你明天就能大規模塞進 coding assistant 的東西。

這篇 benchmark 為什麼值得看？

作者沒有隨便拿幾個 prompt demo，而是做了一個有 ground truth 的 leak benchmark：

• 1,300 筆樣本
• 4,014 個敏感內容標註
• 4 類 workload

四類工作負載分別是：

• WL1 — PII-heavy prose：大量姓名、email、電話、地址、員工編號等。
• WL2 — Secret-heavy configuration：.env、YAML、Terraform、API keys、bearer tokens、passwords。
• WL3 — Implicit identity prose：不直接寫 PII，但靠角色與背景就能指認人或組織。
• WL4 — Proprietary code：內部函式名、schema、專案代號、嵌入式 credentials、專有程式碼。

這個切法很實務。因為真實 prompt 泄漏風險本來就不是單一型態：

• 有些是明顯 secret，regex 好抓。
• 有些是人名、公司名、地址，NER 勉強可抓。
• 有些是「看起來沒寫名字，但其實已經能唯一識別」的隱性身分。
• 還有一整塊是 proprietary code，本質上不是 PII，也不是單純 secret pattern。

也因此，這篇論文最重要的結論不是「哪個技術最強」，而是：不同資料型態要的保護組合根本不一樣，沒有單一 technique 可以統治全部場景。

最重要的結果：沒有萬靈丹，但 A+B+C 是目前最像實用解的組合

作者的 headline finding 很直接：沒有任何單一技術能全面勝出。 真正比較有部署味道的，是把幾種方法疊起來。

其中最值得記住的是 A+B+C：

• 先判斷能不能本地回答（A）
• 不能本地做的，再先做 redaction（B）
• 必要時再做 semantic rephrasing（C）

這個組合在論文裡打出的數字很有代表性：

• WL1 / PII 的 combined leak rate = 0.006，也就是 0.6%
• WL1 / PII 500 筆樣本中 exact leak = 0
• WL4 / proprietary code 的 combined leak rate = 0.313，也就是 31.3%

這組數字超有意思。它告訴我們兩件事：

1. PII / structured sensitive data 確實可以被大幅壓低到很有部署價值的程度。
2. 但 proprietary code 這種高語意密度內容，直到今天仍然很難被「安全地送出去又不破壞任務」這件事徹底解決。

換句話說，對 coding agent 而言，真正棘手的常常不是 email 或 token，而是那些看起來只是正常程式碼、但其實本身就是企業資產的內容。

更細看一點：不同 workload 下誰表現怎樣？

論文 Table 4 跟 Table 5 很值得記一下。

1. Local routing（A）其實已經能吃掉很大一塊風險

Option A 不是神技，但它把一個常被忽略的事實量化了：只要能在本機先回答掉一部分請求，風險就會直接歸零。

在論文裡，本地路由率大致是：

• WL1 PII：94.4% 可本地處理
• WL2 Secrets：74.7%
• WL3 Implicit identity：54.0%
• WL4 Proprietary code：38.0%

這很像在說：很多 prompt 根本不需要 frontier cloud model。 如果你硬把所有東西都送出去，很多時候不是能力需要，而只是產品預設偷懶。

2. Redaction（B）很有用，但 detector recall 就是天花板

作者把這件事講得很實在：B 的上限就是 detector 的 recall。

regex-only 對 emails、IP、AWS access keys、PEM markers、bearer tokens 很有用，但對人名、組織名、地址、員工編號這類就不夠。加入 Presidio NER 之後：

• person names leak rate 降到 0.123
• organization names 降到 0.259
• 但 employee IDs 仍高達 0.798，地址也還有殘漏

這裡最有價值的不是「NER 很強」，而是作者後面補了一句非常實務的觀察：加一個自定義 `EMP-\d{4,6}` recognizer 後，employee ID leak 可以直接從 79.8% 掉到 0%。

這幾乎就是在提醒每個產品團隊：很多 prompt privacy 問題不需要先等學界發明超模型，先把你自己 domain-specific 的 pattern 寫出來，常常就是最高 ROI 的改進。

3. Semantic rephrasing（C）不是你想像中那麼萬能

乍看會以為「改寫掉敏感脈絡」很聰明，但論文結果其實沒那麼漂亮。尤其在 WL3 implicit identity 上，作者自己的 semantic leak 評估顯示：

• Baseline：0.95
• B (regex only)：0.95
• B (NER)：0.95
• B+C：1.00

這很殘酷，但也很真：語意改寫不一定真的去掉可識別性，有時只是把它換一種講法留下來。 對那些不是靠明顯字串、而是靠語境與角色組合就能識別的內容，rephrasing 很可能沒有你以為的那麼安全。

更麻煩的是，C 還會帶來 utility 風險。作者提到在 WL3 裡有 16.5% 的 rephrase 被 validator rollback，原因是改寫後不是 hallucinate 新細節，就是把原本負載技術意義的內容也一起洗掉。

4. DP noise（H）也不是白送的

作者測了不同 ε 值，結果很有意思：

• ε = 4 時，B+H 大致能接近 NER 層級效果，延遲很低
• ε = 8 時，幾乎跟 B alone 差不多，等於噪音太小沒什麼用
• ε = 2 時，exact leak 某些情況會再降，但 partial leak 可能上升，因為字碎片還在

簡單說，DP noise 比較像補層，而不是主防線。你不能期待它單獨替你解決 prompt 外洩。

Latency / utility trade-off 也很現實

這篇論文沒有只談 privacy，也有把 latency 攤出來。Table 8 顯示：

• B (NER) 大概只有 13.7–28.3 ms 級別
• B+H 也仍在 17.9–35.0 ms 左右
• 但 B+C 會直接跳到 1.6–2.5 秒
• A 若要本地模型判斷 / 回答，也大約是 1.7–2.6 秒

這就把 deployment 現實講白了：如果你的產品要守住互動延遲，B 類 redaction 幾乎是最容易塞進 production 的方案；但只要牽涉 local inference 或 semantic rephrasing，成本就立刻不是同一個量級。

而且 utility judge 也偏向 baseline。也就是說，隱私不是免費午餐：保護做得越多，任務品質常常越容易掉。

作者提出的 decision rule，其實很有部署味

我很喜歡這篇沒有停在學術比較，還直接給了 decision rule。論文建議大意是：

• 零容忍外洩（λ = 0）：能本地做就全本地；剩下走 TEE，做不到就拒絕。
• 低容忍（λ ≤ 0.05）：用 A+B+C。
• 中等容忍（λ ≤ 0.25）：用 B（含 NER），這是最便宜但仍有明顯保護效果的組合。
• 若 latency 是主 constraint：優先用 B，少碰 C。

這個 decision rule 的價值，不在它是絕對真理，而是它把 prompt privacy 從「要不要加個紅框遮一下」拉回到更像工程決策：風險容忍度、工作負載型態、延遲預算、基礎設施能力，本來就該一起算。

這篇論文最值得帶走的幾個訊號

1. Prompt privacy 是 AI coding / agent stack 的一級問題，不是附屬功能

這篇真正刺中的，是現在很多 AI 開發工具的盲點：大家很會談 output safety，卻沒把 outbound prompt content 當成核心 attack surface。 但對企業來說，很多風險其實早在「送出去」那一步就成立了。

2. Structured secret 好守，專有程式碼與隱性身分難守得多

如果只是 API key、email、AWS key，工程上已經有不少高 ROI 手段。可是一旦內容變成 proprietary code、內部架構語意、或隱性可識別背景，事情立刻複雜很多。這也是為什麼論文最亮眼的 0.6% 不該被誤讀成「問題快解完了」。

3. Domain-specific recognizer 的價值可能比更大的隱私模型還務實

員工編號案例很能說明：自家資料格式、自家代碼規則、自家專案命名習慣，本來就該進 detector。很多組織缺的不是最前沿 PET，而是根本沒把自己的資料語法接進 request firewall。

4. 這篇其實在重新定義 MCP / agent middleware 該扮演的角色

它不是只做一個 redaction tool，而是在提示我們：MCP host、API proxy、agent runtime middleware 不只是 convenience layer，也應該是 privacy enforcement layer。 這點對今天的 coding agent 生態特別重要。

限制在哪？

• workload 主要是合成資料：雖然有 ground truth 好處，但和真實企業 prompt 還是有落差。
• utility 評估偏初步：離完整 production 任務成功率還有距離。
• D–G 多數仍偏 research-stage：不能假裝今天就能全面部署 FHE / MPC。
• implicit identity 問題仍幾乎沒被真正解掉：這是最值得保持警覺的一塊。

我的看法：這篇最重要的不是「怎麼遮」，而是「在哪裡遮」

我覺得 LLM-Redactor 真正厲害的地方，不是證明 redaction 多神，而是把 attention 從 model output 拉回 request path。這點非常關鍵。

因為對 agentic systems 來說，很多風險都在往前移：

• 不只是回答可能錯
• 也不只是 tool call 可能被劫持
• 而是 整個系統在送出 prompt 前，就可能已經把不該外送的東西打包好了

所以這篇論文最像是在補一塊今天很多產品都還沒補齊的基礎設施：一個能直接站在模型 API 前、對外送內容做分類、裁切、改寫、降敏與路由決策的 request firewall。

而從數字看來，這塊基礎設施已經不是空談了——至少對 PII、secret、明顯 structured sensitive data，它可以非常有效；只是對 proprietary code 與隱性身分，大家還遠沒到可以鬆手的程度。

重點整理

• LLM-Redactor 想解的是 prompt 出機前 的隱私保護，不是傳輸中加密，也不是資料靜態 DLP。
• 論文比較了 8 種 privacy-preserving LLM request 技術，其中真正較可落地的是 A / B / C / H。
• 作者建立了 1,300 筆樣本、4,014 個標註 的 leak benchmark，涵蓋 PII、secret、implicit identity 與 proprietary code。
• A+B+C 是最像實用解的組合：PII combined leak rate 可到 0.6%，且 500 筆 PII 樣本 exact leak 為 0。
• 但在 proprietary code 上，A+B+C 仍有 31.3% combined leak，顯示專有程式碼保護仍很難。
• 只靠 redaction 的上限取決於 detector recall；加入 domain-specific recognizer 可能是最高 ROI 改進。
• semantic rephrasing 並不保證能解 implicit identity，甚至可能只是換句話繼續暴露。
• 若考慮部署現實，B (NER) 是延遲最友善的 practical baseline；若要求更低外洩，才往 A+B+C 疊。
• 這篇最重要的啟發是：prompt privacy 應該被視為 agent runtime / MCP middleware 的一級能力，而不是附加小工具。

一句話總結

LLM-Redactor 真正提醒我們的，不是「送給模型前先馬賽克一下」這麼簡單，而是當 AI coding agent 已經把 prompt request 變成一條會自動蒐集、組裝與外送內部資料的執行鏈時，真正該被當成安全邊界的，是整個 request pipeline，而不是只有傳輸加密或供應商承諾。

免責聲明

本文由 AI 產生、整理與撰寫。內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保完整性與可讀性，仍可能因模型理解限制、資料版本差異或語意轉譯而存在疏漏、不精確或更新延遲之處。實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。