放心支付:Solv Labs 如何基于 Amazon Bedrock AgentCore payments 构建可验证、可审计的 Agent 支付
英文标题:Pay with confidence: How Solv Labs built verifiable, auditable agent payments on Amazon Bedrock AgentCore payments
Solv Labs 联合 ICME Labs 在 Amazon Bedrock AgentCore payments 上构建了一套受治理的 Agent 支付工作流,通过 ORACLE 策略引擎、ICME PreFlight 验证、AWS Nitro Enclave 硬件证明和逐笔风险定价控制每一笔交易。该方案要求支付结算前完成预授权、可独立验证的策略证明、硬件完整性证明和风险乘数计算,并将证据锚定至公共区块链。端到端单笔交易耗时不足四秒,其中治理开销不足一秒,同时保留完整、可供审计方和交易对手独立验证的证据记录。对企业开发者而言,这一模式将 Agent 支付的治理从事后审查转为执行时控制,尤其适用于监管要求严格的业务场景。
1.3 MB
101.1 KB
124.1 KB
345.0 KB
141.2 KB
346.5 KB
25.3 KB
24.3 KB
264.3 KB
27.2 KB
1.7 MB
170.5 KB
1.9 MB
3.0 KB
411.9 KB
2.7 MB
215.7 KB
中文
本文由 Solv Labs 的 Patrick Duffy 与 ICME Labs 的 Houman Shadab 共同撰写
Solv Labs 使用 Amazon Bedrock AgentCore 的一项功能 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,该服务与 Coinbase 和 Stripe 合作构建。它让 AI Agent 能够即时访问并支付其所使用的资源,包括网页内容、API、MCP 服务器以及其他 Agent。支出受到开发者用于运营 Agent 的同一套控制机制治理。
本文中,Solv Labs 与策略验证合作伙伴 ICME 将介绍我们如何在 AgentCore payments 上构建 Agent 支付工作流:每笔交易均在执行时受到治理、在 AWS Nitro Enclave 内获得证明、按单笔交易进行风险定价,并且可被完整审计。我们还将说明,这一模式为在受监管环境中运行 Agent 的企业带来了什么。
企业面临的挑战
当一个自主系统划转资金时,运营方必须向审计人员、交易对手和法务证明:每笔付款均已获得授权、已按其所承载的风险定价,并以经得起审查的方式记录。配置错误或遭操纵的 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。

图 1:系统架构。每笔 Agent 支付均在结算前经过预授权、约束验证、完整性证明和风险定价,且全部原生集成于 AgentCore。
每笔支付都会经过五个专用组件,每个组件分别处理治理问题中的不同部分。
- 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,故记录无法在事后被悄然重写。
- 风险引擎 — 逐笔交易定价。 风险引擎为每笔交易附加风险乘数,该乘数根据已评估的违规信号确定性地计算,因此治理记录携带的是风险价格,而非简单的统一通过结果。该乘数为下游审核优先级排序提供依据,并在适用时用于为转移给第三方的风险定价。
- 支付处理与结算。 AgentCore payments 在执行每笔付款时强制实施每个会话的支出限额,使交易保持在最终用户已授权的预算内。随后,结算通过 Coinbase 的链上路由完成。
这些组件按照固定顺序运行:ORACLE 的决策、其可独立验证的证明、硬件证明以及逐笔交易风险价格,均在启动结算前生成。该门控机制是绝对的:没有决策,就没有结算。

图 2:交易时序。步骤 1–3 会在启动结算前生成治理记录,该门控机制强制执行“没有决策,就没有结算”。每笔交易端到端延迟不足四秒,治理开销不足一秒。
治理层所证明的内容
每笔受治理的支付都会生成一条统一的已签名证据记录,绑定五项内容:被评估的策略、策略检查结果及其可独立验证的证明、经硬件证明的执行记录、逐笔交易风险价格,以及来自 AgentCore payments 的结算工件。
它并不证明 Agent 的底层决策是否明智、交易对手是否具备偿付能力,或策略本身是否正确。与其他支付一样,这些仍是运营方的责任。它所能以各方可验证的方式证明的是:这笔特定支付是在这些特定约束条件下,依据这项特定策略并以这一特定风险价格进行评估;而该评估结果正是授权结算的依据。

