Amazon Bedrock AgentCore内置护栏：智能体支付安全评测

当AI袋里开始自主调用工具、浏览网页，甚至调用MCP服务器来完成一个目标时，一个现实问题就摆在了面前：如果它访问的付费资源需要真金白银，它该怎么办？在一次性的API调用里还好说，但面对需要长时间、多步骤执行的复杂任务，袋里往往会卡在“没钱”这一步。

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。

核心挑战：袋里支付中的安全风险

设计一个面向袋里的支付系统，必须直面几个核心安全风险。

风险一：失控的“无底洞”消费

袋里是自主且长时间运行的。它代表用户做决策，往往一次会话中就有很多决策，而且整个过程没人盯着键盘。如果没有明确的护栏，一个被错误提示或攻破的袋里，就可能造成无限的资金消耗。

更要命的是，大语言模型（LLM）是非确定性的。你无法保证模型不会把某次响应误解为授权消费，或者因为一次意外的重试而重复支付。因此，消费限额必须定义并强制执行在模型之外的基础设施层，这是底线。

风险二：用户授权与委托的缺失

虽然袋里可以自主支付，但最终用户必须保留最终控制权。谁来决定何时授权消费？何时充值？何时变钱？答案是用户自己。袋里必须在明确、有范围的许可下操作，而不是一个笼统的授权，并且用户随时可以收回这个许可。

风险三：开发者密钥与钱&包令牌的泄露

一个代表用户交易的袋里，手里握着两种敏感材料。一种是AgentCore Payments用来调用钱&包提供商API的开发者凭证（API密钥、秘密等）。另一种是最终用户的嵌入式钱&包密钥（由钱&包提供商自托管）。这两样东西都必须远离袋里的代码。如果凭证直接写在代码或环境变量里，一旦袋里被攻破，这些信息就一览无余。原则是，袋里不应该直接处理这些凭证，系统为单次支付颁发的凭证也必须是短生命周期的，并且绑定到特定会话。

风险四：用户支付工具的暴露

用户的信用卡号、CVV等个人支付信息，永远不应该进入袋里的上下文。一个能看见信用卡信息的袋里，其暴露面远大于看不见的，并且PCI合规的覆盖范围也会相应扩大。袋里的视野应该止步于“拥有一笔来自用户钱&包的消费许可”，不能再多了。

风险五：不可审计的“糊涂账”

一旦出了问题——比如出现意外扣款、支付被拒绝，或者安全、财务团队需要追查——必须有一个完整的、可靠的记录，清楚说明袋里做了什么、代表谁、在哪个限额内、向哪个商家付了款。这个记录必须自动生成。指望袋里代码自己去记录日志，远远不够。

用AgentCore构建安全支付体系

AgentCore Payments通过与Amazon Bedrock AgentCore的其他组件集成，来应对上述挑战。下面这张图总结了它在每笔交易中强制执行的防护栏。

图1 – 内置的防护栏保护着每一笔袋里支付。每条防护栏都在基础设施层，而非袋里代码内执行。

支付限额与工具访问策略

每笔交易都运行在一个“支付会话”中。这个会话有两个可配置的上限：一个是指定货币下的最大消费金额，另一个是到期时间。在签名支付之前，AgentCore Payments会检查请求是否符合会话预算，任何超出上限的请求都会被拒绝。即使签名失败后服务已经扣除了预算，它也会自动回滚，确保失败的交易不占用预算。

这个检查是确定性的，在基础设施层运行。提示注入无法绕过这个限额，因为限额是在模型之外强制执行的。开发者可以根据工作负载配置限额，AgentCore Payments会在每次调用时强制执行。建议从小预算开始，等袋里在生产环境中运行稳定后再逐步提高。

对于工具级别的授权，建议通过Amazon Bedrock AgentCore Gateway暴露付费端点。每个经过Gateway的调用都会被AgentCore中的策略引擎（基于Cedar）拦截，评估请求中的袋里身份、工具名称和参数，决定是否放行。这两个控制机制覆盖了不同层面：策略决定谁能调用哪个付费工具、用什么参数；AgentCore Payments决定这次调用能花多少钱、花多久。两者结合，为开发者提供了工具访问和消费金额两个正交的杠杆。

• 创建支付会话的详细步骤，可参考Amazon Bedrock AgentCore开发者指南中“创建支付会话”部分。
• 按袋里角色和用户组限制工具访问的Cedar策略示例，可参见开发者指南中的“AgentCore策略”部分。

用户控制、资金与委托

流程是清晰的：最终用户先为钱&包充值，再明确授予袋里消费许可，顺序不可颠倒。充值是一个带外交互过程。用户在钱&包提供商的门户（Coinbase WalletHub或Stripe Privy前端）中完成，这个流程袋里既没有API接入，也看不到内部细节。即使钱到账了，在用户通过钱&包提供商的权限原语（Coinbase的“消费许可”或Privy的“委托操作”）明确授权之前，袋里没有任何交易权限。充值和授权，是用户在钱&包提供商门户里做出的两个独立决定。

钱&包本身属于用户（无论是CDP还是Stripe Privy的嵌入式钱&包）。用户掌握密钥，AWS和开发者都不持有。用户可以随时撤销委托。而且，因为钱&包是用户的，他们可以随时把资金提回到自己控制的地址。

凭证管理的四层安全体系

AgentCore Identity在四个层面处理安全问题。

1. 入站认证：IAM或SigV4
开发者通过配置AWS Identity and Access Management (IAM)或SigV4来控制对AgentCore Payments的入站访问。服务自带的四角色IAM模式，将控制面（管理配置AgentCore Payments的API）与数据面（执行交易的API）分离开来。

