Pay with confidence: How Solv Labs built verifiable, auditable agent payments on Amazon Bedrock AgentCore payments
Quick Summary
Solv Labs는 Amazon Bedrock AgentCore payments에 ORACLE, ICME PreFlight, AWS Nitro Enclave 및 거래별 위험 가격을 결합해 결제 전 정책 판단부터 Coinbase 온체인 정산까지 4초 미만에 처리하고, 각 에이전트 결제에 독립 검증 가능한 감사 증거를 결속했다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
Solv Labs는 Amazon Bedrock AgentCore payments에 ORACLE, ICME PreFlight, AWS Nitro Enclave 및 거래별 위험 가격을 결합해 결제 전 정책 판단부터 Coinbase 온체인 정산까지 4초 미만에 처리하고, 각 에이전트 결제에 독립 검증 가능한 감사 증거를 결속했다.
📌 핵심 요약
- Solv Labs는 Amazon Bedrock AgentCore payments를 결제 처리 계층으로 사용하고, ORACLE의 사전 승인과 ICME PreFlight의 규정 준수 검증을 결합한 에이전트 결제 워크플로를 구축했다.
- 모든 결제는 ORACLE 판정, 독립 검증 가능한 정책 증명, AWS Nitro Enclave의 무결성 증명, 거래별 위험 가격 산정을 거친 뒤에만 정산되며, 결정이 없으면 정산도 시작되지 않는다.
- 거래별 증거 기록은 평가된 정책, 정책 검사 결과와 증명, 하드웨어가 증명한 실행 기록, 위험 배수, AgentCore payments의 정산 산출물을 하나로 결속한다.
- AgentCore payments는 세션별 지출 한도를 독립적으로 집행하고, 위험 엔진은 위반 신호를 바탕으로 결정론적 위험 배수를 계산하며 관찰된 실행이 누적될수록 결과 보정 근거가 쌓인다.
- ALLOW와 REVIEW 경로는 동일한 증거 보장을 제공하고 DENY 경로는 서명된 거부 기록을 생성하며, 전체 거래는 4초 미만, 거버넌스 오버헤드는 1초 미만에 처리된다.
🧩 주요 포인트
- 정책·제약·위험 가격·정산 결과를 개별 거래에 암호학적으로 결속 → 조직 수준의 사후 설명을 넘어 특정 결제가 허용된 근거를 제3자가 직접 검증할 수 있다.
- ORACLE의 선결 판정, ICME PreFlight의 비공개 독립 증명, AWS Nitro Enclave의 하드웨어 증명을 정산 전에 고정 → 조작되거나 잘못 구성된 에이전트가 통제 없이 자금을 이동할 위험을 다층으로 제한한다.
- 증거는 정책에 따른 실행 여부를 입증하지만 에이전트 판단의 현명함, 정책 자체의 정확성, 거래상대방의 지급능력까지 보장하지 않음 → 자동화된 증명의 범위와 운영자의 책임이 명확히 구분된다.
🧠 상세 정리
1. 기업 에이전트 결제의 핵심 문제
자율 에이전트가 기업을 대신해 실제 자금을 이동하면 핵심 질문은 결제가 작동했는지가 아니라 특정 결제가 왜 허용됐는지를 입증할 수 있는지가 된다. 잘못 구성되거나 조작된 에이전트는 단순히 부정확한 답을 반환하는 데 그치지 않고 실제 자금을 움직일 수 있으므로, 결제 실행보다 허가 근거의 사후 증명이 더 어려운 문제가 된다. 기존의 모델 카드, SOC 2 보고서, 사후 검토는 시스템 주변 조직을 설명하지만 개별 거래가 어떤 정책과 제약을 통과했는지는 보여주지 못한다. 거래와 승인 정책 사이의 지속적인 연결이 없으면 운영자는 분쟁을 해결하거나 감사 요구를 충족하고, 정상적인 에이전트 행동과 침해된 행동을 구분하기 어렵다. Solv Labs는 기존 에이전트 환경 밖에 별도 인프라를 덧붙이거나 처리 속도를 크게 낮추지 않으면서 모든 행동을 검증하고 위험 가격을 산정하며 필요할 때 감사할 수 있는 구조를 요구했다.
2. 실행 시점 거버넌스의 비전
Solv Labs와 ICME Labs가 제시한 목표는 모든 에이전트 결제를 실행 시점에 통제하고, 운영자의 주장에 의존하지 않아도 감사인·거래상대방·규제기관이 독립적으로 확인할 수 있는 기록을 만드는 것이다. 이를 위해 Amazon Bedrock AgentCore payments가 결제 조정 계층을 맡고, AWS Automated Reasoning Checks가 형식적 정책 평가를 지원하며, AWS Nitro Enclave가 거래별 실행을 하드웨어 수준에서 증명한다. x402는 에이전트가 서비스에 결제하는 표준으로 이 구성에 포함되며, 이 네 가지 기반 요소가 함께 갖춰지면서 검증 가능한 에이전트 결제가 연구 과제가 아니라 구현 가능한 선택지가 됐다. Amazon은 2026년 5월 Coinbase 및 Stripe와 협력해 AgentCore payments를 도입했고, 에이전트가 웹 콘텐츠, API, MCP 서버, 다른 에이전트에 접근해 사용한 만큼 결제할 수 있도록 했다. 지출은 개발자가 에이전트를 운영할 때 사용하는 통제 체계 안에서 관리되므로 결제 기능과 에이전트 운영 거버넌스를 분리하지 않는 것이 이 비전의 핵심이다.
3. 구성 요소와 신뢰 경계
워크플로는 Solv Labs가 운영하는 환경의 AgentCore payments, Nitro Enclave 증명기를 포함한 ORACLE 엔진, 외부 서비스로 제공되는 ICME 정책 검사로 구성된다. 각 구성 요소는 서로 다른 배포 환경에 놓일 수 있지만, 신뢰 경계를 통과할 때는 서명되고 해시로 결속된 산출물만 교환한다. 이 구조는 특정 서비스 배치 방식이나 운영자의 설명에 의존하지 않고 증거 흐름 자체가 무결성을 유지하도록 설계됐다. 워크플로는 Amazon Bedrock AgentCore로 구축된 에이전트에 연결되며 AgentCore runtime에서 실행되는 에이전트뿐 아니라 사용자 정의 AgentCore 구현과도 호환된다. 결제마다 사전 승인, 제약 검증, 무결성 증명, 위험 가격 산정이 정산보다 먼저 수행되기 때문에 결제 실행과 그 결제를 허가한 증거가 분리되지 않는다.
4. 다섯 구성 요소의 처리 순서
첫 번째로 ORACLE은 제안된 행동을 적용 대상 정책과 비교해 자금 이동 전에 ALLOW 또는 REVIEW 판정을 반환하며, 정책 실패가 이미 정산된 거래로 이어지는 상황을 막는다. 두 번째로 ICME PreFlight는 ORACLE 판정의 기반이 되는 정책 검사를 수행하고, 정책 내용이나 거래 매개변수를 공개하지 않아도 제3자가 검사 결과를 확인할 수 있는 작고 개인정보 보호적인 증명을 만든다. 세 번째로 AWS Nitro Enclave 안의 무결성 서비스가 실행 기록에 서명해 해당 기록이 공개된 특정 엔클레이브 이미지에서 생성됐음을 증명하고, 네 번째로 위험 엔진이 평가된 위반 신호에서 결정론적 위험 배수를 계산한다. 다섯 번째로 AgentCore payments가 세션별 지출 한도를 적용하며 결제를 처리하고, 이후 Coinbase를 통한 온체인 경로로 정산을 완료한다. ORACLE 판정, 독립 검증 증명, 하드웨어 증명, 거래별 위험 가격이 모두 생성되기 전에는 정산을 시작하지 않는 고정 순서가 적용되며, 원문은 이를 결정이 없으면 정산도 없다는 절대적인 관문으로 설명한다.
5. 암호학적으로 결속된 거래별 증거
각 결제는 평가된 정책, 정책 검사 결과와 독립 검증 증명, 하드웨어가 증명한 실행 기록, 거래별 위험 가격, AgentCore payments의 정산 산출물이라는 다섯 요소를 하나의 서명된 증거 기록에 담는다. Nitro Security Module이 생성하는 증명 문서는 서명 키를 특정 엔클레이브 이미지 측정값인 PCR0에 연결하고 PCR1과 PCR2도 포함해, 단순히 엔클레이브에서 서명됐다는 사실뿐 아니라 어떤 이미지가 기록을 만들었는지 확인할 수 있게 한다. 전체 기록에는 실행 및 정책 해시, 제약 결과, 영지식 증명 참조, 하드웨어 증명 다이제스트, 위험 배수, 온체인 앵커가 포함된다. 기록은 정규화된 뒤 Nitro Enclave 안에서 Ed25519로 서명되고 온체인에 앵커링되므로, 실행 후 내용을 조용히 다시 쓰는 행위를 방지한다. 해시와 서명으로 정책 판단부터 정산까지 연결함으로써 증거가 운영 조직의 별도 설명이 아니라 거래 자체와 함께 이동하도록 만든다.
6. 증명이 보장하는 범위와 한계
거버넌스 계층은 특정 결제가 특정 정책과 제약 아래에서 특정 위험 가격으로 평가됐고, 그 평가 결과가 실제 정산을 허가했다는 사실을 검증 가능하게 증명한다. 반면 에이전트의 기초 판단이 현명했는지, 거래상대방이 지급능력을 갖췄는지, 적용된 정책 자체가 올바른지는 증명하지 않는다. 이러한 사항은 다른 결제와 마찬가지로 운영자의 책임으로 남으며, 하드웨어 증명이나 정책 검사 증명이 대신 판단해 주지 않는다. 따라서 이 구조의 목적은 모든 사업적·법적 위험을 제거하는 것이 아니라 특정 거래에서 정책 검사가 어떻게 실행되고 어떤 결과가 결제를 승인했는지를 위조하기 어려운 형태로 남기는 데 있다. 보장 범위를 명시적으로 제한함으로써 자동화된 증거가 확인할 수 있는 사실과 운영자가 별도로 책임져야 할 판단을 구분한다.
7. AgentCore 환경의 운영 통합
거버넌스 워크플로가 에이전트와 동일한 AgentCore 환경에서 실행되므로 에이전트의 신원, 게이트웨이, 관측성 표면을 그대로 상속한다. 운영자는 에이전트와 결제를 위해 서로 다른 두 개의 통제 계층을 병렬로 관리할 필요가 없으며, 별도 통제 계층 사이의 설정 불일치에서 발생할 수 있는 거버넌스 공백을 줄인다. AgentCore payments는 에이전트나 ORACLE의 판단과 독립적으로 세션별 지출 한도를 집행해 정책 판정 외에도 인프라 수준의 방어 계층을 제공한다. 모든 판정, 증명, 위험 가격, 정산 정보는 Amazon CloudWatch의 로그·지표·추적을 사용하는 AgentCore Observability에서 에이전트의 다른 활동과 함께 확인할 수 있다. 이 통합은 결제 처리, 지출 통제, 거래별 증거, 운영 관측을 하나의 에이전트 시스템 안에서 다루게 한다.
8. 처리 결과와 독립 감사 가능성
완성된 워크플로는 에이전트가 결제를 정산하기 전에 거래별 하드웨어 증명과 독립 검증 가능한 거버넌스 기록을 생성한다. 각 행동은 암호학적으로 서명되고 Base 네트워크의 공개 앵커와 대조해 검증할 수 있으며, ALLOW와 REVIEW 양쪽 처리 경로 모두 동일한 증거 보장을 제공한다. ORACLE 엔진에 완전히 구현되고 단위 테스트된 DENY 경로는 설정된 제약을 위반할 때 서명된 거부 기록을 남겨 결제가 실행되지 않은 이유도 보존한다. 위험 엔진은 모든 결제를 동일하게 취급하지 않고 결정론적으로 계산한 위험 배수를 첨부하며, 관찰된 실행이 누적되면서 결과 보정의 근거도 축적한다. 정책 세부 내용, 거래 매개변수, 개인 키를 공개하지 않고도 Solv Labs와 ICME의 참조 검증 도구를 이용한 제3자 검증이 가능하도록 설계됐다. 사전 승인, 거버넌스, 결제 처리, Coinbase 온체인 정산을 포함한 전체 거래는 4초 미만에 완료되고 거버넌스 오버헤드는 1초 미만이어서 에이전트 작업의 지연 예산 안에서 거래별 감사를 제공한다.
🧾 핵심 주장 / 시사점
- 감사의 초점을 조직의 통제 체계에서 개별 결제의 정책 판정과 실행 증거로 이동시키면 분쟁 당사자가 특정 거래의 허가 근거를 직접 확인할 수 있다.
- 서명되고 해시로 결속된 산출물만 신뢰 경계를 통과하게 하면 ORACLE, ICME PreFlight, AWS Nitro Enclave가 서로 다른 환경에 배치돼도 증거 흐름을 유지할 수 있다.
- ORACLE 정책 판정과 AgentCore payments의 세션별 지출 한도를 독립적으로 적용하는 구조는 단일 통제가 실패해도 지출을 제한하는 다층 방어를 제공한다.
✅ 액션 아이템
- Amazon Bedrock AgentCore payments 적용 시 ORACLE의 선결 판정과 세션별 지출 한도의 중첩 통제 여부 검토.
- ICME PreFlight와 AWS Nitro Enclave가 결속한 거래별 증거의 제3자 독립 검증 가능성 확인.
- 4초 미만 전체 처리와 1초 미만 거버넌스 오버헤드 충족 여부 측정.
❓ 열린 질문
- ORACLE의 REVIEW 판정이 정산으로 이어지기 위한 구체적인 승인 조건은 무엇인가?
- 위험 엔진의 결정론적 위험 배수는 관찰된 실행이 누적될 때 어떤 기준으로 보정되는가?
- AWS Nitro Enclave가 보장하지 않는 정책 자체의 정확성과 거래상대방의 지급능력을 운영자는 어떻게 검증할 것인가?