X-NegoBox 論文閱讀分析：很多高敏資料共享真正缺的，不是固定一個 epsilon，而是讓隱私預算真的能談

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

論文基本資訊

• 論文標題：X-NegoBox: An Explainable Privacy-Budget Negotiation Framework for Secure Peer-to-Peer Energy Data Exchange
• 作者：Poushali Sengupta、Sabita Maharjan、Frank Eliassen、Yan Zhang
• 年份：2026
• 來源：arXiv:2604.24326
• 論文連結：https://arxiv.org/abs/2604.24326
• DOI：10.48550/arXiv.2604.24326
• 主題：Privacy Engineering、Differential Privacy、Energy Data Security、Explainable AI、Sandboxed Computation、Trust Negotiation

很多人一談到資料共享隱私，就直覺把問題收斂成「要不要加 differential privacy」或「epsilon 要設多少」。但真實世界麻煩得多：同一份資料，能不能分享、該分享到多細、值得拿多少隱私成本去換，往往跟請求方是誰、用途是什麼、過去行為如何、資料欄位有多敏感，全都綁在一起。

這篇 X-NegoBox 有意思的地方，就在於它不把隱私保護當成一個固定參數，而是把它改寫成可協商、可解釋、可局部執行的 decision process。它真正補的不是「怎麼再多上一層 DP」，而是：當資料交換本身就是動態關係時，隱私預算也不該是死的。

這篇真正想解的，不是資料要不要保護，而是資料共享到底該怎麼談，才能別一開始就把原始資料交出去。

它在打哪個痛點？

論文場景放在 peer-to-peer energy data exchange。也就是說，家庭或小型能源節點不再只是被動用戶，而是會跟 aggregator、其他 peers、market operators 交換資料，支撐：

• 電力交易
• 需求響應（demand response）
• 分散式預測
• 市場協調

問題在於，這類資料很容易洩漏生活輪廓。你以為只是分享用電資料，實際上可能暴露：

• 住戶作息
• 是否有人在家
• 設備使用模式
• 消費與行為習慣

所以真正的問題不是單純「資料能不能給」，而是要給誰、給多久、給多細、值不值得、如果不值得有沒有折衷版本。

作者點出的現有機制盲點也很準：很多做法依賴固定 policy 或預先寫死的 privacy budget。這代表系統即使碰到不同信任程度、不同敏感欄位、不同業務目的，也常只能用一套僵硬門檻處理。最後的結果通常是兩種極端：

• 要嘛保太死，資料共享效率差
• 要嘛放太鬆，隱私成本被低估

這篇的核心想法：把隱私預算變成可談判的 runtime governance

X-NegoBox 的設計其實很有 runtime governance 味道。它不是先把所有情境寫死，而是讓每一筆請求進來時，都經過一個本地的 negotiation loop。

作者提出的主要構件有三個：

• DataBox：資料留在本地，不先把 raw data 搬出去
• APBNP：Autonomous Privacy Budget Negotiation Protocol，負責判定該給多少 privacy budget
• X-Contract：Explainable Agreement Layer，負責把接受、拒絕或反提案的理由講清楚

這個架構背後的思路很務實：真正該被保護的，不只是輸出，而是決定怎麼輸出的那層談判權。

它怎麼決定一筆請求能不能過？

依照論文摘要，APBNP 在決定 privacy budget 時，不是只看單一欄位，而是綜合多個因素：

• 請求方可信度（trust）
• 資料特徵敏感度（feature sensitivity）
• 宣告用途（declared purpose）
• 歷史行為（historical behavior）
• 風險感知定價（risk-aware pricing）

這很重要，因為它把很多現實世界裡本來就存在、但常被技術系統硬忽略的判斷拉回來了。不是所有資料請求都該被平等對待，也不是所有 requester 拿到同一個 epsilon 都合理。

更有意思的是，系統不只會 accept / reject。當風險不值得直接開放時，它還能提出privacy-preserving counter-offer，例如：

• 降低資料解析度
• 縮短時間範圍
• 限制欄位粒度

這種設計其實很像把資料共享從 binary gate，改成一個可協商的最小揭露流程。

