Solv Labs在AWS Bedrock上构建可审计的Agent支付系统

This post is co-written with Patrick Duffy from Solv Labs and Houman Shadab from ICME Labs

Solv Labs 使用 Amazon Bedrock AgentCore payments 构建了一套 AI agent 支付工作流，受两层机制治理：ORACLE（Solv 的策略引擎）和 ICME PreFlight 合规验证层。AgentCore payments 提供支付处理基础设施。ORACLE 在每笔交易前执行授权策略。ICME 的验证层将 AWS Automated Reasoning Checks 扩展为隐私保护、可移植且可独立核查的形式，每项决策均可核查。

因此，每笔 agent 支付均经由三个核心治理组件：ORACLE 负责交易前授权决策、运行于 AWS Nitro Enclave 的完整性服务、以及针对每笔交易定价的风险引擎。每笔交易在四秒内完成，覆盖交易前授权、治理、和通过 Coinbase 完成的链上结算。每笔交易都产生完整的审计跟踪，且完全在 agent 型工作负载的延迟预算范围内。

当一个自主 agent 首次代表企业转移真实资金时，问题不再是"它生效了吗？"而是"我们能证明刚才发生了什么？"在一个季度内，四项使该问题可回答的基础设施同时出现：Amazon Bedrock AgentCore payments、AWS Automated Reasoning Checks、作为每笔交易证明者的 AWS Nitro Enclaves，以及用于 agent 向服务支付的 x402 支付标准。

Amazon 于 2026 年 5 月推出了 Amazon Bedrock AgentCore payments，由 Amazon 与 Coinbase 和 Stripe 合作构建。它让 AI agent 能够即时访问并支付其所使用的资源，包括网页内容、API、MCP 服务器和其他 agent。支出受开发者已用于运营 agent 的相同控制机制治理。

在本文中，Solv Labs 与策略验证合作伙伴 ICME 将介绍我们如何在 AgentCore payments 上构建 agent 支付工作流，其中每笔交易在执行时均受治理、在 AWS Nitro Enclave 内进行证明、单独进行风险定价、且完全可审计。我们还将探讨此模式为在受监管环境中运行 agent 的企业解锁了什么。

The enterprise challenge

当一个自主系统转移资金时，运营者必须向审计人员、交易对手和法律证明：每笔支付都经过了授权、针对其所携带的风险进行了定价、并以经得起审查的方式记录。一个配置错误或被操纵的 agent 不仅会返回一个错误的答案——它会转移资金。而困难的部分不是执行支付，而是事后证明该支付原本就是被允许的。

企业团队始终面临同样的差距：当一笔 agent 交易完成时，没有持久记录将该特定行为与其授权策略、满足的约束条件或携带的风险绑定在一起。模型卡、SOC 2 报告和事后审查描述的是系统周围的组织，而不是个别决策的执行。没有这种交易级绑定，运营者无法干净利落地解决争议、满足审计人员、或将常规 agent 行为与被破坏的行为区分开来。

Solv Labs 需要让每个 agent 行为都可验证、可风险定价、并可按需审计，但不能因此拖慢 agent 的速度或在现有系统外部额外拼接基础设施。

这一愿景很直接：在执行时治理每个 agent 支付，并生成各类相关方（审计人员、交易对手、监管机构）可以独立验证的记录，而不依赖于运营者的一面之词。

这一愿景直到最近才变得可行：AgentCore payments 作为支付编排层、Automated Reasoning Checks（ARc）用于正式策略评估、Nitro Enclaves 用于硬件证明、x402 在 agent 支付中得到广泛采用。它们共同将使受治理的 agent 支付从研究项目变成了一个实现选择。

该工作流作为一组专业组件运行：运行于 Solv 运营环境中的 AgentCore payments、配备 Nitro Enclave 证明者的 ORACLE 引擎、以及作为外部服务的 ICME 策略检查。组件之间仅通过签名和哈希绑定的制品跨越信任边界，因此证据流无论服务如何部署都保持完整。该工作流附加到一个基于 Amazon Bedrock AgentCore 构建的 agent，并兼容运行在 AgentCore runtime 或自定义 AgentCore 实现上的 agent。