图 3:逐笔交易证据记录,包括执行与策略哈希、约束结果、零知识证明引用、硬件证明摘要、风险乘数和链上锚点。哈希值和标识符均为说明性占位符。完整记录经过规范化处理,在 Nitro Enclave 内使用 Ed25519 签名,并锚定至链上。
AgentCore payments 如何弥合治理缺口
该服务的三项特性使工作流在运营层面更加清晰:
- 原生集成于 Agent 系统。 治理工作流运行于与 Agent 相同的 AgentCore 环境中,因此继承 Agent 的身份、网关和可观测性界面。运营方无需运行两个并行控制平面——而这恰恰是实践中大多数治理缺口出现的配置。
- 基础设施级支出限额。 AgentCore payments 独立于 Agent 或策略引擎的任何决策,强制执行每个会话的支出限额。纵深防御是内置的,而非后期拼装的。
- 统一的可观测性界面。 每项决策、证明、风险价格和结算,都会通过 Amazon Bedrock AgentCore 的一项功能 AgentCore Observability,在 Amazon CloudWatch 日志、指标和追踪中呈现,并与 Agent 执行的其他所有操作并列可见。
客户视角:Solv Labs
“在构建这套工作流之前,我们无法为企业清晰回答:为什么某一笔特定支付会被允许——我们只能说明授权它的组织作出了哪些声明。AgentCore payments 让我们把这个答案转移到交易本身:每笔支付如今都携带它所通过的策略、为其签名的 Enclave,以及第三方可以核验的证明。证据随交易一同流转。”
— Patrick Duffy,Solv Labs CEO
客户视角:ICME
“当支付决策的验证者并非作出该决策的运营方时,你需要一种方法来证明检查被正确执行,同时又不暴露策略本身。这正是 ICME 为 AWS Automated Reasoning Checks 增加的能力:每项决策都带有密码学证明,交易对手或监管机构无需看到策略细节或交易参数,即可在一秒内完成验证。”
— Houman Shadab,ICME Labs 联合创始人
结果
该工作流会在 Agent 发起的支付交易结算之前,生成逐笔交易、经硬件证明、可独立验证的治理记录。企业在 Amazon Bedrock AgentCore payments 上采用这一模式后,能够以机器速度为每笔支付交易获得以下能力:
- 交易的可验证执行: 每项 Agent 操作均经过密码学签名,并可依据 Base 网络上的公共锚点独立验证。经过治理的支付会通过 ALLOW 和 REVIEW 两种决策路径处理,两种路径均具有相同的证据保障。ORACLE 引擎中已完整实现并经过单元测试的 DENY 路径,会在配置的约束遭违反时生成已签名的拒绝记录。
- 风险定价: 每笔交易均携带确定性计算的风险乘数,因此治理记录会对其承载的风险定价,而不是将每笔支付视为完全相同。风险乘数反映引擎的运行点,随着可观测执行结果不断积累,结果校准也会逐步完善。
- 独立可审计性: 每项治理决策都锚定在公共区块链上,并设计为可通过 Solv Labs 和 ICME 提供的参考验证工具进行第三方验证,且不会暴露策略细节、交易参数或私钥。
- 机器速度下的治理: 交易在四秒内完成,涵盖预授权、治理、支付处理以及通过 Coinbase 进行的链上结算。治理调用延迟保持在整体交易的延迟预算内。
- 统一、可观测的界面: 每项决策、证明和风险价格,均可通过运营方用于监测其余 Agent 行为的同一套 AgentCore Observability,在 Amazon CloudWatch 日志、指标和追踪中查看。记录面向实际使用者进行结构化设计:风险与合规团队、内部审计人员,以及外部审计人员和交易对手均可验证。

