使用 Amazon Bedrock AgentCore Payments 的內建防護欄實現安全的代理支付

隨著AI代理越來越多地代表終端使用者執行操作，如選擇工具、瀏覽網頁、自主呼叫MCP伺服器等，當這些工具、MCP端點或網路資源需要付費時，代理就會因無法交易而卡住。Amazon Bedrock AgentCore Payments（與Coinbase和Stripe/Privy合作推出預覽版）使代理能夠代表終端使用者訪問付費資源以完成任務。然而，將真實資金置於自主系統背後會帶來一系列新風險，包括代理在長時間會話中自主行動、模型非確定性，以及代理程式碼與使用者資金之間更廣泛的暴露面。

AgentCore Payments 目前在美國東部（弗吉尼亞北部）、美國西部（俄勒岡）、歐洲（法蘭克福）和亞太地區（悉尼）提供預覽版，功能和API在正式釋出前可能會發生變化。

代理支付的安全挑戰

設計代理支付能力時需考慮幾個關鍵風險：

失控支出：代理自主且長時間執行，每會話可能做出多個決策，且無人值守。如果沒有明確防護欄，錯誤的提示或受損的代理可能導致支出失控。大語言模型（LLM）的非確定性也使得無法保證模型不會誤將響應視為授權支出，或因意外重試而重複支付。因此，必須在模型外部、基礎設施層定義並執行支出限制。

缺乏使用者同意與授權：代理可以自主支付，但終端使用者必須保留最終控制權。使用者決定何時授權支出許可權、何時充值錢包、何時提取資金。代理必須基於明確、有範圍的許可權操作，而非全面授權，且使用者可以隨時撤銷許可權。

開發者金鑰和錢包令牌洩露：代表使用者交易的代理涉及兩類敏感材料：一是AgentCore Payments用於呼叫錢包提供者API的開發者憑證（API金鑰、金鑰和授權金鑰）；二是使用者的嵌入式錢包金鑰（由錢包提供者自託管）。兩者都不能存放在代理程式碼中。如果這些憑證內聯儲存於代理程式碼或環境變數，一旦代理被攻破，憑證就會暴露。代理不應直接處理這些憑證，且系統為單次支付頒發的憑證應短有效期並繫結特定會話。

使用者支付工具暴露：使用者的卡號、CVV等個人支付資訊絕不應進入代理上下文。代理能接觸到信用卡會顯著擴大暴露面，並相應擴大PCI標準範圍。代理的視野應僅限於“從使用者擁有的錢包中支出許可權”，不應更進一步。

缺乏可審計性：當出現意外收費、支付被拒或安全/財務團隊需要追責時，必須有完整可靠的記錄，包括代理執行了哪些操作、代表誰、在哪些限制下、向哪個商家。該記錄必須自動生成，僅依賴代理程式碼自我記錄是不夠的。

AgentCore服務與控制措施

AgentCore Payments 與 Amazon Bedrock AgentCore 的其他部分整合來應對這些挑戰。

支付限額與工具訪問策略：每筆交易都在支付會話（為單次代理互動設立的有限支付上下文）中執行。每個會話有兩個可配置上限：以指定貨幣的最大支出金額和過期時間。在簽署支付前，AgentCore Payments 會檢查請求是否超出會話預算，超出則拒絕；如果簽署失敗但已扣除預算，則回滾扣減，因此失敗交易不消耗預算。該檢查是確定性的，在基礎設施層執行，提示注入無法繞過上限，因為上限在模型外部強制實施。開發者可根據工作負載配置限額，AgentCore Payments 在每次呼叫時強制執行。建議從小預算開始，隨著代理在生產中的表現逐步提高。

對於工具級授權，建議透過 Amazon Bedrock AgentCore Gateway 暴露付費端點。透過 Gateway 的每次呼叫都會被 Policy in AgentCore 攔截，該引擎基於 Cedar 策略評估請求（包括代理身份、工具名稱和引數）並決定是否允許。兩種控制覆蓋不同決策：Policy 決定誰可以呼叫哪個付費工具及引數；AgentCore Payments 決定該呼叫可以花費多少及持續多久。兩者共同為開發者提供工具訪問和支出金額的正交控制。

