Anumati 論文閱讀分析：當 Agent 開始替你接受別人的條款，真正該驗的就不只是有沒有權限呼叫

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

論文基本資訊

• 論文標題：Proof of Adherence as a Formal Consent Model for Autonomous Agent Protocols
• 作者：Ravi Kiran Kadaboina
• 年份：2026
• 來源：arXiv:2604.16524
• 論文連結：https://arxiv.org/abs/2604.16524
• DOI：10.48550/arXiv.2604.16524
• 主題：Agentic Security、MCP、A2A、Consent Management、Policy Enforcement、Auditability

這篇論文真正戳中的，不是「agent 能不能連到別的 agent」這件事本身，而是當 agent 已經能代表人去接受別人的規則、呼叫別人的能力、甚至在別人的政策底下做事時，系統到底要拿什麼證明：它不只是按過同意，而是真的一路照規矩做？

很多人談 agent protocol security，會先想到 authentication、authorization、mTLS、OAuth scope、API key、tool permission。這些當然重要，但它們主要回答的是同一類問題：誰可以呼叫什麼。 這篇 Anumati 要補的，是另一個其實同樣致命、卻常被忽略的問題：在什麼條件下可以呼叫、呼叫之後又必須怎麼做。

這兩件事看起來很像，實際上差非常多。你可以有權存取某個能力，不代表你就可以把結果跨 session 保存、不代表你可以轉給第三方 agent、不代表你可以不通知人類就直接花錢、不代表你可以拿它來做 policy 沒批准的次級用途。

換句話說，auth 是 capability gate，consent 與 adherence 才是 usage governance。 而現在多數 agent protocol，前者做得比後者完整太多。

這篇論文想解決什麼？

作者把問題描述得很直白：現在 agent 對 agent 的互動，常常只有「可不可以打這個 API / skill / tool」的判定，卻沒有一套協議層機制去證明：

• calling agent 看到的是哪一版政策
• 它是不是有把每一條 clause 真的 parse 過
• 它接受了哪些條件、對哪些條件有保留
• 每次行動前，它到底依據哪條 policy clause 做判斷
• 之後若出事，能不能回溯「它當時聲稱自己是怎麼理解與遵守的」

這裡最關鍵的觀點是：對人類世界來說，點一次「我同意」通常就已經很勉強；但對 agent 來說，理論上它其實可以做得比人類嚴格很多。 它可以逐條解析、逐步檢查、逐次記錄、逐版本重簽；問題只是今天的協議與系統設計，通常根本沒要求它這樣做。

所以這篇不是在講一個更漂亮的 privacy notice UI，也不是單純把 Terms of Service JSON 化。它要做的是把 consent 從一次性的 acceptance，推進到可驗證的、版本化的、逐行動可追責的 adherence model。

核心區分：Proof of Acceptance 不等於 Proof of Adherence

我覺得這篇最值得記住的一刀，就是它把兩種常被混在一起的東西拆開：

• Proof of Acceptance：證明你在某個時間點接受過某份文件
• Proof of Adherence：證明你在每次行動時，真的有依照相關條款評估並執行

這個區分非常重要。因為很多系統做完第一件事後，就會錯覺第二件事也差不多完成了。但實際上，acceptance 只能證明曾經同意，不能證明後續持續遵守。

放到 agent 世界更明顯：

• agent 可能在 v1.2 政策下接受過條件，但 callee 早就升到 v1.3
• agent 可能只做整份文件的布林式接受，卻沒處理某些關鍵 clause
• agent 可能有能力呼叫服務，卻在實際 workflow 中違反 retention、sharing 或 notification 義務
• 出了事之後，你只看得到「它當初有按同意」，卻看不到它每一步是否真的依條款運作

所以這篇的主張其實很像把傳統 access control 往前再推一層：真正成熟的 agent protocol，不只要管理 capability，還要管理 consent version 與 behavioral accountability。

論文提出的三個 primitive：把 consent 變成可檢查的結構

作者提出三個核心物件，組成所謂的 Agent Consent and Adherence Protocol（ACAP）：

1. PolicyDocument
2. ConsentRecord
3. AdherenceEvent

這三個名字看起來很平，但設計其實抓得蠻準。

1. PolicyDocument：不是 PDF 條款，而是可版本化、可引用的政策物件

PolicyDocument 是 callee 公布的機器可讀政策文件。重點不只是 machine-readable，而是它同時具備：

• semantic versioning
• content hash
• effective date
• supersedes 關係
• 逐條 claim 的穩定識別

這設計背後的精神很像軟體供應鏈裡的可驗證版本治理：你不能只說「我有 policy」，你得說清楚是哪一版、哪幾條、哪一條從什麼版本開始生效、哪一條改了就必須重新同意。