图 4:逐笔交易证据栈。四项工件均在结算触发之前生成并一同记录;审计人员、交易对手和监管机构无需访问运营方的策略细节、交易参数或私钥,即可独立验证每个要素。
这为企业解锁了什么
- 每笔交易一条清晰的审计轨迹,在执行时生成,而不是事后重建:授权了什么、依据哪项策略、针对哪些约束、以何种风险价格、由哪个 Enclave 签名,以及锚定在哪里。
- 能够经受争议检验的证据。 当交易对手、审计人员或监管机构询问某笔支付为何被
English / 原文
This post is co-written with Patrick Duffy from Solv Labs and Houman Shadab from ICME Labs
Solv Labs built an AI agent-payments workflow using Amazon Bedrock AgentCore payments, a capability of Amazon Bedrock AgentCore, governed by two layers: ORACLE (Solv’s policy engine) and ICME PreFlight for compliance verification. AgentCore payments provides the payment processing infrastructure. ORACLE enforces authorization policies before each transaction. ICME’s verification layer extends AWS Automated Reasoning Checks to make them privacy-preserving, portable, and independently verifiable, with each decision checkable.
As a result, every agent payment runs through three core governance components: ORACLE for pre-authorization decisions, an integrity service running in an AWS Nitro Enclave, and a risk engine for per-transaction pricing. Each transaction completes in under four seconds, covering pre-authorization, governance, and on-chain settlement through Coinbase. Every transaction produces a full audit trail, and that’s well within latency budgets for agentic workloads.
The first time an autonomous agent moves real money on behalf of an enterprise, the question is no longer “Did it work?” It is “Can we prove what just happened?” In a single quarter, four pieces of infrastructure that make that question answerable arrived together: Amazon Bedrock AgentCore payments, AWS Automated Reasoning Checks, AWS Nitro Enclaves used as a per-transaction attester, and the x402 payment standard for agent payments to services.
Amazon introduced Amazon Bedrock AgentCore payments in May 2026, built in partnership with Coinbase and Stripe. It lets AI agents instantly access and pay for what they use, including web content, APIs, MCP servers, and other agents. Spending is governed by the same controls developers already use to operate their agents.
In this post, Solv Labs and policy-verification partner ICME walk through how we built an agent-payments workflow on AgentCore payments where every transaction is governed at execution time, attested inside an AWS Nitro Enclave, risk-priced individually, and fully auditable. We also cover what this pattern unlocks for enterprises running agents in regulated environments.
The enterprise challenge
When an autonomous system moves money, the operator must prove to auditors, counterparties, and legal that each payment was authorized, priced for the risk it carried, and recorded in a way that holds up to scrutiny. A misconfigured or manipulated agent doesn’t only return a bad answer. It moves money. And the hard part isn’t executing the payment. It’s proving, afterward, that the payment was permitted in the first place.
Enterprise teams consistently struggle with the same gap: when an agent transaction completes, there’s no durable record tying that specific action to the policy that authorized it, the constraints it satisfied, or the risk it carried. Model cards, SOC 2 reports, and after-the-fact reviews describe the organization around the system. They don’t describe the execution of individual decisions. Without that transaction-level binding, operators have no clean way to resolve a dispute, satisfy an auditor, or tell a routine agent action apart from a compromised one.
Solv Labs needed every agent action to be verifiable, risk-priced, and auditable on demand, without slowing agents down or bolting on infrastructure outside the system they already run on.
Vision
The vision is straightforward: govern every agent payment at execution time and produce a record that various parties (auditors, counterparties, regulators) can verify independently without depending on the operator’s word for it.
This became practical only recently, with AgentCore payments as the payment orchestration layer, Automated Reasoning Checks (ARc) for formal policy evaluation, Nitro Enclaves for hardware attestation, and x402 reaching broad adoption for agent payments. Together, they made governed agent payments an implementation choice rather than a research program.
Architecture
The workflow runs as a set of specialized components: AgentCore payments in a Solv-operated environment, the ORACLE engine with its Nitro Enclave attester, and policy checks from ICME as an external service. Components only cross trust boundaries through signed, hash-bound artifacts, so the evidence flow holds regardless of how the services are deployed. The workflow attaches to an agent built on Amazon Bedrock AgentCore and is compatible with agents running on AgentCore runtime or custom AgentCore implementations.