使用者控制、資金與授權：使用者先給錢包充值，然後明確授予代理支出許可權，順序固定。充值是一種帶外操作，使用者在錢包提供者門戶（Coinbase WalletHub 或 Stripe Privy 前端）中完成，代理沒有API或介面可見。即使資金已到位，在使用者透過錢包提供者的許可權原語（Coinbase Spend Permissions 或 Privy Delegated Actions）明確授權之前，代理無權交易。充值和授權是使用者分別在錢包提供者門戶中做出的兩個獨立決定。錢包本身（無論是 Coinbase Developer Platform 嵌入式錢包還是 Stripe Privy 嵌入式錢包）屬於使用者，使用者持有金鑰，AWS和開發者都不持有。使用者可以自行撤銷授權，並隨時將資金提取回自己控制的地址。

AgentCore Identity 與 Secrets Manager 憑證儲存：AgentCore Identity 處理四個層次的安全：

1. 入站認證：開發者配置 IAM 或 SigV4。服務附帶的四角色 IAM 模式將控制平面（管理和配置 AgentCore Payments 的API）與資料平面（執行交易的API）分離。控制平面中 ControlPlaneRole 管理服務，ManagementRole 配置支付管理器和會話，且 ManagementRole 明確拒絕 ProcessPayment，因此用於設定支付的憑證不能同時執行交易。資料平面中 ProcessPaymentRole 執行支付，服務本身承擔 ResourceRetrievalRole 在執行時獲取會話和憑證狀態。沒有單一角色既能提高預算又能支出。

1. 呼叫錢包提供者的開發者憑證：AgentCore Payments 呼叫 Coinbase Developer Platform 或 Stripe Privy 時使用開發者憑證（如 Coinbase Developer Platform API 金鑰、Stripe Privy 應用憑證、Privy 授權金鑰）。AgentCore Identity 將這些憑證儲存在令牌保管庫中，使用 AWS KMS 在靜態和傳輸中加密，並與 AWS Secrets Manager 原生整合，便於開發者使用其安全團隊已有的工具管理輪換和訪問策略。代理程式碼不直接處理這些開發者憑證。

1. 使用者錢包地址保留在錢包提供者處：每個使用者擁有一個嵌入式錢包（Coinbase Developer Platform 錢包或 Stripe Privy 錢包），具有自託管錢包地址。該地址和控制金鑰保留在使用者和錢包提供者處，AWS 和開發者均不持有。AgentCore Payments 透過控制代碼而非金鑰引用錢包。

1. 每次支付的即時令牌：當 AgentCore Payments 需要執行支付時，它透過 GetResourcePaymentToken API 向 Identity 請求作用域令牌。該令牌在執行時頒發，繫結到支付會話，僅用於該次操作。沒有長期開放的支付通道。會話 TTL 或預算耗盡後，執行時拒絕後續交易，且呼叫錢包提供者使用的令牌僅在操作期間存在。

帶外充值使代理遠離敏感資料：使用者充值錢包時，在錢包提供者託管的入口（Coinbase WalletHub 或 Stripe Privy 前端）中輸入信用卡、簽帳金融卡或銀行賬戶詳細資訊。這些介面由錢包提供者運營並承擔 PCI 範圍。代理沒有API或UI訪問許可權。卡號、有效期、CVV 或 ACH 詳細資訊不會觸及代理程式碼、提示上下文或開發者運營的 AWS 服務。這種隔離限制了爆炸半徑：即使代理因提示注入、投毒工具響應或模型誤行為而被攻破，也無法從它本來就沒有許可權訪問的系統提取卡號。PCI 負擔由錢包提供者承擔。代理僅操作一個有範圍、可撤銷的許可權，即從使用者嵌入式錢包中支出穩定幣或法幣的許可權，且該許可權受會話限制約束。從合規角度看，這種設計讓開發者無需將自身系統納入 PCI 範圍即可交付代理支付流程。代理的攻擊面和開發者的合規範圍刻意保持較小。AWS 本身不在資金流中，因為資金在使用者嵌入式錢包和商家之間直接流動。