特別值得注意的是 stable claim ID 這件事。這讓 calling agent 不只知道文件更新了，還知道到底是哪些條款變了。對長流程 agent 來說，這很重要，因為不是每次政策微調都該把整個 workflow 全停掉；但如果是某個 governing claim 真的變了，那就應該精準觸發 re-consent 或降級。

2. ConsentRecord：不是「我同意」，而是「我怎麼理解每一條」

ConsentRecord 是這篇最有意思的地方。它不是單一 accept / reject flag，而是要求對每個 PolicyClaim 都有對應的 ParsedClaim。

也就是說，agent 不能只回一句「ok 我接受」，然後默默略過麻煩條款。它必須對每一條 claim 記錄：

• 有沒有理解
• 是否爭議 / 保留
• 若不同意，原因是什麼

這點我很喜歡，因為它把「consent」從法律形式上的按鈕，拉回更接近系統語意上的 parsing 與 commitment。對 agent 來說，真正有價值的不是它按了 accept，而是它不能裝傻略過不想理的 clause。

論文甚至支援 conditional consent：某些條款接受、某些條款保留，然後由 callee 對應 skill 做 claim-level gating。這比一刀切更實際。因為 production agent workflow 裡，很多時候不是非全有即全無，而是允許在受限能力下繼續運作。

這其實把 consent model 往 capability mediation 推進了一步：不是只看「你是不是已登入」，而是看你對哪些政策條款有完整承諾，因此哪些 skill 仍然可用。

3. AdherenceEvent：每一步行動都留下它依哪條規則判斷

AdherenceEvent 則把整件事從簽約帶到執行期。每次 action 嘗試前，都應留下：

• 引用了哪條 policy clause
• 做了什麼判斷
• 理由是什麼
• 最後允許、拒絕還是要求額外條件

這很像把 policy enforcement 與 audit trail 黏在一起。重要的不是只知道 action 有沒有被放行，而是能在事後回答：

• 它當時聲稱自己遵守的是哪條規範？
• 若判錯，是 parser 錯、mapping 錯、policy 模型錯，還是 enforcement placement 錯？
• 這次違規是 deliberate bypass、理解失敗，還是政策更新沒被 re-consent 接住？

很多團隊今天做的 audit log，其實只是把 tool call、時間戳、成功失敗存下來。這樣對 debugging 有用，對 accountability 不太夠。Anumati 的意思是：如果 agent 真要替人承擔政策義務，log 裡就不能只看得到它做了什麼，還要看得到它宣稱自己依什麼規則做。

這篇真正補的是哪個缺口？OAuth / mTLS 為什麼不夠？

這篇反覆強調，OAuth、OIDC、mTLS 這些並不是錯；它們只是回答錯誤類型的問題。它們擅長處理：

• 身份
• 授權
• scope
• capability access

但它們不擅長處理：

• 版本化 usage policy
• 逐條義務與條件
• 政策變更後的再同意
• 行動時的 clause-level compliance record
• 事後可審計的 adherence trail

這點其實和最近一整串 agentic security 論文的共識很一致：很多風險不是因為我們完全沒有 control，而是因為現有 control 放錯層。 OAuth 很適合保 capability boundary，但如果你拿它去承擔 usage governance，它就會像拿 firewall 規則去處理企業內控流程——不是完全沒用，而是永遠差一層語意。

所以這篇的價值，不是推翻既有 authN / authZ，而是提醒大家：agent protocol 若只做到「你能叫誰」，卻沒做到「你在誰的條款下怎麼叫」，那它離成熟的 cross-agent governance 還差很遠。

與 MCP / A2A 的關係：不是重寫協議，而是沿 extension path 補上治理層

我覺得這篇另一個成熟的地方，是它沒有試圖把自己包裝成「新協議取代一切」。作者反而強調，ACAP 是沿著 A2A 與 MCP 現有 extension mechanism 去做非破壞式擴充。

這很重要，因為 protocol proposal 若一上來就要求 ecosystem 全面重寫，通常很難落地。相反地，這篇走的路比較像：

• 核心 transport / auth flow 不動
• 在 caller / callee boundary 補 middleware
• 讓 PolicyDocument、ConsentRecord、AdherenceEvent 掛進現有流程
• 把 enforcement 盡量放在可部署的 integration layer

這種定位讓它比較像一個governance overlay，而不是另一套空中樓閣。對 MCP 生態尤其有意思，因為 MCP 現在很多討論都集中在 tool poisoning、approval、capability mediation、description trust；而這篇補的是更偏雙方條件承諾與後續可追責的那一塊。

簡單講：MCP 幫你把 agent 接上世界，Anumati 則在問，接上世界之後，雙方規則到底怎麼被證明有被讀懂且一路遵守。

形式化與驗證：它不只講制度，也試著把生命周期寫成 state machine