Figure 1: System architecture. Every agent payment passes through pre-authorization, constraint verification, integrity attestation, and risk pricing before settlement, all native to AgentCore
Every payment runs through five specialized components, each addressing a distinct part of the governance problem.
- ORACLE – pre-authorization. ORACLE evaluates the proposed action against the applicable policy and returns an ALLOW or REVIEW determination before values move, so a policy failure doesn’t produce a settled transaction the operator has to unwind.
- PreFlight – independently verifiable policy checks. ICME’s PreFlight provides the policy check underlying ORACLE’s decision. It produces a small, privacy-preserving proof of that check that a third party can verify without access to the policy or the transaction parameters.
- AWS Nitro Enclave – integrity attestation. An integrity service running in a Nitro Enclave signs the execution record inside a hardware-isolated environment. The attestation document, produced by the Nitro Security Module, binds the signing key to the specific enclave image measurements (PCR0, with PCR1 and PCR2 also included). As a result, a verifier can confirm not just that the record was signed inside an enclave, but inside the specific enclave image Solv Labs has published. Each action is therefore cryptographically attested and bound to the enclave that produced it, so the record can’t be silently rewritten after the fact.
- Risk engine – per-transaction pricing. The risk engine attaches a risk multiplier to each transaction, computed deterministically from the assessed violation signal, so the governance record carries a risk price rather than a flat pass. The multiplier informs downstream review prioritization and, where applicable, pricing of risk transferred to a third party.
- Payment processing and settlement. AgentCore payments processes each payment while enforcing per-session spending limits, keeping the transaction within the budget the end user has authorized. Settlement then completes with on-chain routing through Coinbase.
These components run in a fixed order: ORACLE’s decision, its independently verifiable proof, the hardware attestation, and the per-transaction risk price are all produced before settlement is initiated. The gate is absolute: no decision, no settlement.

Figure 2: Transaction sequence. Steps 1–3 produce the governance record before settlement is initiated, and the gate enforces “no decision, no settlement.” End-to-end latency is under four seconds per transaction, with governance overhead under one second
What the governance layer attests
Each governed payment produces a single signed evidence record binding five things: the policy that was evaluated, the policy-check result and its independently verifiable proof, the hardware-attested execution record, the per-transaction risk price, and the settlement artifacts from AgentCore payments.
It doesn’t attest that the agent’s underlying decision was wise, that the counterparty is solvent, or that the policy itself is correct. Those remain the operator’s responsibility, as for other payments. What it does attest, in a way parties can verify, is that this specific payment was evaluated against this specific policy under these specific constraints at this specific risk price, and that the result of that evaluation is what authorized settlement.

Figure 3: Per-transaction evidence record containing execution and policy hashes, constraint result, zero-knowledge proof reference, hardware attestation digests, risk multiplier, and on-chain anchor. Hashes and identifiers are illustrative placeholders. The full record is canonicalized, Ed25519-signed inside the Nitro Enclave, and anchored on-chain
How AgentCore payments closes the governance gap
Three properties of the service make the workflow operationally clean:
- Native to the agent system. Running inside the same AgentCore environment as the agent, the governance workflow inherits the agent’s identity, gateway, and observability surfaces. Operators don’t run two parallel control planes, which is the configuration where most governance gaps appear in practice.
- Infrastructure-level spending limits. AgentCore payments enforces per-session spending limits independently of anything the agent or policy engine decides. Defense in depth is built in, not assembled.
- A single observability surface. Every decision, attestation, risk price, and settlement is visible through standard AgentCore Observability, a capability of Amazon Bedrock AgentCore, on Amazon CloudWatch logs, metrics, and traces, alongside everything else the agent does.
Customer perspective: Solv Labs
“Before we built this workflow, the thing we couldn’t give an enterprise was a clean answer to why a specific payment was permitted — only assertions about the organization that authorized it. AgentCore payments let us move that answer to the transaction itself: every payment now carries the policy it cleared, the enclave that signed it, and the proof a third party can check. The evidence travels with the transaction.”
— Patrick Duffy, CEO, Solv Labs
Customer perspective: ICME
“When the verifier of a payment decision isn’t the operator who made it, you need a way to prove the check ran correctly without exposing the policy itself. That’s what ICME adds to AWS Automated Reasoning Checks: every decision comes with a cryptographic proof a counterparty or regulator can verify in under a second without seeing the policy detail or the transaction parameters.”
— Houman Shadab, Co-Founder, ICME Labs
Results
The workflow produces a per-transaction, hardware-attested, independently verifiable governance record before settlement of a payment transaction by an agent. Enterprises adopting this pattern on Amazon Bedrock AgentCore payments get the following, per payment transaction, at machine speed:
- Verifiable execution on transactions: Each agent action is cryptographically signed and independently verifiable against a public anchor on the Base networks. Governed payments processed across both decision paths, ALLOW and REVIEW, and both carry the same evidence guarantee. The DENY path, fully implemented and unit-tested in the ORACLE engine, produces a signed refusal record when configured constraints are violated.
- Risk pricing: Each transaction carries a deterministically computed risk multiplier, so the governance record prices the risk it carried rather than treating every payment as identical. The risk multipliers reflect the engine’s operating point, with outcome calibration accruing as observed executions accumulate.
- Independent auditability: Each governing decision is anchored on a public blockchain, designed for third-party verification using reference verifier tooling from Solv Labs and ICME, without exposing the policy detail, transaction parameters, or private keys.
- Governance at machine speed: Transactions complete in under four seconds, covering pre-authorization, governance, payment processing, and on-chain settlement through Coinbase. Governance-call latency holds within the latency budget of the overall transaction.
- A single, observable surface: Each decision, attestation, and risk price is visible through the same AgentCore Observability on Amazon CloudWatch logs, metrics, and traces operators use for the rest of agent behavior. The record is structured for the people who consume it: Risk and Compliance, Internal Audit, and external auditors and counterparties, each able to verify.