每笔支付都经由五个专业组件，每个组件解决治理问题的不同部分。

ORACLE – 交易前授权。 ORACLE 在资金流动之前评估拟议行为是否适用相关策略并返回 ALLOW 或 REVIEW 判定，因此策略失败不会产生需要运营者回滚的已结算交易。

PreFlight – 独立可验证的策略检查。 ICME 的 PreFlight 提供支撑 ORACLE 决策的策略检查。它生成该检查的一个小型、隐私保护的证明，第三方无需访问策略或交易参数即可验证。

AWS Nitro Enclave – 完整性证明。 一个运行于 Nitro Enclave 中的完整性服务在硬件隔离环境内对执行记录进行签名。证明文档由 Nitro Security Module 生成，将签名密钥绑定到特定的 enclave 镜像测量值（PCR0，PCR1 和 PCR2 也包含在内）。因此，验证者不仅能确认记录是在一个 enclave 内签名的，还能确认是在 Solv Labs 发布的特定 enclave 镜像内签名的。每个行为因此在密码学上被证明并绑定到生成它的 enclave，所以记录不能在事后被静默重写。

风险引擎 – 每笔交易定价。 风险引擎为每笔交易附加一个风险乘数，根据评估的违规信号deterministically 计算，因此治理记录携带的是风险价格而非一刀切的通过标记。该乘数影响下游审查优先级，在适用情况下还影响转移给第三方的风险定价。

支付处理和结算。 AgentCore payments 在执行每笔支付时强制执行每会话支出限额，使交易保持在终端用户授权的预算范围内。然后通过 Coinbase 链上路由完成结算。

这些组件按固定顺序运行：ORACLE 的决策、其独立可验证的证明、硬件证明和每笔交易的风险价格都在结算启动前生成。关卡是绝对的：无决策，不结算。

What the governance layer attests

每笔受治理的支付生成一个单一的签名证据记录，绑定五项内容：被评估的策略、策略检查结果及其独立可验证的证明、硬件证明的执行记录、每笔交易的风险价格、以及来自 AgentCore payments 的结算制品。

它并不证明 agent 的底层决策是明智的、交易对手是有偿付能力的、或策略本身是正确的。这些仍然是运营者的责任，与其他支付方式一样。它所做的证明——以相关方可以验证的方式——是：这笔特定支付是在这些特定约束条件下、针对这个特定策略、按这个特定风险价格进行了评估的，而该评估的结果就是授权结算的内容。

How AgentCore payments closes the governance gap

该服务的三个特性使工作流在运营上干净利落：

原生集成于 agent 系统。 运行在与 agent 相同的 AgentCore 环境中，治理工作流继承了 agent 的身份、网关和可观测面。运营者不需要运行两个并行的控制平面——而这正是大多数治理差距实际出现的配置。

基础设施级支出限额。 AgentCore payments 独立于 agent 或策略引擎的任何决策来强制执行每会话支出限额。纵深防御是内置的，而非组装而成的。

单一可观测面。 每项决策、证明、风险价格和结算都通过标准 AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）在 Amazon CloudWatch 日志、指标和追踪中可见，与 agent 的其他所有行为一起。

Customer perspective: Solv Labs

"在我们构建此工作流之前，我们无法给企业的一个清晰答案是为什么一笔特定支付被允许——只能给出关于授权它的组织的断言。AgentCore payments 让我们将答案移到了交易本身：每笔支付现在都携带它通过的策略、签署它的 enclave、以及第三方可检查的证明。证据随交易同行。"

— Patrick Duffy，CEO，Solv Labs

Customer perspective: ICME

"当支付决策的验证者不是做出该决策的运营者时，你需要一种方式来证明检查正确运行，而不暴露策略本身。这就是 ICME 为 AWS Automated Reasoning Checks 添加的内容：每项决策都带有一个加密证明，交易对手或监管机构可以在不到一秒内验证它，而无需看到策略细节或交易参数。"

