使用 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 本身不在资金流中，因为资金在用户嵌入式钱包和商家之间直接流动。