控制面中，ControlPlaneRole负责管理服务，ManagementRole配置支付管理器和会话。ManagementRole被明确拒绝执行ProcessPayment操作，确保用于配置支付的凭证无法同时执行交易。数据面中，ProcessPaymentRole执行支付，而服务本身会扮演ResourceRetrievalRole来在运行时获取会话和凭证状态。这样一来，没有任何一个角色能同时提高预算并消费。

2. 调用钱&包提供商的开发者凭证
当AgentCore Payments代表用户调用Coinbase或Stripe Privy时，使用的是开发者凭证。AgentCore Identity将这些凭证（如API密钥、应用凭证、授权密钥等）存储在其令牌保险库中，并使用AWS KMS进行静态和传输加密。这个保险库原生集成了AWS Secrets Manager，开发者可以用自己安全团队熟悉的工具来管理凭证轮换和访问策略。重要的是，袋里代码本身不直接处理这些凭证。

3. 用户钱&包地址
与上述开发者凭证不同，每个用户都有一个属于自己的嵌入式钱&包，包含自托管的钱&包地址。这个地址和控制它的密钥，始终由用户和钱&包提供商掌握，AWS和开发者从不持有。AgentCore Payments通过“句柄”而非密钥来引用钱&包。

4. 即时（JIT）令牌
当AgentCore Payments需要执行一笔支付时，它会通过GetResourcePaymentToken API向Identity请求一个作用域受限的令牌。这个令牌是运行时颁发的，绑定到支付会话，并且只用于这一次操作。不存在长期有效的开放支付通道。一旦会话的TTL或预算耗尽，运行时就会拒绝后续交易。用于调用钱&包提供商的令牌，只在操作需要的时间内存在。

带外交互充值的隔离优势

当用户为钱&包充值时，他们是在钱&包提供商托管的入口（Coinbase WalletHub或Stripe Privy前端）输入信用卡、借记卡或银&行账户信息。这些界面由钱&包提供商运营并纳入PCI合规范围。袋里对此既没有API接口，也没有UI访问权限。信用卡号、有效期、CVV或ACH信息，完全不会触及袋里代码、袋里的提示词上下文，或开发者运营的任何AWS服务。

这种隔离至关重要，因为它限制了风险半径。一个通过提示注入、有毒的工具响应或模型异常行为而被攻破的袋里，无法从一个它根本访问不到的系统中提取信用卡号。PCI合规的责任由钱&包提供商承担。袋里操作的唯一东西，是一个有作用域、可撤销的、允许从用户嵌入式钱&包中消费稳定币或法币的许可——而这个许可本身还受到支付会话限额的约束。

从合规角度看，这种设计让开发者可以在不把自有系统纳入PCI范围的前提下，实现袋里支付流程。袋里的表面区域，以及开发者的合规范围，都非常小。AWS本身也不涉及资金流，资金通过钱&包提供商的基础设施，在用户的嵌入式钱&包和商家之间直接流动。

端到端可观测性

AgentCore Payments与AgentCore Observability集成，为开发者提供支付生命周期的可见性。服务会自动将托管的日志发送到CloudWatch日志组，并为每次数据面API调用将托管跨度发送到AWS X-Ray。

每次ProcessPayment调用——无论成功、触发预算限制还是在钱&包层失败——都会被详细记录，足以诊断问题而无需重现。开发者可以监控交易成功率、追踪不同袋里的消费模式，并在错误发生时立即发现。

支付追踪使用的是开发者已习惯的同一套可观测性基础设施。支付活动会与工具调用、模型请求和编排步骤出现在同一个时间线上。运维团队可以针对错误率或消费速度设置CloudWatch告警，提前发现异常。

AgentCore Observability包含预建仪表盘，可以展示跨袋里、跨会话、跨时段的端到端交易健康状况。由于支付遥测数据也流入CloudWatch和X-Ray，开发者可以构建自己的仪表盘。一个CloudWatch仪表盘就能汇总各袋里的总消费、按原因（预算耗尽、策略拒绝、凭证过期）区分的拒绝率以及支付延迟百分位。这为财务、安全和合规团队提供了所需的审计能力，而无需构建自定义报告基础架构。

总结

总的来说，AgentCore Payments的设计体现了几个核心理念：

• 袋里无法接触最终用户的资金或支付工具。
• IAM和SigV4对每次入站调用强制执行授权，四角色模式确保配置支付的角色和执行支付的角色完全分离，无人能既提高预算又消费。
• 每次会话的消费限额和TTL在基础设施层，以确定性的方式强制执行，杜绝提示注入绕过的可能。
• 最终用户始终保管自己的嵌入式钱&包，按自己的意愿委托消费，并随时可以撤销或变钱。
• 钱&包凭证存放在AWS KMS加密的令牌保险库中，袋里仅能通过即时颁发的、短生命周期的、会话绑定的令牌访问。
• AgentCore Observability会自动将每笔交易记录到CloudWatch和X-Ray，为安全和财务团队提供完整的审计追踪。
• 资金流经钱&包提供商的基础设施，在用户嵌入式钱&包和商家之间直接结算，AWS不参与其中。

有了这些内置防护栏，袋里支付就成为了一项可管理、有边界、可审计且生产就绪的能力。

更多详情，欢迎访问Amazon Bedrock AgentCore产品页面，或阅读发布公告。对袋里商务模式的技术深入探讨，可参考相关技术文章。

来源：互联网