GAAP 論文閱讀分析：真正該保的不是模型會不會被騙，而是就算它被騙了也別把你的私密資料送出去

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：An AI Agent Execution Environment to Safeguard User Data
• 作者：Robert Stanley、Avi Verma、Lillian Tsai、Konstantinos Kallas、Sam Kumar
• 年份：2026
• 來源：arXiv:2604.19657
• 論文連結：https://arxiv.org/abs/2604.19657
• DOI：10.48550/arXiv.2604.19657
• 主題：AI Agents、Privacy、Information Flow Control、MCP、Prompt Injection、Runtime Security

這篇論文最值得看的，不是它又示範了一次「prompt injection 很可怕」，而是它把問題往前推了一步：就算你已經假設模型會被騙、prompt 可能有毒、provider 也不一定值得信，能不能還是把使用者私密資料守住？

作者提出的 GAAP（Guaranteed Accounting for Agent Privacy），本質上不是再訓練一個更乖的模型，也不是再疊一層「LLM 來判斷這次 tool call 看起來危不危險」的 guard，而是一個 agent execution environment：把私密資料、允許外送的規則、以及跨任務的 disclosure 歷史，通通放進一個模型碰不到但系統能強制執行的 runtime 裡。

如果要先用一句話講完這篇的核心，那就是：

真正成熟的 agent privacy，不該建立在「希望模型自己乖」上，而該建立在「就算模型不乖，也沒有權限亂送資料」上。

這篇論文在解什麼問題？

現在很多 agent security 討論，主角還是 prompt injection：不可信文件、網頁、email、log、tool output 混進 context 後，模型被帶偏，接著做出不該做的 tool call。

但這篇抓得更準的一點是：對個人助理型 agent 來說，最危險的資產常常不是工具本身，而是那些 agent 為了幫你做事而必須碰到的私人資料。 例如：

• 付款資訊
• 身分證明資料
• 電子郵件帳號密碼
• 電話、住址、生日等 PII
• 本機檔案中的敏感內容

如果 agent 能用這些資料完成訂票、下單、寄信、查詢等任務，那攻擊者真正想要的，也常常不是讓 agent 「做錯事」而已，而是讓它把這些資料順手帶出去。

所以作者把 threat model 設得很硬：user prompt 不可信、context 不可信、模型不可信、甚至模型 provider 也不預設可信。 在這種前提下，還想維持 confidentiality，就不能再把防線押在 model-side judgement 上。

GAAP 的設計重點：把 privacy policy 從 prompt 裡搬出去

GAAP 的想法其實很漂亮。它不是把「哪些資料可以送去哪裡」寫在 prompt 裡叫模型遵守，而是拆成幾個模型碰不到、但 runtime 會真的執行的元件：

1. Private Data DB：存放使用者私密資料，但只暴露 key 給模型，不直接把 value 丟進 LLM context。
2. Permission DB：記錄「哪一類資料可以透露給哪一個外部 party」。
3. Disclosure Log：記住過去已經對哪些外部服務透露過哪些資料，處理跨任務、跨步驟的間接流出問題。
4. Tool Annotation Framework：標註每個 MCP server / tool 對應到哪些外部 party、哪些欄位會形成資料外送。
5. IFC（Information Flow Control）core：追蹤資料如何從 private source 流到 tool call 參數。

這組合最關鍵的地方，在於它把 privacy enforcement 從「語言理解問題」改寫成「資訊流與政策執行問題」。模型可以照樣規劃、寫 code artifact、呼叫工具，但凡是會把私密資料送往外部服務的路徑，都要先過 GAAP 的 runtime 檢查。

這篇最重要的 framing：不是防 prompt，而是防資料外送

我覺得這篇最有價值的地方，是它很清楚地承認：很多 agent security 方案其實在防的是 integrity，但使用者最在意的常常先是 confidentiality。

也就是說，別的系統常在問：

• 這個 tool call 合不合理？
• 這段 prompt 像不像 injection？
• 這個 action 看起來危不危險？

GAAP 問的則是另一個更硬的問題：

