How t54 built a trust layer with Amazon Bedrock AgentCore payments

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

t54는 Amazon Bedrock AgentCore payments의 지출 통제와 x402-secure의 결제 전 신뢰 평가를 결합해 사람의 개별 승인 없이 2,000만 건 이상의 에이전트 거래를 처리했다.

📌 핵심 요약

• x402-secure가 처리한 에이전트 거래는 2,000만 건 이상이며, 각 거래는 $0.001~$0.01의 소액 결제로 사람의 개별 승인 없이 진행됐다.
• Amazon Bedrock AgentCore payments는 세션 지출 한도, 자격 증명 격리, 결제 실행을 제공하고, x402-secure는 결제 대상의 신뢰도를 실시간으로 평가한다.
• Trustline은 블록체인 이력, 웹페이지 적법성, 소셜 미디어 활동, API 상태와 이를 종합한 위험 점수를 평가하며, 결정론적 신뢰 게이트는 기준 미달·사기 표시·URL 불일치가 있는 결제를 코드로 차단한다.
• IAM 역할 분리로 에이전트는 자신의 한도를 변경하거나 새 지갑을 만들거나 자격 증명에 직접 접근할 수 없으며, 세션 지출 한도를 소진하면 중단된다.
• 동일한 결제 설정을 직접 API와 Coinbase x402 Bazaar의 유료 MCP 도구에 적용했으며, Amazon CloudWatch와 AWS CloudTrail을 통해 결제 및 API 이력을 기록한다.

🧩 주요 포인트

1. 결제 실행과 규칙 설정의 분리 → IAM 권한과 세션 지출 한도로 에이전트가 자신의 지출 통제를 변경할 수 없도록 구성한다.
2. 매 결제 전 Trustline 평가와 결정론적 신뢰 게이트 적용 → 평가 지연을 수용하면서 모델이 위험 판정을 무시하고 결제를 진행하는 경로를 차단한다.
3. 직접 API와 유료 MCP 도구에 동일한 결제 설정 적용 및 거래 이력 기록 → 결제 연동 범위를 넓히면서 사후 추적 근거를 확보한다.

🧠 상세 정리

1. 자율 결제의 과제는 지갑 제공보다 지출 통제

원문은 조사와 추론, 여러 단계의 작업을 수행하는 에이전트도 유료 서비스에 접근하면 결제 수단과 지출 한도가 없어 멈춘다는 문제에서 출발한다. 예시로 제시한 금융 서비스의 포트폴리오 감시 시스템은 보유 종목의 변화를 분석가에게 알리기 위해 유료 API의 실시간 시장 데이터가 필요하다. 지갑을 연결하는 것보다 어려운 일은 잘못 구성된 반복 실행이 계좌를 소진하지 않도록 한도를 적용하고, 자격 증명을 격리하며, 모든 거래를 감사할 수 있도록 만드는 것이다. 수십 개의 에이전트가 수백 개의 엔드포인트를 호출하고 시간당 수천 건의 API 요청을 보내면 사람이 거래마다 승인하는 방식은 유지하기 어렵다. 이에 t54의 고객들은 결제 제공자별 연동을 처음부터 직접 개발하지 않으면서도 보안과 확장성을 갖춘 자율 결제 기반을 요구했다.

2. 결제 기반과 신뢰 평가를 결합한 제품 구성

Amazon Bedrock AgentCore payments는 세션 한도와 자격 증명 격리, 결제 실행을 담당하고, t54의 x402-secure는 어떤 서비스에 안전하게 결제할 수 있는지를 판단하는 신뢰 계층을 제공한다. 기반 프로토콜인 x402는 HTTP 402 상태 코드를 활용해 클라이언트가 HTTP를 통해 API 이용 대금을 직접 지불하도록 하는 공개 결제 표준이다. 유료 엔드포인트가 402 응답을 반환하면 결제 기반이 서명과 정산을 처리하므로 에이전트가 개인 키를 직접 취급하지 않는다. x402-secure의 평가 엔진인 Trustline은 엔드포인트와 온체인 결제 주소를 실시간으로 평가하며, 단일한 약한 신호만으로 거래가 승인되지 않도록 설계됐다. 제품군에 포함된 ClawCredit은 에이전트용 신용 기반 자금원을 제공하고, AgentCore payments의 세션별 지출 상한과 독립적으로 지출을 통제한다.

3. 역할 분리와 자격 증명 격리

