Building agents that transact with Anchor Browser and AgentCore payments

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Anchor Browser는 Amazon Bedrock AgentCore payments와 연동해 AI 에이전트가 같은 브라우저 세션 안에서 지출 한도를 적용하고 개인 키를 런타임에 노출하지 않으면서 x402 유료 리소스에 자동 결제하도록 지원한다.

📌 핵심 요약

• 유료 데이터셋·연구 API·웹 콘텐츠에서 HTTP 402 Payment Required를 받은 AI 에이전트는 자체 결제 수단이 없으면 작업을 중단하고 사람의 개입을 필요로 한다. x402는 결제 금액·허용 결제 방식·결제 주소를 HTTP 응답으로 전달하는 개방형 기계 간 결제 표준이다.
• Anchor Browser with Agentic Payments는 AWS Generative AI Innovation Center Partner Agent Factory와 협력해 개발됐으며 AWS Marketplace에서 제공된다. Amazon Bedrock AgentCore payments는 지갑 연결, 인프라 계층의 지출 한도, x402 결제 처리와 Amazon CloudWatch를 통한 결제 관측 기능을 관리한다.
• 직접 결제를 구현하면 프로토콜 처리, 개인 키 관리, 요청 재시도·멱등성·동시 실행 예산 관리, 감사 로그를 개발자가 책임져야 한다. 지출 한도가 없으면 버그·재시도 루프·프롬프트 인젝션 등이 의도하지 않은 결제를 유발할 수 있고, 런타임의 개인 키와 서명 경로도 공격에 노출될 수 있다.
• Anchor Browser는 브라우저 세션에 전용 PaymentSession과 예산을 연결한다. AgentCore payments가 예산을 검증하고 Coinbase CDP 또는 Stripe Privy를 통해 결제 증명을 생성하면 브라우저는 원래 요청을 정확히 한 번 재시도하며, 판매자가 증명을 검증하고 온체인 정산 후 콘텐츠를 제공한다. 개인 키는 브라우저나 에이전트 런타임에 들어오지 않는다.
• 자동 결제에는 유효한 ANCHOR_API_KEY가 필요하며, 기본값이 false인 session.x402를 true로 설정하면 구성된 결제 수단에서 실제 결제가 승인된다. 결제는 같은 브라우저 세션에서 이뤄지고 기존 Playwright·Puppeteer·Chrome DevTools Protocol 워크플로를 변경하거나 자동화 코드에 지갑 키·결제 헤더를 넣을 필요가 없다고 설명한다.

🧩 주요 포인트

1. 결제 책임의 인프라 이전 → AgentCore payments가 지갑·서명·지출 한도·관측 기능을 맡아 에이전트 내부의 결제 구현 부담과 민감 정보 노출을 줄이는 구조다.
2. 브라우저 세션과 PaymentSession의 연결 → 인증·쿠키·요청 맥락을 유지하면서 결제와 콘텐츠 수신을 이어가고, 세션 녹화와 실시간 화면에 실제 실행 과정을 함께 담는다.
3. session.x402의 명시적 활성화 → 기존 자동화에 필요한 설정은 작지만 실제 자금 지출을 승인하므로, 구성된 결제 수단과 세션 예산이 자동 결제의 통제 기준이 된다.

🧠 상세 정리

1. HTTP 402가 자율 에이전트의 작업을 중단시키는 이유

AI 에이전트가 접근하는 웹 리소스에는 쿼리마다 비용을 받는 프리미엄 데이터셋, 호출량에 따라 과금하는 연구 API, 결제 뒤에 콘텐츠를 제공하는 발행사 등이 포함된다. 이런 리소스에 대한 요청이 HTTP 402 Payment Required 응답을 받으면, 내장 결제 기능이나 세션 예산이 없는 에이전트는 작업을 계속하지 못하고 사람의 개입을 필요로 한다. x402는 HTTP 기반의 기계 간 결제를 위한 개방형 표준으로, 서버가 402 응답에 금액과 허용 결제 방식, 결제 주소를 담아 전달한다. 글은 이 결제 요구를 에이전트가 프로그램으로 처리할 수 있도록 Anchor Browser와 Amazon Bedrock AgentCore payments를 결합하는 방식을 소개한다. Anchor Browser with Agentic Payments는 AWS Generative AI Innovation Center Partner Agent Factory와 협력해 개발됐으며 AWS Marketplace에서 제공된다고 설명한다.

2. 직접 구현해야 하는 결제 스택의 복잡성