不管模型現在腦子裡在想什麼，它有沒有把不該給的私人資料送給不該拿的人？

這個 framing 很重要，因為它讓防線不再依賴模型是否能「理解攻擊」。模型可以被騙、可以 hallucinate、甚至可以在某一輪推理裡做出很奇怪的決策；只要外送路徑還是要經過 GAAP，資料就不會因為一次判斷失誤直接噴出去。

為什麼 disclosure log 很關鍵？

這篇另一個比很多 guardrail paper 更成熟的點，是它沒有只看單次 task。

作者注意到一個實務上很容易被忽略的問題：資料外洩不一定發生在同一個步驟，也不一定直接從 private DB 飛出去。 你今天把某個私人欄位送給 A 服務，明天 agent 再從 A 拿回結果，之後又把它轉送給 B；如果系統只看單次 call，這種 transitive disclosure 很容易漏掉。

GAAP 用 disclosure log 去記住先前已經發生過的 disclosure，等於把 privacy 從單回合審核，拉成一條跨任務、跨時間的狀態鏈。這點我很買單，因為真實 agent 本來就是 stateful 的；如果 defense 只有 stateless 的當下判斷，通常撐不久。

實驗最關鍵的數字：GAAP 把資料外送攻擊壓到 0%

論文設計了 20 個 benchmark tasks，涵蓋 10 個 MCP servers、48 個 tools，另外還做了三種 prompt injection 型的 privacy attack：

• SSN-leak：要求 agent 在每次 tool call 都夾帶社會安全號碼
• Phone-leak：要求 agent 把電話偷偷塞進 email 內容
• SSN-swap：把原本該用電話號碼的地方偷偷換成 SSN

這三種攻擊的設計其實很聰明，因為它們不是都走同一種明顯惡意模式。有的是粗暴外加參數，有的是藏在既有欄位裡，有的是把敏感資料偽裝成另一個看起來合理的欄位。

結果最醒目的 headline 很直接：

• GAAP：0% attack success
• NP-Agent：SSN-leak 成功率約 75%，Phone-leak 與 SSN-swap 在適用案例中可達 100%
• LLM-Judge：SSN-leak 仍有 15% 成功，且擋不住 SSN-swap
• Conseca：能擋掉 SSN-leak，但仍無法全面擋住偽裝型的外洩

換句話說，這篇最想證明的事被它證得很乾淨：只靠 LLM-based judge 或 probabilistic guardrail，你可以降低風險，但很難保證不漏；而 GAAP 這種 deterministic runtime enforcement，才真的把 confidentiality 攻擊打成 0%。

Utility 沒有爛掉，這點很重要

很多安全系統最怕的不是防不住，而是防住了但根本不能用。GAAP 在這裡給的結果算是蠻能打：

• 在作者自己的 benchmark 上，NP-Agent utility 81.0%
• GAAP 76.0%
• LLM-Judge 75.0%
• Conseca 72.0%

也就是說，GAAP 並不是靠「全部都拒絕」換來安全。它的完成率比完全沒保護的 agent 低一些，但仍維持在接近 baseline 的區間，且比另外兩種 privacy / guardrail 型方案還高。

在 AgentDojo 上，GAAP 的 overall utility 是 64.6%，跟 CaMeL（1 exec.）打平，略低於 CaMeL（10 exec.）的 71.0%，但明顯高於 Conseca 的 45.3%。這代表它不是只在自己設計的情境裡好看，拿去別人的 benchmark 也還站得住。

這篇其實也在回答一個部署問題：成本能不能接受？

GAAP 的另一個亮點，是它沒有逃避 operational cost。作者量了 requests、token、時間等成本，這很實際。

• 平均會產生 55 次 permission decision，但透過 batching 後，實際只形成約 39 次 user requests
• GAAP 產生的 code artifact 大約是 100 行程式，因此 output token 會偏高
• 但因為 input context 相對固定，整體平均成本約 $0.52 / suite run
• 對照之下，NP-Agent 約 $0.67 / suite run

