Agentic Commerce 安全 SoK 論文閱讀分析：當 agent 開始自己付錢、自己談交易，風險就不再只是 prompt injection

論文基本資訊

• 論文標題：SoK: Security of Autonomous LLM Agents in Agentic Commerce
• 年份：2026
• 來源：arXiv:2604.15367
• 論文連結：https://arxiv.org/abs/2604.15367
• 主題：Agentic Security、Agentic Commerce、Autonomous Payments、Protocol Security、Digital Wallets、Regulatory Compliance

這篇 SoK: Security of Autonomous LLM Agents in Agentic Commerce 很值得接在最近這波 agentic security 論文後面看，因為它把問題從「agent 會不會被 prompt injection」往下一層現實推到底：如果 agent 真的開始自己談價格、自己刷 API、自己付錢、自己控錢包、自己跟別的 agent 做交易，那你原本那套只盯模型輸出的安全觀，基本上已經不夠用了。

這篇最有價值的地方，不是再做一個花俏的 payment demo，而是把今天正在長出來的 agentic commerce stack —— 像是 ERC-8004、AP2、x402、ACP、ERC-8183、MPP —— 全部重新放進同一個威脅框架裡，直接問一個很不舒服但很實際的問題：當 autonomous LLM agent 真的開始拿著支付憑證與資產去世界上做事，安全風險到底會沿著哪些層一路擴散？

這篇論文想處理什麼問題？

作者觀察到，現在的相關研究其實是分裂的：

• LLM security 社群在談 prompt injection、jailbreak、alignment
• 區塊鏈 / DeFi security 社群在談 smart contract、wallet、settlement
• FinTech 社群在談 AI-driven trading 與投資流程
• multi-agent systems 社群在談 agent-mediated commerce 與協商

每一邊都碰到一部分真問題，但幾乎沒有人把它們當成 同一個 autonomous system 來看。可是一個真的上線的 agentic commerce agent，偏偏同時就是：

• 一個會推理的 LLM
• 一個會呼叫工具與協定的 agent
• 一個拿著支付憑證或錢包權限的付款主體
• 一個可能跟其他 agents 協商、互信、競價、結算的市場參與者
• 一個還得面對合規要求的自動化金融行為者

也就是說，只看模型安全，會漏掉交易授權；只看錢包安全，會漏掉 prompt-to-payment 的跨層傳染；只看 protocol correctness，會漏掉 market manipulation 與 compliance exposure。 這篇 SoK 就是在補這個全棧安全視角。

作者怎麼定義「autonomous financial agent」？這點很重要

論文沒有把任何會聊投資的 bot 都算進來，而是刻意把範圍收得很實務。它定義的 autonomous financial agent，至少要同時滿足幾件事：

• 有持久狀態，包含資產、錢包、帳戶或 delegated payment credentials
• 能自己規劃並執行交易或金融操作
• 不需要每筆都有人類批准
• 會跟外部世界互動，例如 blockchain、payment network、exchange、其他 agents

這個切法很乾淨，因為它把真正危險的那批系統圈出來了。很多今天看起來還像 copilot 的東西，一旦跨過「可直接執行交易」與「不需逐筆批准」這條線，風險性質就完全不同。

這篇論文的核心框架：五個安全維度，不再只盯模型本身

作者把 agentic commerce 的安全問題整理成五個維度，我覺得非常準：

• Agent integrity：agent 有沒有被外部內容、工具、供應鏈或推理層帶偏
• Transaction authorization：agent 到底被授權做到哪，誰能限制它、撤銷它、審它
• Inter-agent trust：agent 與 agent 之間如何驗身分、驗承諾、驗履約
• Market manipulation：多 agent 生態會不會被協同操縱、洗量、誘導價格
• Regulatory compliance：當 agent 自己談判、付款、持有資產時，KYC / AML / audit / accountability 怎麼辦

這個分類的好處，是它逼你承認一件事：agentic commerce 不是把 payment protocol 接上 LLM 這麼簡單，而是把模型風險、支付風險、身份風險、市場風險與法遵風險一起綁進同一個 runtime。

作者不只分類，還抽出 12 條 cross-layer attack vectors

這篇最有味道的部分，是它不是只列 threat list，而是往前走到 cross-layer propagation。也就是說，問題不只是某層有洞，而是這個洞會怎麼一路長到另一層造成真實金流或市場傷害。

文中整理出 12 條 cross-layer vectors，像是：

• Prompt-to-Transaction：從 prompt / context 污染一路長成未授權交易
• Tool-to-Transaction：從工具或 MCP 介面被帶偏，一路變成錯誤支付或資產搬移
• Prompt-to-Key：從 prompt 或互動脈絡一路碰到 wallet / credential 洩露
• Supply-to-Integrity：從供應鏈或工具層問題一路污染整體執行可信度
• Agent-to-Market：個別 agent 被操縱後，進一步放大成價格或市場結構層面的傷害
• Negotiation-to-Compliance：agent 協商與交易流程一路踩進監管與責任界線

這種 cross-layer 看法非常重要。因為今天很多團隊還在用元件式思維看風險：prompt injection 是模型組的事、wallet 是鏈上組的事、合規是法務的事。但 autonomous commerce 真正可怕的地方，恰好就是這些層會在一次任務裡被 agent 串成同一條行動鏈。

為什麼這篇特別強調 payment protocols？因為「可付款」本身就在改寫風險級別