Figure 4: The per-transaction evidence stack. All four artifacts are produced before settlement fires and recorded together, and auditors, counterparties, and regulators can verify each element independently without access to the operator’s policy detail, transaction parameters, or private keys
What this unlocks for enterprises
- A clean audit trail per transaction , produced at the moment of execution rather than reconstructed afterward: what was authorized, under which policy, against which constraints, at what risk price, signed by which enclave, and anchored where.
- Evidence that survives a dispute. When a counterparty, auditor, or regulator asks why a payment was permitted, the answer is a verifiable artifact, not an organizational assertion. This matters most in regulated environments, where evidence-retention obligations attach to each transaction.
- Governance at agent speed. Sub-second governance overhead means enterprises get both control and the throughput agentic workloads require.
- Review effort that scales with exceptions, not volume. Because every transaction carries its own evidence and clears a policy gate before settlement, review shifts from sampling every Nth transaction to investigating the exceptions the evidence itself flags. Oversight work grows with the exception rate, not the transaction rate.
- A control cost that fits the budget line you already own. Running on AgentCore’s native surfaces, there is no parallel control plane to license, integrate, or staff. The marginal cost of governing one more payment is dominated by the AgentCore call itself, with proof and anchoring as marginal cost on top of a line enterprises already pay, not a new line item.
- A foundation for the workloads ahead. The same per-transaction evidence model scales to the volume and diversity of payment actions agentic workloads will generate in production.
Conclusion
Using Amazon Bedrock AgentCore payments together with ORACLE, PreFlight and an AWS Nitro Enclave attester, Solv Labs built a governed agent-payments workflow in which every transaction is evaluated against policy, attested in hardware, priced for risk, and anchored to a public blockchain, all before settlement fires. For enterprises, that means review effort that scales with exceptions rather than volume, a control cost that fits a budget line they already own, and an audit trail their Risk, Compliance, and Audit functions can each verify without access to the operator’s policy detail, transaction parameters, or private keys. That is what it takes to deploy agent payments in regulated environments without trading speed for control.
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.
About the authors
Patrick Duffy
Patrick is CEO of Solv Labs, where he leads the design of the governed agent-payments workflow and the per-transaction evidence model that makes it independently verifiable.
Houman Shadab
Houman is a cofounder of ICME Labs, the company behind PreFlight, a privacy-preserving verification layer that makes AWS Automated Reasoning Checks independently verifiable in under a second. He focuses on turning that cryptographic rigor into an audit trail that enterprises, compliance teams, and regulators can actually rely on.
Madhu Samhitha Vangara
Madhu is a Worldwide GenAI Specialist Solutions Architect at AWS, focusing on Agentic AI GTM for Amazon Bedrock AgentCore and Strands Agents. She brings deep enterprise experience translating emerging AI capabilities into measurable customer outcomes. Madhu is a speaker at AI conferences and specializes in production-grade Agentic AI.
Raju Ansari
Raju is a Senior Software Development Engineer at AWS, specializing in scalable, secure, serverless solutions that simplify data analytics and AI agent development. Currently, he is focused on building foundational AI services, including Amazon Bedrock, which helps developers create intelligent, autonomous applications at scale.
Chethan Shriyan
Chethan is a Principal Product Manager – Technical at AWS. He has 12+ years of experience in product and business management. Chethan is passionate about building and delivering technology products that create meaningful impact in customers’ lives.
Wyatt Benno
Wyatt is a technical founder at ICME Labs (https://icme.io/), where he leads the research, combining formal methods and cryptography so that every AI agent action ships with a proof rather than a promise. His work centers on how formal verification and zero-knowledge techniques can make autonomous agents provably secure, not just trusted.