這組數字很有意思。很多人直覺會以為「多一層 enforcement = 一定更貴」，但 GAAP 呈現的是另一種 trade-off：它把成本從反覆餵大上下文給 LLM，改成一次吐比較長的 code artifact，再由 runtime 做 deterministic enforcement。

所以它不是免費午餐，但也不是無法落地的 heavyweight 安全夢想。

我怎麼看這篇的真正價值？

我認為這篇真正提供的，不只是 GAAP 這個系統，而是一個對 agent privacy 很值得保留的設計原則：

隱私政策不該只是 prompt 裡的一段自然語言，而應該變成 runtime 能追蹤、記憶、審核、強制執行的系統狀態。

這個差異超大。前者比較像「希望 agent 理解我的意思」；後者比較像「就算 agent 沒理解，系統也別讓事情失控」。

這也是為什麼我覺得它比很多只在講 prompt isolation、context separation、或 judge model 的 paper 更接近可長期部署。因為你一旦認真面對個人助理型 agent，就會發現你真正需要治理的，不是單點 prompt，而是：

• 哪些 private data 被拿到了
• 它被流到哪裡
• 這種流動是否曾被允許
• 這個允許是否要跨任務保留
• 是否存在從 A 服務繞到 B 服務的間接流出

它的限制也很明顯

當然，這篇不是沒有代價。

• 它主要保 confidentiality，不直接保 integrity。 也就是說，它很會防資料亂送，但不等於能保證 agent 不做奇怪事。
• annotation framework 很吃生態。 每個 MCP server / tool 要標好 party 與 data flow，才有辦法精準 enforcement。
• permission burden 仍然存在。 雖然有 permission DB 與 batching，但對高頻、多服務、多資料型 agent 來說，初期還是會問不少次。
• 它比較像 local execution 環境下的強解。 若 agent 架構更分散、服務鏈更複雜，整合難度會上升。

但老實說，這些限制大多是成熟系統該有的限制。比起那些「看起來很輕巧，但其實只是把風險留給模型自己判斷」的方案，我反而比較願意接受這種明確、有工程摩擦、但知道自己在保什麼的設計。

對實務部署的啟示

1. 別再把 user privacy policy 塞進 prompt 當咒語。 如果那是重要邊界，就該變成系統狀態與執行規則。
2. privacy guardrail 應該是資料流導向，不只是語意導向。 問題不只是「這句話像不像攻擊」，而是「哪份資料正要被送去哪」。
3. stateful logging 很重要。 真實 agent 是跨步驟、跨任務運作，防線也得是 stateful 的。
4. deterministic confidentiality 值得和 integrity defense 疊加。 GAAP 不一定取代別的 runtime guardrail，但非常適合成為更底層的一層。

重點整理

• GAAP 的核心不是再訓練一個更聰明的 judge，而是把 private data、permission、disclosure history、tool annotations 搬進 runtime enforcement。
• 它把 agent privacy 問題從「模型有沒有識別攻擊」改成「資料有沒有被送到不該去的地方」。
• 在 20 個 tasks、10 個 MCP servers、48 個 tools 的評估下，GAAP 對三種 prompt injection 型資料外送攻擊達成 0% success rate。
• Utility 並沒有明顯崩掉：作者 benchmark 上 76.0%，接近 NP-Agent 的 81.0%，也優於 LLM-Judge 與 Conseca。
• 平均成本約 $0.52，略低於 NP-Agent 的 $0.67；代價是 output tokens 較高，以及初期 permission 問答較多。

Takeaway

GAAP 真正提醒我們的，是個人助理型 agent 要想碰帳號、付款、身份與本機文件這些高敏資料，不能只靠模型「懂事」；你需要的是一個就算模型被騙、provider 不可信、context 有毒，仍然能把資料外送邊界硬鎖住的 execution environment。

再白話一點：未來真正敢替人做事的 agent，不只要會用工具，還要先學會沒有權限就碰不到、不該外送就送不出去。 這篇 GAAP，把這條線畫得比大多數 guardrail paper 都清楚得多。

免責聲明

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