論文還用了 TLA+ 去描述 consent lifecycle，並提到檢查 safety / liveness properties。這件事未必保證整體系統就安全，但它至少釋放出一個訊號：作者不是只把 consent 當治理口號，而是把它視為可形式化的系統狀態轉移問題。

這和最近很多 runtime governance / formal agent security 論文的方向一致：當 agent 已經會長時間代表人做事時，單靠自然語言政策文件加上「請你遵守」其實太薄。你要嘛把某些承諾變成結構化 state，要嘛最後出事時只會剩下一堆模糊的事後辯解。

在這個意義上，Anumati 最值得看的不是 TLA+ 本身，而是背後的觀點：consent 不是 legal decoration，而是 protocol state。 一旦把它當 state，就能談版本、遷移、失效、重簽、鏈完整性與 validator；整個工程味就出來了。

這篇最有啟發性的地方：把「誰負責」這件事釘回系統裡

現在很多 agent 系統最大問題，不是做不到事，而是責任邊界非常糊。出了事常常只剩幾種說法：

• 模型自己理解錯了
• 工具描述寫得不夠清楚
• 系統 prompt 沒交代完整
• 使用者也沒有明講

這些話有時沒錯，但都太容易變成責任煙幕。Anumati 的價值，就是它試圖把這種煙幕拆掉：如果 agent 真的代表 principal 行動，那麼它對外部政策的理解、接受、保留與逐步遵守，就應該變成可查、可驗、可追溯的系統事實。

這不只對法遵或審計有用，對安全工程也有用。因為很多安全事件到最後都卡在 attribution：問題出在 policy ingestion、consent refresh、capability mapping、action-time enforcement，還是 trail integrity？如果沒有這種分層紀錄，你很難真的修到根。

限制也很明顯：它仍然有 self-attestation 與 semantic honesty 問題

當然，這篇不是萬靈丹。它最明顯的限制，是很多 adherence 記錄本質上仍然帶有 self-attestation 色彩。也就是說，agent 可以留下看似漂亮的 reasoning trail，但那不自動等於它真的誠實、真的理解、真的沒有策略性造假。

所以這套東西比較像是：

• 先把 accountability surface 做出來
• 讓 policy 與 action 之間至少有結構化連結
• 讓後續 validator、runtime monitor、external verifier 有東西可查

它不是最終真理機，而是讓「根本查不到」升級成「至少有明確可驗的聲稱與紀錄」。這在工程上已經是很大的進步，但確實還需要搭配更硬的 enforcement、獨立驗證器、甚至 cryptographic attestation，才可能走到更強的 assurance。

另一個限制是政策語意本身。若 policy 寫得過度模糊、充滿開放世界灰區，那就算有 PolicyDocument 與 ConsentRecord，也只是把模糊包成 JSON，不會自動變清楚。這篇比較適合的是那些已經願意把 usage conditions 寫得夠結構化的 agent 生態。

對實務界的意義：從 capability governance 走向 protocol-level usage governance

如果你是做以下幾種東西的人，我覺得這篇很值得看：

• MCP / A2A 平台與 runtime 團隊：你們現在大多守的是 capability 邊界，接下來該補 usage-policy lifecycle。
• 企業內部 agent orchestration 團隊：當 agent 開始調外部 agent / vendor service 時，contractual 與 policy obligations 不能只靠文件與人工流程。
• 做 agent audit / forensics / accountability 的人：這篇提供了一個比一般 tool log 更接近責任歸因的資料模型。
• 做 AI governance 與 compliance 的人：它示範了怎麼把「要有 oversight」往 machine-readable、 versioned、 action-linked 的設計推進。

更直白地說，很多團隊現在以為自己在做 agent governance，其實只是在做 access control。 這篇提醒你，真正困難的不是先讓 agent 能呼叫服務，而是當它開始代表人承諾條件、吃進對方政策、並在這些條件下持續做事時，系統要怎麼留下可信的治理足跡。

我的看法

如果最近一整串 agentic security 論文都在提醒大家：不要只盯 prompt，要看 runtime、tool boundary、policy placement、privilege separation，那 Anumati 則是在補另一個很容易被低估的洞：agent 與 agent 之間，不只需要握手，還需要可驗證的承諾與可追責的履約紀錄。

我自己最喜歡它的地方，是它把 consent 從「法律 UI 上那個 everyone knows nobody reads 的按鈕」拉回真正的系統工程問題。對人類，proof of acceptance 常常已是極限；但對 agent，如果它連逐條理解、逐步評估、逐次留痕都做不到，那它其實還沒準備好替你在別人的規則底下長時間做事。

所以如果要我用一句話總結這篇，我會這樣講：

當 agent 開始自己替你接受別人的條款，真正該被驗證的，就不只是它有沒有權限呼叫，而是它能不能證明自己從簽下去到做下去都還在同一套規則裡。

這篇不一定已經把答案做完，但它確實把問題釘到了對的位置。