這篇論文把幾個新協定放在一起看：ERC-8004、AP2、x402、ACP、ERC-8183、MPP。作者不是說這些協定不該存在，而是提醒：它們在「有人操作」時可接受的設計假設，到了 autonomous setting 可能會突然變危險。

例如在人類手動交易的場景，你可以說：

• 先讓 agent 拿到 payment intent，再人工確認
• 有異常再回頭追 log
• 協商內容有爭議時人工仲裁

但如果 agent 是自動執行，甚至在 HTTP 402、API call、MCP tool invocation、smart contract settlement 之間一路無人接手，那風險焦點就變了：

• 授權是否真的 task-scoped？
• 付款憑證是否可被重放、誤用、升權？
• 交易前的 intent 與交易後的 settlement 是否可驗證對齊？
• evaluator / escrow / receipt 這些中介角色自己有沒有成為新攻擊面？

這也是為什麼我覺得這篇和前陣子的 x402、授權控制、runtime governance 類論文很能互相對照。它補上的不是某一協定的細節，而是：一旦 agent 會自主付款，authorization 不能只是一個 API token 問題，而要變成一整層系統設計。

OpenClaw 在這篇裡很關鍵，因為它代表的是「agent-as-wallet-holder」模式

論文多次拿 OpenClaw / Clawdbot 這類能直接連到區塊鏈與錢包權限的系統當例子。這其實很有代表性，因為它凸顯了一個時代切換：agent 不再只是幫人讀資訊，而是真的拿著可支配資產進場。

當系統從「分析後給建議」跨到「可直接簽章、付款、調工具、執行交易」，很多原本還能被人類最後一道核准擋住的風險，就會被 runtime 自動化吞掉。這也是作者把 autonomy levels 分成幾級的原因：Level 2 / Level 3 的 delegated / fully autonomous agents，面對的不是單純更高效率，而是質變後的授權與責任問題。

這篇最值得記住的洞見：agentic commerce 的失敗，常常不是單點漏洞，而是 failure propagation

我最認同這篇的一點，是它一直在講 propagation。例如：

• 推理層被 prompt injection 帶偏 → 錯誤地理解支付任務 → 合法調用支付協定 → 真金白銀結算
• 工具層或 MCP metadata 被污染 → agent 調錯市場資料或錯誤工具 → 下錯單或做出錯誤對價判斷
• inter-agent trust 設計不良 → evaluator 被操縱或 collusion → escrow / settlement 被不當釋放
• 身份與授權邊界不清 → delegated credential 被濫用 → 最後變成 custody loss 或 audit failure

換句話說，今天真正該問的不是「模型安不安全」，而是「一個 reasoning failure 會不會被你的 payment / settlement / market stack 放大成不可逆財務後果」。 這是完全不同的安全哲學。

這篇不是純威脅文，也有清楚的 defense architecture

作者不是只列 12 條可怕路徑，還提出一個分層防禦框架。重點大致包括：

• prompt hardening：避免任務理解與上下文被太輕易帶偏
• payment authorization：把 agent 能花的錢、能做的事、能碰的資產收成真正可執法的政策
• tool provenance：確認工具、協定、外部服務與回傳結果的來源與完整性
• decentralized identity / identity controls：讓 agent 身分、角色、權限、可撤銷性更可驗證
• market-level safeguards：不要把風險只當單一 agent 問題，還要考慮整體市場結構與操縱面

這套設計其實很合理，因為它承認：agentic commerce 不可能只靠一個 super-guard model 解決。 你得同時補 reasoning、execution、identity、settlement、market structure 這幾層。少一層，風險就會從那裡滲出去。

對實務世界最大的提醒：不要把付款能力接上 agent，卻還用「聊天助理」的威脅模型在管它

我覺得這篇最實用的提醒，是給所有正在把 agent 接去支付、訂閱、採購、鏈上操作、商務協商的人：一旦 agent 有 capability 去承諾價值交換，它就不是普通 assistant，而是半個 financial actor。

這表示你不能只做這些表層措施：

• 多寫幾句 system prompt
• 裝一層 jailbreak filter
• 覺得 API key 放保險箱就夠了

真正該補的是：

• 可驗證的 task-scoped authorization
• 高風險支付與資產轉移的 deterministic constraints
• 對 evaluator、escrow、receipt、identity 的完整威脅建模
• 能把行為一路追回去的 auditability 與 accountability
• 市場與合規層面的 kill switch / override / dispute handling

不然你只是把一個會被內容帶偏的 agent，直接接上了不可逆的價值流。

總結

SoK: Security of Autonomous LLM Agents in Agentic Commerce 真正補上的，不是某個 payment protocol 的規格細節，而是整個 agentic commerce 時代該怎麼重新看安全邊界。它把問題講得很明白：當 agent 開始自己持有憑證、自己談判、自己付款、自己結算時，風險就不再只是 prompt injection 或工具污染，而是 reasoning、authorization、identity、market、compliance 五層一起連動。

如果要我用一句話總結這篇，我會說：真正危險的不是 agent 會不會花錢，而是你還沒把它當成一個會自己承擔、放大並傳染金融風險的行動主體。

對正在把 agent 接到 API 付費、MCP 工具付費、鏈上錢包、agent-to-agent commerce 的團隊來說，這篇很值得當作上線前的 threat-model 骨架。因為到了這個階段，守不住的已經不只是聊天品質，而是整條 value flow。本文由 AI 產生、整理與撰寫。