관리형 결제 서비스가 없으면 개발자는 HTTP 402 응답을 다른 4xx 오류와 구별하고 결제 요구를 해석하는 단계부터 직접 구현해야 한다. 판매자가 기대하는 정확한 형식으로 암호학적 증명과 결제 헤더를 만들고, exact·upto 및 프로토콜 변형을 지원하면서 판매자별 요구 형식과 지원 스테이블코인, 정산 시점 차이에도 대응해야 한다. 여기에 개인 키의 안전한 보관, 키 교체, 자격 증명 갱신, 지갑 제공자 장애 시 전환 같은 지갑 수명주기 관리가 추가된다. 운영 측면에서는 쿠키와 요청 맥락을 보존한 재요청, 지갑 작업의 멱등성, 동시 에이전트 실행에 걸친 실시간 예산 추적과 세션별·거래별 한도가 필요하다. 결제 시도·승인·거절·정산을 감사 로그에 남기는 일까지 포함되므로, 에이전트 내부에는 지갑과 개인 키부터 서명·헤더 부착·재시도·정산·로깅까지 강하게 결합된 구성 요소가 들어가게 된다.

3. 지출 통제와 키 격리가 필요한 보안 근거

글은 결제 스택의 부담이 개발 공수에 그치지 않고 실제 자금과 자격 증명의 보안 문제로 이어진다고 강조한다. 인프라 수준에서 강제하는 지출 한도가 없으면 버그, 재시도 루프, 프롬프트 인젝션 또는 의도하지 않은 접근이 원치 않는 결제를 유발할 수 있으며, 유료 엔드포인트를 반복 호출하는 에이전트가 사람의 개입 전까지 계속 결제를 승인할 수 있다. 개인 키가 에이전트 런타임에 있으면 신뢰할 수 없는 웹 페이지, 외부 도구, 외부 의존성과 실행 환경을 공유하므로 실제 자금을 통제하는 자격 증명이 노출될 가능성이 생긴다. 서명 인프라가 런타임에서 접근 가능한 경우에도 공격자는 키에 접근하거나 결제 대상을 자신이 통제하는 주소로 바꾸려 시도할 수 있어, 글은 키가 애초에 런타임에 들어오지 않는 구조를 완화책으로 제시한다. 브라우저 기반 에이전트에는 결제를 같은 세션에서 수행해야 한다는 추가 제약도 있으며, 이를 벗어나면 세션 녹화와 실시간 화면이 실제 실행 내용과 일치하지 않게 된다.

4. 같은 브라우저 세션에서 실행되는 관리형 결제

해결책의 핵심은 결제 스택을 관리형 인프라로 옮기면서 브라우저 작업과 결제를 하나의 세션 안에 유지하는 것이다. Anchor Browser는 AI 에이전트용 클라우드 브라우저로, 인증 상태와 지속적인 세션 정체성을 유지하고 탐색·네트워크 요청·녹화·실시간 화면을 같은 환경에서 처리해 반복 가능하고 결정적인 워크플로를 지원한다고 설명한다. 결제가 필요하면 요청, 402 응답, 결제, 콘텐츠 전달까지의 전체 순서가 같은 세션에서 실행되고 녹화에도 담긴다. 내장 x402 도구는 브라우저 맥락에서 유료 API 호출을 처리하며, 기존 Playwright·Puppeteer·Chrome DevTools Protocol 기반 워크플로에는 변경이 필요하지 않다고 제시한다. 이 구조에서 Anchor Agent가 보유하는 결제 관련 요소는 예산 세션과 x402 도구로 줄어들고, 인증·지갑 비밀정보·결제 한도·관측 기능·결제 증명 서명은 AgentCore payments 계층이 담당한다.

5. Payment Manager와 외부 지갑 연결 구조

AgentCore payments의 중심에는 AWS 계정의 결제 작업을 조율하는 최상위 리소스인 Payment Manager가 있으며, 생성할 때 권한 부여 유형과 IAM 역할을 지정해야 한다. 그러면 AgentCore가 Amazon Bedrock AgentCore Identity에 대응하는 워크로드 ID를 프로비저닝하고, PaymentConnector가 Payment Manager를 외부 지갑 제공자인 Coinbase Developer Platform, 즉 Coinbase CDP 또는 Stripe Privy와 연결한다. PaymentCredentialProvider는 지갑 제공자의 자격 증명을 AgentCore Identity에 안전하게 저장하고, PaymentInstrument는 자금을 인출할 구체적인 지갑 주소를 식별한다. Anchor Browser는 이 구성을 통해 지갑 비밀정보나 개인 키를 에이전트 런타임에 넣지 않고 지갑을 설정하며, 지갑 작업은 구성된 제공자를 통해 AgentCore payments가 처리한다. 유료 엔드포인트 탐색을 위해서는 Amazon Bedrock AgentCore Gateway를 통해 선별된 Coinbase x402 Bazaar MCP 서버를 제공하고, 결제 시도·승인·거절·정산의 관측 정보는 Amazon CloudWatch를 통해 제공한다.

6. PaymentSession 생성부터 예산 검증과 서명까지