아키텍처의 핵심 원칙은 돈을 쓰는 주체가 지출 규칙까지 설정해서는 안 된다는 것이다. t54는 IAM을 통해 시스템을 네 가지 역할로 분리해 에이전트 런타임이 결제를 실행하되 자신의 한도를 변경하거나 새 지갑을 생성하거나 자격 증명에 직접 접근할 수 없도록 했다. 호출 시 에이전트에는 세션 ID와 결제 수단 ID만 전달되며, 개발자 자격 증명은 Amazon Bedrock AgentCore Identity를 통해 AWS Secrets Manager에 암호화되어 저장되고 API 응답으로 반환되지 않는다. 최종 사용자 지갑의 서명 키는 지갑 제공자인 Coinbase에 남아 있고, 에이전트에는 세션 범위로 제한된 토큰만 제공된다. 지출 한도를 소진한 에이전트는 중단되며, 에이전트 내부에서 한도를 보충하거나 세션을 다시 생성하는 경로도 허용하지 않는다.

4. 매 결제를 통제하는 신뢰 게이트와 운영 결과

t54는 위험 평가를 결제와 별도로 실행하는 보조 기능이 아니라 모든 ProcessPayment 전에 통과해야 하는 결정론적 게이트로 구현했다. 에이전트 시스템은 매 결제 전에 x402-secure API를 호출하며, 점수 기준 미달이나 사기 표시, URL 불일치가 있으면 코드가 결제를 차단하므로 모델이 이를 무시할 수 없다. 통합 담당자는 결제 경로 안에서 평가하면 지연이 조금 늘어나지만, 새로운 위험 판단 없이 정산이 이뤄지지 않는 보장을 위해 이를 수용했다고 설명한다. 출시 이후 x402-secure는 사람의 개별 승인 없이 2,000만 건 이상의 에이전트 거래를 처리했으며, 거래별 금액은 $0.001~$0.01이었다. t54는 운영 중 고위험으로 평가된 엔드포인트에 대한 결제를 차단해 세션 지출 한도를 유지하고 에이전트를 더 안전한 대상으로 유도한 사례도 제시한다.

5. 제어 영역에서 구성하는 세 가지 결제 자원

구현 설명은 결제 기반을 준비하는 제어 영역과 실제 거래를 처리하는 데이터 영역을 구분하며, 제어 영역에서는 세 가지 자원을 구성한다. Credential Provider는 자격 증명을 토큰 저장소에 보관해 에이전트 런타임에 평문으로 노출되지 않도록 한다. Payment Manager는 권한 부여와 신원, 결제 커넥터를 연결하며, t54는 OIDC 검색 엔드포인트를 기반으로 하는 CUSTOM_JWT 권한 부여자를 설정했다. Payment Connector는 결제 제공자 유형을 CoinbaseCDP로 지정하고 Credential Provider를 참조해 Payment Manager와 외부 제공자를 연결한다. 이러한 구성은 제공자마다 별도의 결제 통합 코드를 작성하지 않고 기반을 마련하기 위한 것으로, 이후 실행 단계에서 사용할 자격 증명과 결제 연결 관계를 정의한다.

6. 데이터 영역의 세션·지갑·결제 처리

실행 시 CreatePaymentSession은 지출 한도와 만료 시간, userId를 지정해 세션을 열며, 만료 시간의 허용 범위는 15~480분이다. Amazon Bedrock AgentCore payments는 세션에서 사용할 수 있는 잔여 지출액을 실시간으로 추적한다. CreatePaymentInstrument는 지정된 네트워크에 내장형 암호화폐 지갑을 생성하고, 응답으로 지갑 주소와 온보딩용 리디렉션 URL을 반환한다. ProcessPayment는 실제 결제를 실행하지만 정산에 앞서 Trustline이 엔드포인트를 평가하며, 승인된 거래에는 processPaymentId와 상태, 전체 감사 이력이 반환된다. 위험으로 표시된 경우에는 x402-secure가 결제를 차단하고 지출 한도를 그대로 유지하므로, 세션 관리와 결제 실행에 신뢰 판단이 함께 적용된다.

7. 유료 MCP 도구 시장으로 확장한 동일한 연동