很多隱私治理真正缺的，不是永遠說 yes 或 no，而是在風險太高時，還能給出一個比較不傷的 yes。

這篇最對味的地方：解釋性不是附加功能，而是協議的一部分

作者特別強調，現有資料分享機制常讓 prosumer 不知道「為什麼這筆請求被接受、拒絕或修改」。這種黑箱治理會直接打掉信任，因為使用者只會看到結果，卻不知道決策邏輯。

所以 X-Contract 的角色不是拿來做漂亮介面，而是把 decision rationale 輸出成human-readable 與 machine-readable 的理由。這代表它想守住兩件事：

• 對人可說明：讓資料擁有者知道為什麼系統這樣判
• 對系統可追責：讓後續稽核知道當時依據什麼脈絡做決策

這點很值得記。很多隱私系統的弱點不在密碼學本身，而在決策層完全不可審計。你如果不知道某次分享是因為高信任、低敏感、低風險，還是純粹規則寫壞，後面就很難修。

另一個關鍵：請求方的 code 不是把資料送去跑，而是進本地 sandbox 跑

摘要裡還有一個很值得注意的設計：在雙方談妥後，requester code 會在本地 sandbox 內執行，最後只共享 sanitized outputs。

這代表整個模型不是傳統「把資料丟給遠端處理」，而是更接近：

• 資料留在 owner 端
• 外來邏輯進受控環境執行
• 對外只放出去被治理過的結果

這種設計的安全含義很直接：把 raw data 外送的需求，改寫成把 computation 引進邊界內執行。 這不是萬靈丹，但至少把風險重心從「誰拿到原始資料」移到「誰能在什麼約束下碰資料」。

如果你平常在看 agent、MCP、sandbox、TEE、資料最小揭露這些題目，應該會很有感：這篇雖然是在能源資料交換脈絡下講事，但核心其實很接近現代 AI 系統的資料治理問題。

為什麼這篇值得放進 AI × Security 的脈絡看？

因為它談的不是傳統 static privacy control，而是自治協商 + 可解釋決策 + 本地受控執行。這三件事剛好都踩在現在 AI 系統最常缺的地方：

• 不是所有請求都該吃同一套 policy
• 不是所有授權都該是一次性 hard-coded
• 不是所有資料治理都該靠事前同意書賭後面不出事

換句話說，這篇不是在講「如何把 DP 用進能源系統」這麼窄而已。它更像是在示範一種思路：高敏資料交換不該是靜態 access control，而應該是持續評估、持續談判、持續可解釋的 runtime process。

它最值得帶走的幾個訊號

• 固定 privacy budget 很容易脫離真實風險。 同樣的 epsilon，不同資料欄位、不同 requester、不同用途，風險可能完全不同。
• 反提案（counter-offer）很重要。 很多資料治理卡住，不是因為一定不能分享，而是系統不會談更安全的分享方式。
• 可解釋性是信任基礎，不只是 UX 加分題。 沒有理由鏈，治理就很難被接受，也很難事後稽核。
• local sandbox execution 是實際安全槓桿。 真正該移動的可能不是資料，而是運算。

這篇的邊界也得講清楚

當然，從摘要來看，這篇也有幾個自然邊界：

• 它重點在 framework 與 negotiation logic，不是形式化保證所有外洩風險都被消除
• trust、purpose、historical behavior 這些輸入本身也需要治理，不然可能被 gaming
• sandbox 能降低風險，但 sandbox 本身不是免費安全，仍要看隔離與輸出管制做得多硬
• energy domain 很適合這套方法，但跨域泛化時仍要重做 sensitivity 與 incentive model

不過這些都不妨礙它的價值。因為它真正提出的是一個很實用的方向：把資料共享從「一次性授權」升級成「可審計的持續協商」。

一句話總結

這篇論文最值得看的地方，不是它又替 differential privacy 找到一個新場景，而是它提醒我們：很多高敏資料共享真正缺的，不是固定一個 epsilon，而是讓隱私預算跟著信任、用途、敏感度與歷史風險一起談，並且把整個談判、執行與輸出都留在可解釋、可稽核、可隔離的邊界裡。