— Houman Shadab，联合创始人，ICME Labs

该工作流在 agent 支付交易结算前生成每笔交易的硬件证明、独立可验证的治理记录。在 Amazon Bedrock AgentCore payments 上采用此模式的企业，每笔支付交易都能以机器速度获得以下能力：

可验证的执行。 每个 agent 行为都经过密码学签名，并可针对 Base 网络上的公共锚点独立验证。跨两种决策路径（ALLOW 和 REVIEW）处理的受治理支付均携带相同的证据保证。DENY 路径（在 ORACLE 引擎中完全实现并经过单元测试）在配置约束被违反时生成签名拒绝记录。

风险定价。 每笔交易都携带一个 deterministically 计算的风险乘数，因此治理记录对交易携带的风险进行定价，而非将每笔支付视为相同。风险乘数反映引擎的工作点，随着观察到的执行累积，结果校准也逐步完善。

独立可审计性。 每项治理决策都锚定在公共区块链上，设计用于使用来自 Solv Labs 和 ICME 的参考验证器工具进行第三方验证，而不暴露策略细节、交易参数或私钥。

机器速度的治理。 交易在四秒内完成，覆盖交易前授权、治理、支付处理和通过 Coinbase 的链上结算。治理调用延迟保持在整体交易的延迟预算内。

单一可观测面。 每项决策、证明和风险价格都通过运营者用于监控 agent 其他行为的相同 AgentCore Observability 在 Amazon CloudWatch 日志、指标和追踪中可见。记录的结构设计面向其消费者：风险与合规、内部审计、以及外部审计人员和交易对手，各方都能在无需访问运营者策略细节、交易参数或私钥的情况下进行验证。

What this unlocks for enterprises

每笔交易产生一个干净的审计跟踪，在执行时刻生成而非事后重构：什么被授权了、依据哪个策略、针对哪些约束、什么风险价格、由哪个 enclave 签署、锚定在哪里。

在争议中存活的证据。 当交易对手、审计人员或监管机构问为什么一笔支付被允许时，答案是可验证的制品，而非组织断言。这在受监管环境中最为重要，因为证据保留义务附着于每笔交易。

agent 速度的治理。 亚秒级治理开销意味着企业同时获得控制力和 agent 型工作负载所需的吞吐量。

随异常而非总量扩展的审查工作。 因为每笔交易都携带自己的证据并在结算前通过了策略关卡，审查从对每 N 笔交易抽样变成了调查证据本身标记的异常。监督工作随异常率增长，而非随交易率增长。

符合现有预算线的控制成本。 运行在 AgentCore 原生面上，无需许可、集成或人员配备并行控制平面。治理多一笔支付的边际成本主要由 AgentCore 调用本身决定，证明和锚定作为边际成本叠加在企业已经支付的费用线上，而非一个新的账单项目。

面向未来工作负载的基础。 相同的每笔交易证据模型可扩展到 agent 型工作负载在生产环境中将产生的交易量和多样性。

Solv Labs 将 Amazon Bedrock AgentCore payments 与 ORACLE、PreFlight 和 AWS Nitro Enclave 证明者结合使用，构建了一套受治理的 agent 支付工作流，其中每笔交易都在结算启动前经过策略评估、硬件证明、风险定价、并锚定到公共区块链。对企业而言，这意味着审查工作随异常而非总量扩展、控制成本符合现有预算线、以及审计跟踪可供其风险、合规和审计职能各自验证而无需访问运营者的策略细节、交易参数或私钥。这就是了在受监管环境中部署 agent 支付而无需以速度换控制的所需条件。

To learn more about Amazon Bedrock AgentCore payments, see the Amazon Bedrock AgentCore payments documentation. To explore Solv Labs' governed agent payments, visit Solv Labs. To learn more about ICME's PreFlight, visit ICME.