x402를 활성화한 Anchor Browser 세션이 시작되면, 브라우저 세션 전용 AgentCore PaymentSession이 생성되어 구성된 결제 수단과 예산에 연결된다. 이후 에이전트가 URL로 이동하거나 fetch 또는 XMLHttpRequest, 즉 XHR 요청을 보내면 판매자는 결제 금액·허용 방식·결제 주소를 포함한 HTTP 402 응답을 반환할 수 있다. Anchor Browser는 이 결제 요구를 읽고 PaymentSession에 연결된 결제 수단과 호환되는 방식을 선택한다. 다음으로 AgentCore payments가 해당 금액이 세션 지출 한도 안에 있는지 검증하고, 구성된 Coinbase CDP 또는 Stripe Privy를 이용해 거래에 서명한 뒤 암호학적 결제 증명을 반환한다. 이 과정에서 키 자료는 브라우저나 에이전트 런타임에 들어오지 않으며, 지갑 자격 증명은 AgentCore와 구성된 지갑 제공자 측에 남는다.

7. 요청의 단일 재시도와 판매자의 검증·정산

결제 증명을 받은 브라우저는 원래 요청에 서명된 증명을 붙여 정확히 한 번 재시도한다. 헤더 이름은 x402 버전에 따라 달라서 v2에서는 PAYMENT-SIGNATURE를, v1에서는 X-PAYMENT를 사용한다. 재요청을 받은 판매자는 암호학적 증명을 검증하고 거래를 온체인으로 정산한 다음 보호된 리소스를 반환하며, 에이전트는 받은 응답으로 작업을 이어간다. 따라서 제시된 흐름에서는 AgentCore payments가 세션 예산 검증과 지갑 제공자를 통한 서명을 맡고, 판매자가 증명 검증과 최종 정산을 수행하는 역할 구분이 드러난다. 원래 요청의 재시도와 콘텐츠 수신이 같은 브라우저 세션에서 이어지므로 인증 상태와 요청 맥락을 유지하면서 실제 결제 과정을 녹화와 실시간 화면에 반영할 수 있다는 것이 글의 설명이다.

8. 자동 결제 활성화와 실제 지출 승인

설정의 사전 조건은 유효한 Anchor Browser API 키인 ANCHOR_API_KEY이며, 글은 키 생성 방법으로 Anchor Browser Quick Start를 안내한다. 자동 결제를 켜려면 기본값이 false인 session.x402를 true로 지정하면 되고, 이 설정은 구성된 결제 수단에서 실제 결제를 수행하도록 브라우저에 권한을 부여한다. 예제는 cURL과 JavaScript에서 Anchor Browser 세션 생성 API인 https://api.anchorbrowser.io/v1/sessions에 POST 요청을 보내고, anchor-api-key 헤더와 session.x402 설정을 전달하는 방식이다. JavaScript 예제는 응답에서 세션 정보를 꺼내 cdp_url을 출력하며, 이후 Chrome DevTools Protocol로 연결한 에이전트는 평소처럼 탐색할 수 있다고 설명한다. 제공된 본문은 자동화 코드에 지갑 키나 결제 헤더를 직접 포함할 필요가 없다는 설명 뒤에서 잘려 있으므로, 그 이후의 설정이나 동작에 관한 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 자동 결제의 통제는 에이전트의 판단만으로 완성되지 않는다. 글이 제시하는 구조에서는 인프라의 지출 한도와 런타임 밖의 키 관리가 자율 실행을 뒷받침한다.
• 같은 브라우저 세션에서 결제하는 설계는 인증과 요청 맥락의 연속성뿐 아니라, 녹화·실시간 화면과 실제 결제 실행의 일치에도 의미가 있다.
• session.x402라는 작은 설정 변경이 실제 자금 지출 권한을 부여하므로, 도입의 핵심은 활성화 자체와 함께 연결된 결제 수단과 예산을 이해하는 데 있다.

✅ 액션 아이템

• session.x402를 true로 활성화하기 전에 구성된 결제 수단과 세션 예산, 실제 결제 승인 범위를 확인한다.
• AgentCore payments 적용 시 개인 키를 런타임에 두지 않는 구성과 인프라 계층의 지출 한도 적용을 확인한다.
• Anchor Browser의 HTTP 402 처리에서 같은 브라우저 세션 유지와 원래 요청의 정확히 한 번 재시도 여부를 확인한다.

❓ 열린 질문

• AgentCore payments의 세션 예산과 지출 한도는 어떤 기준으로 설정할 것인가?
• session.x402를 true로 설정해 실제 결제를 승인할 결제 수단은 Coinbase CDP와 Stripe Privy 중 어느 제공자에 연결할 것인가?
• Amazon CloudWatch에서 제공하는 결제 시도·승인·거절·정산 정보로 의도하지 않은 결제를 어떻게 파악할 것인가?