中文内容
代理越来越多地代表其最终用户执行操作，无论是选择工具、浏览网页，还是自主调用 MCP 服务器以实现目标。当代理访问的工具、MCP 端点或 Web 资源需要付费时，如果没有交易能力，代理就会陷入停滞。Amazon Bedrock AgentCore payments 与 Coinbase 和 Stripe（Privy）合作发布预览版，使代理能够代表最终用户访问付费资源，以完成任务。
在自主系统背后投入真实资金会带来一系列新的风险。这些风险来自代理在长会话中自主行动、模型的非确定性，以及代理代码与最终用户资金之间更广泛的暴露面。在本文中，我们将介绍这些风险，以及 AgentCore payments 结合了哪些防护措施来逐一应对这些风险。
AgentCore payments 预览版已在美国东部（弗吉尼亚北部）、美国西部（俄勒冈）、欧洲（法兰克福）和亚太地区（悉尼）提供。功能和 API 在正式可用之前可能会发生变化。
在本文中，我们使用以下术语：
- 最终用户：其资金被花费、且代理代表其进行交易的人。
- 开发者：将支付功能集成到其 AI 代理中的 AWS 客户。
- 钱包提供方：Coinbase Developer Platform (CDP) 或 Stripe Privy。
- 嵌入式钱包：由钱包提供方托管、属于最终用户的自托管钱包。
- 支付会话：用于单次代理交互的限定范围支付上下文，具有可配置的预算和存活时间（TTL）。
- 开发者凭证：由钱包提供商签发给开发者的 API 密钥、机密和授权密钥，供 AgentCore payments 用于调用钱包提供商的 API。
在本文中，我们将探讨设计代理式支付系统时出现的几个关键风险，以及如何利用 AgentCore payments 的能力来应对这些风险。
挑战：代理式支付中的安全风险
几个关键风险决定了代理的支付能力必须如何设计。
支出失控
代理是自主且长期运行的。它们代表最终用户做出决策，通常每个会话中会做出许多决策，并且会在没有人在键盘前操作的情况下持续运行。如果没有明确的防护机制，一个被错误提示或遭到攻陷的代理可能会产生失控支出。
大型语言模型（LLMs）也具有非确定性，因此你无法保证模型不会将某个响应误解为支出授权，或因意外重试而重复付款。支出限额必须在模型之外、在基础设施层进行定义和执行。
缺乏最终用户同意和委托
代理现在可以自主进行支付，但最终用户必须保留最终控制权。最终用户决定何时委托支出权限、何时为钱包充值以及何时提取资金。代理必须在明确且限定范围的许可下运行，而不是获得一揽子授权，并且最终用户可以在其选择的时间撤销该许可。
开发者密钥和钱包令牌被攻破
代表最终用户进行交易的代理有两类敏感材料。第一类是 AgentCore payments 用于调用钱包提供商 API 的开发者凭证（API 密钥、密钥和授权密钥）。第二类是最终用户的嵌入式钱包密钥（由钱包提供商以自托管方式持有）。两者都必须避免出现在代理代码中。如果这些凭证以内联方式存储在代理代码或环境变量中，代理一旦被攻破就会泄露它们。代理不应直接处理这些凭证，并且系统为单笔支付签发的凭证应当是短期有效的，并绑定到特定会话。
终端用户支付工具的暴露
终端用户的卡号、卡验证值（CVV）以及其他个人支付详情绝不应进入代理的上下文。能够看到信用卡信息的代理，其暴露面远大于看不到这些信息的代理，支付卡行业（PCI）标准的适用范围也会相应扩大。代理的可见范围应止于“获准从用户拥有的钱包中支出”，不得再进一步。
缺乏可审计性
当出现问题时，例如发生意外扣款、支付被拒，或安全团队、财务团队询问发生了什么，必须有一份完整、可靠的记录，说明代理做了什么、代表谁、受哪些限额约束，以及面向哪家商户。该记录必须自动生成。依赖代理代码自行记录其操作是不够的。
使用 AgentCore 服务和控制措施来应对这些风险
AgentCore payments 与 Amazon Bedrock AgentCore 的其他部分集成，以应对这些挑战。
下图总结了 AgentCore payments 对每笔交易强制执行的护栏措施。
图 1 – 内置护栏保护每一笔代理支付。每项护栏都在基础设施层强制执行，位于代理代码之外。
工具访问的支付限额和策略
每笔交易都在一个支付会话中运行，该会话是针对单个智能体交互的、有作用域的支付上下文。支付会话有两个可配置的上限：以指定货币计价的最大支出金额，以及到期时间。在签署支付之前，AgentCore payments 会根据会话预算检查请求。AgentCore payments 会拒绝那些会导致会话超出其上限的请求。如果在服务已从预算中扣减后签署失败，它会回滚该扣减，因此失败的交易不会消耗预算。
该检查是确定性的，并在基础设施层运行。提示注入无法提高上限，因为该上限是在模型之外强制执行的。开发者会配置与工作负载相匹配的限额，AgentCore payments 则在每次调用时执行这些限额。我们建议从较小的预算开始，并随着智能体在生产环境中证明自身能力而提高预算。
对于工具级授权，我们建议通过 Amazon Bedrock AgentCore Gateway 公开付费端点。通过 AgentCore Gateway 发起的每一次调用都会被 AgentCore 中的 Policy 拦截；Policy 是一个基于 Cedar 的引擎，会评估请求，包括代理的身份、工具名称和参数，并决定是否允许该请求。这两项控制覆盖不同的决策。Policy 决定谁可以调用哪个付费工具以及使用哪些参数。AgentCore payments 决定该调用可以花费多少以及持续多长时间。二者结合，为开发者提供了在工具访问和支出金额方面相互独立的控制手段。
- 有关创建包含预算和 TTL 配置的支付会话的演练，请参阅 Amazon Bedrock AgentCore 开发者指南中的“Creating a payment session”。
- 有关按代理角色和用户组限定工具访问范围的 Cedar 策略示例，请参阅开发者指南中的“Policy in AgentCore”。
用户控制、资金和委托
最终用户先为钱包充值，然后明确授予代理支出权限，顺序如此。充值是带外操作。最终用户在钱包提供商的门户（Coinbase WalletHub 或 Stripe Privy 前端）内完成该操作；在这一流程中，代理没有可用的 API，也无法看到该流程。即使资金已经到账，在最终用户通过钱包提供商的权限原语（Coinbase Spend Permissions 或 Privy Delegated Actions）明确委托该权限之前，代理也没有交易权限。为钱包充值和授权代理是两个独立的决定，均由最终用户在钱包提供商的门户内作出。
钱包本身属于最终用户，无论是 Coinbase Developer Platform（CDP）嵌入式钱包，还是 Stripe Privy 嵌入式钱包。最终用户持有密钥。AWS 不持有，开发者也不持有。最终用户可以自行决定撤销委托。而且，由于钱包归他们所有，他们可以随时将资金提取回其控制的地址。
用于凭证存储的 AgentCore Identity 和 Secrets Manager
AgentCore Identity 在四个层面处理安全性。我们将在以下各节逐一介绍。
1. 使用 IAM 或 SigV4 进行入站身份验证
对于访问 AgentCore payments 的入站访问，开发人员可配置 AWS Identity and Access Management (IAM) 或 SigV4。该服务随附的四角色 IAM 模式将控制平面（用于管理和配置 AgentCore payments 的 API）与数据平面（用于执行交易的 API）分离。
在控制平面上，ControlPlaneRole 管理该服务，ManagementRole 配置支付管理器和会话。ManagementRole 对 ProcessPayment 带有显式 Deny，因此开发人员用于设置支付的凭证不能同时执行交易。
在数据平面上，ProcessPaymentRole 执行支付，服务本身会代入 ResourceRetrievalRole，以在运行时获取会话和凭证状态。没有任何单一角色既能提高预算，又能针对该预算进行支出。
2. 用于调用钱包提供商的开发者凭证
当 AgentCore payments 代表最终用户调用 Coinbase Developer Platform 或 Stripe Privy 时，会使用开发者凭证，例如 Coinbase Developer Platform API 密钥、Stripe Privy 应用凭证以及 Privy 授权密钥。AgentCore Identity 将这些凭证存储在其令牌保险库中，并通过 AWS Key Management Service（AWS KMS）对静态和传输中的凭证进行加密。该保险库与 AWS Secrets Manager 原生集成，因此开发者可以通过其安全团队已经使用的工具来管理轮换和访问策略。Agent 代码不会直接处理这些开发者凭证。
3. 最终用户钱包地址保留在钱包提供商处
与上一节中的开发者凭证不同，每个最终用户都有一个嵌入式钱包（Coinbase Developer Platform 钱包或 Stripe Privy 钱包），并拥有自己的自托管钱包地址。该钱包地址以及控制它的密钥由最终用户和钱包提供商保管，AWS 和开发者都不会持有。AgentCore payments 通过句柄而不是密钥来引用该钱包。
4. 每笔支付的即时令牌
当 AgentCore payments 需要执行支付时，它会通过 GetResourcePaymentToken API 向 Identity 请求一个限定范围的令牌。该令牌在运行时签发，绑定到支付会话，并且仅用于这一项操作。不存在长期开放的支付通道。会话的 TTL 或预算耗尽后，运行时会拒绝进一步交易，而用于调用钱包提供商的令牌仅在操作需要的时间内存在。
带外充值使代理远离敏感数据
当最终用户为其钱包充值时，他们会在钱包提供商托管的入金通道中输入信用卡、借记卡或银行详细信息，该通道可以是 Coinbase WalletHub 或 Stripe Privy 前端。这些界面由钱包提供商运营并纳入 PCI 范围。代理无法通过 API 访问它们，也没有对它们的 UI 访问权限。卡号、有效期、CVV 或自动清算所（ACH）详细信息不会接触到代理代码、代理的提示上下文，或开发者运营的 AWS 服务。
这种隔离很重要，因为它限定了影响范围。一个因提示注入、受污染的工具响应或模型异常行为而被攻陷的代理，无法从它一开始就无权访问的系统中提取银行卡号。PCI 负担仍由钱包提供商承担。该代理所操作的唯一内容，是一项有范围、可撤销的权限，用于从最终用户的嵌入式钱包中支出稳定币或法定货币；即便该权限也受到上一节所述会话限制的约束。
从合规角度看，这种设计让开发者能够交付代理式支付流程，而不会将自己的系统纳入 PCI 范围。代理的暴露面以及开发者的合规范围都被有意保持在较小范围内。AWS 本身不参与资金流，因为资金是通过钱包提供商的基础设施，在最终用户的嵌入式钱包与商户之间流转。
通过 AgentCore Observability 获得端到端洞察
AgentCore payments 与 AgentCore Observability 集成，为开发者提供支付生命周期的可见性。该服务会针对每一次数据平面 API 调用，自动将供应日志发送到您的 Amazon CloudWatch 日志组，并将供应跨度发送到 AWS X-Ray。
每次 ProcessPayment 调用，无论是成功、达到预算限制，还是在钱包层失败，都会被记录足够详细的信息，以便在不复现问题的情况下进行诊断。开发人员可以监控交易成功率，跟踪各个代理的支出模式，并在错误发生时将其呈现出来。
支付追踪使用开发人员已经依赖的同一套可观测性基础设施来观察代理行为。支付活动会与工具调用、模型调用和编排步骤一起显示在同一条时间线中。运维团队可以针对错误率或支出速度设置 CloudWatch 警报，以便及早发现异常。
AgentCore Observability 包含预构建的仪表板，可展示跨代理、会话和时间段的端到端交易健康状况。由于支付遥测数据也会流入 CloudWatch 和 X-Ray，开发人员可以构建自己的仪表板。单个 CloudWatch 仪表板可以呈现按代理统计的总支出、按原因分类的拒绝率（预算耗尽、策略拒绝、凭证过期）以及支付延迟百分位数。这为财务、安全和合规团队提供了所需的可审计性，而无需构建自定义报告基础设施。
结论
借助 AgentCore payments：
- 该代理无法访问最终用户的资金或支付工具。
- IAM 和 SigV4 会对每一次入站调用强制执行授权，而四角色模式将控制平面（配置支付）与数据平面（执行支付）分离，因此没有任何单一角色既能提高预算，又能使用该预算进行支出。
- 每个会话的支出限额和 TTL 在基础设施层被强制执行——以确定性方式在代理代码之外执行——因此提示注入无法提高这些限制。
- 最终用户保留对其嵌入式钱包的托管权，按照自己的条件委托支出，并可随时撤销或提取。
- 钱包凭证存放在由 AWS KMS 加密的令牌保险库中，并且仅以即时签发的短期、会话范围令牌形式到达代理。
- AgentCore Observability 可以自动将每笔交易发送到 Amazon CloudWatch 和 AWS X-Ray，为安全和财务团队提供完整的审计跟踪。
- 资金通过钱包提供商的基础设施在最终用户的嵌入式钱包和商户之间流转，而不是通过 AWS。
有了这些防护措施，代理式支付成为一种受管理的能力，具备边界约束、可审计性，并已可用于生产环境。
要了解更多信息，请访问 Amazon Bedrock AgentCore 产品页面并阅读发布公告。有关代理式商务模式的技术深入解析，请参阅《技术深度解析：AgentCore Payments 与代理式商务创新》。
关于作者