t54는 직접 호출하는 유료 API뿐 아니라 유료 AI 도구 서버를 제공하는 Coinbase x402 Bazaar에서도 같은 결제 연동을 시험했다. 이 시장의 도구 서버는 MCP를 사용하며, 에이전트 시스템은 Amazon Bedrock AgentCore Gateway를 통해 연결한 뒤 유료 도구를 발견하고 호출한다. 도구가 x402 결제 요구를 반환하면 ProcessPayment가 거래에 서명하는 흐름으로 결제가 이어진다. 원문은 하나의 Amazon Bedrock AgentCore payments 설정으로 직접 API 엔드포인트와 시장에 등록된 도구를 모두 처리할 수 있으며 추가 설정이 필요하지 않았다고 설명한다. 이 사례는 도구를 발견하고 호출하는 경로가 달라도 동일한 결제 기반을 적용할 수 있음을 보여주며, 원문은 해당 시장 연동을 시험한 결과로 제시한다.

8. 신뢰 신호와 결제 전 평가 API

Trustline이 사용하는 다섯 가지 신호는 결제 주소의 블록체인 이력, 대상 웹페이지의 적법성, 서비스의 소셜 미디어 활동, API의 실시간 상태, 그리고 앞의 네 요소를 종합한 위험 점수다. 각 신호는 서로 다른 유형의 신뢰할 수 없는 대상을 식별하며, t54는 단일한 약한 신호만으로 거래를 승인할 수 없도록 위험 모델을 구성했다. 원문의 API 표에는 종합 보안 점수와 위험 지표, 블록체인 주소 위험, AI 기반 피싱 및 무단 활동 탐지, 소셜 미디어 평판, 서버 신뢰성과 규정 준수를 확인하는 평가 기능이 제시된다. 이와 별도로 Base에서 거래 전 결제 위험을 평가하는 evaluate_agent_payment 엔드포인트도 포함된다. 따라서 표에 나오는 여섯 개의 평가 엔드포인트는 다섯 가지 신뢰 신호와 함께 결제 전 위험 판단에 사용할 수 있는 기능을 구체적으로 보여준다.

9. 관측·감사와 도입 안내

모든 ProcessPayment 호출은 세션과 결제 수단, 금액, 상태를 담은 구조화 로그를 Amazon CloudWatch에 남긴다. AWS CloudTrail은 규정 준수 검토를 위한 전체 API 이력을 수집하고, Amazon CloudWatch Application Signals는 세션별로 신뢰 판단과 결제 결과를 연결한다. 원문은 이를 통해 규제 대상 업무에서도 에이전트가 지출한 금액과 그 결제의 근거가 된 신뢰 신호를 연속적인 감사 이력으로 확인할 수 있다고 설명한다. 도입 안내에서는 t54 x402-secure 구현 사례와 첫 에이전트 결제 과정을 설명하는 시작 자습서를 소개하고, 기존 AgentCore 에이전트에 적용할 공개 SDK의 설치 명령으로 pip install x402-secure를 제시한다. API 제공자에게는 x402 결제 중개 URL을 t54 프록시로 바꾸는 안내가 시작되지만 제공된 본문은 문장 중간에서 끝나므로, 이후 절차나 추가되는 기능은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 2,000만 건 이상의 소액 거래 사례는 사람의 개별 승인 없이도 매 거래에 신뢰 평가와 지출 통제를 적용하는 운영 방식을 보여준다.
• 결정론적 신뢰 게이트와 IAM 역할 분리는 결제 대상의 위험 판단과 에이전트의 권한 제한을 각각 코드와 접근 권한으로 강제한다.
• 세션별 신뢰 판단과 결제 결과를 연결한 감사 이력은 어떤 금액이 지출됐는지뿐 아니라 어떤 평가에 따라 결제가 진행됐는지 추적할 근거가 된다.

✅ 액션 아이템

• 자율 결제 적용 시 Amazon Bedrock AgentCore payments의 세션 지출 한도와 IAM 역할 분리 적용 여부 검토.
• 매 결제 전 Trustline 평가와 결정론적 신뢰 게이트의 차단 조건, 평가 지연 검토.
• 직접 API와 유료 MCP 도구의 동일한 결제 설정 적용 가능성 및 Amazon CloudWatch·AWS CloudTrail의 거래 추적 범위 확인.

❓ 열린 질문

• 2,000만 건 이상의 거래에서 결정론적 신뢰 게이트가 차단한 결제의 비율은 얼마인가?
• 매 결제 전 Trustline 평가로 발생하는 지연은 어느 정도인가?
• 세션 지출 한도를 소진해 에이전트가 중단된 이후에는 어떤 절차로 작업을 재개하는가?