에이전트 기반 상거래에 필요한 신원 확인 계층: Visa TAP, Google AP2, Mastercard Agent Pay 분석

주요 내용

• Visa Trusted Agent Protocol(TAP), Google Agent Payments Protocol(AP2), Mastercard Agent Pay는 모두 에이전트 주도 구매를 더 안전하게 만들지만, 신뢰 문제의 다른 부분을 해결합니다.
• TAP은 판매자가 승인된 에이전트를 인식하고 서명된 상거래 의도를 확인하는 데 도움을 줍니다. AP2는 사용자가 승인한 내용에 대한 증거를 생성합니다. Agent Pay는 등록된 에이전트, 토큰화된 결제 자격 증명, 동의 및 네트워크 가시성을 결합합니다.
• 이러한 메커니즘 중 어느 것도 인간 또는 사업체가 누구인지 증명하고, 위험을 선별하며, 관할권별 통제를 시행하고, 감사 추적을 보존해야 할 필요성을 없애지는 않습니다.
• Didit은 카드 네트워크나 결제 회사가 아닌 신원 및 사기를 위한 중립적인 인프라입니다. 호스팅된 Model Context Protocol(MCP) 서버는 11개 카테고리에 걸쳐 115개의 도구를 제공하며, REST(Representational State Transfer) API는 임베디드 프로덕션 흐름을 지원합니다.
• 전체 KYC 번들은 0.33달러이며, 모든 계정에는 매월 500건의 무료 확인이 포함되고, MCP 서버 자체는 무료입니다.

에이전트 기반 상거래는 인공지능(AI) 에이전트가 제품 추천 이상의 작업을 수행할 때 시작됩니다. 즉, 제안을 비교하고, 장바구니를 구성하고, 결제 방법을 선택하며, 개인 또는 사업체가 설정한 한도 내에서 구매를 완료할 수 있습니다. 이러한 변화는 동시에 여러 신뢰 문제를 발생시킵니다. 어떤 에이전트가 요청을 했는가? 누가 승인했는가? 그 뒤에 있는 인간 또는 법인은 누구인가? 거래가 허용되는가? 그리고 구매가 분쟁이 될 경우 어떤 증거가 존재할 것인가?

새롭게 등장하는 결제 표준은 이러한 순서의 중요한 부분을 해결합니다. 이들 모두가 같은 부분을 해결하는 것은 아니며, 서로 바꿔 쓸 수 있는 것으로 간주해서는 안 됩니다. 개발자에게 유용한 질문은 어떤 브랜드가 “승리할 것인가”가 아닙니다. 모든 신뢰할 수 있는 아키텍처에서 어떤 통제가 여전히 필요한가입니다.

세 가지 표준, 세 가지 신뢰 경계

Visa TAP: 판매자가 이 에이전트를 인식하고 신뢰할 수 있는가?

Visa Trusted Agent Protocol은 판매자 중심입니다. 주요 임무는 판매자가 승인된 상거래 에이전트를 일반적인 크롤러, 악의적인 봇 또는 알 수 없는 자동화와 구별하는 데 도움을 주는 것입니다. 에이전트는 시간 제한이 있고 목적에 맞는 자격 증명으로 요청에 서명합니다. 판매자 또는 보호 제공자는 서명을 확인하고 탐색, 결제 또는 더 좁은 작업을 허용할지 결정할 수 있습니다.

TAP은 세 가지 관련 신호를 설명합니다. 에이전트 인식 서명, 연결되고 서명된 소비자 또는 장치 신원, 연결되고 서명된 결제 컨테이너입니다. 이는 유용한 분리입니다. 에이전트 인식은 어떤 승인된 에이전트가 존재하는지 확인하고, 서명된 의도는 어떤 종류의 상호 작용이 요청되는지 확인하며, 소비자 신호는 판매자가 기존 고객을 인식하는 데 도움을 줄 수 있습니다.

이러한 소비자 신호가 새로운 신원 증명과 자동으로 동일한 것은 아닙니다. Visa의 모델에는 업스트림의 신원 제공자 역할이 포함되지만, 판매자는 새로운 고객이나 고위험 고객에 대한 정책이 여전히 필요합니다. 즉, 어떤 증거가 확인되었는지, 보증의 강도는 어느 정도인지, KYC가 필요한지, 그리고 언제 재확인이 필요한지 등입니다. TAP은 모든 관할권의 온보딩 결정을 규정하지 않고도 신뢰할 수 있는 신원 정보를 전달할 수 있습니다.

Google AP2: 사용자는 에이전트에게 무엇을 구매하도록 승인했는가?

Google Agent Payments Protocol은 승인 및 증거에 중점을 둡니다. 서명된 위임을 사용하여 사용자 의도, 결제 내용 및 결제를 연결합니다. 개방형 위임은 판매자 제약 조건 또는 지출 한도와 같은 제한된 재량권을 에이전트에게 부여할 수 있습니다. 폐쇄형 위임은 특정 장바구니 및 금액에 대한 승인을 구속합니다. 영수증은 증거 체인을 완성합니다.

AP2는 인간이 존재하는 흐름과 인간이 존재하지 않는 흐름을 구별합니다. 사람이 있을 때는 폐쇄형 결제 및 결제 위임을 직접 승인할 수 있습니다. 사람이 없을 때는 에이전트가 이전에 승인된 제약 조건 내에서 작동하고 최종 폐쇄형 위임에 서명합니다. 판매자 또는 자격 증명 제공자는 제약 조건을 해결할 수 없을 때 사람을 다시 루프에 포함시킬 수 있습니다.

이 디자인은 “이 사람이 이 조건에서 이 작업을 승인했는가?”라는 질문에 “이 사람은 어떻게 처음 확인되었는가?”라는 질문보다 더 직접적으로 답합니다. AP2 승인 프레임워크는 관련 등록 및 사용자 자격 증명이 존재한다고 가정합니다. 따라서 개발자는 이러한 위임이 의미 있는 보증을 전달하기 전에 신원 증명 및 자격 증명 수명 주기 프로세스가 여전히 필요합니다.

Mastercard Agent Pay: 네트워크가 에이전트 기반 결제를 인식하고 관리할 수 있는가?

Mastercard Agent Pay는 결제 토큰화에 기반을 둡니다. Mastercard의 승인 프레임워크는 에이전트를 등록 및 확인하고, 고유한 에이전트 신원을 할당하며, 에이전트 토큰을 사용하여 거래를 추적 가능하게 하고 결제 자격 증명을 보호합니다. 판매자 중심의 인식은 기존 결제 인프라와 함께 작동할 수 있으며, 더 깊은 통합은 더 풍부한 데이터 교환을 지원합니다.

이 모델은 또한 소비자 동의, 인증, 그리고 발급자, 매입자 및 판매자가 에이전트가 참여했음을 인식할 수 있는 능력을 강조합니다. 이는 자동화를 일반적인 카드 미제시 요청과 구별할 수 없게 만드는 대신, 익숙한 카드 네트워크 위험 모델 내에서 에이전트 활동을 가시화합니다.

Agent Pay는 결제 자격 증명 보안, 에이전트 가시성 및 네트워크 통제에서 가장 강력합니다. 이는 신원 확인, Know Your Business(KYB), 자금 세탁 방지(AML) 심사, 연령 확인 또는 강화된 검토가 적용되는 시기를 결정해야 하는 판매자의 의무를 제거하지 않습니다. 이러한 결정은 결제 레일에만 의존하는 것이 아니라 제품, 고객, 거래 및 관할권에 따라 달라집니다.

표준이 겹치는 부분과 신원이 여전히 필요한 부분

세 가지 접근 방식 모두 위임된 상거래를 명확하게 만들려고 합니다. 판매자는 자동화가 개입되었음을 파악하고, 에이전트가 신뢰할 수 있는지 확인하며, 작업을 사용자 의도에 연결하고, 구매를 제한하며, 증거를 보존할 수 있어야 합니다. 각 접근 방식의 강조점은 다릅니다.

• TAP: 판매자 경계에서 에이전트 인식 및 서명된 의도, 선택적으로 연결된 소비자 및 결제 신호.
• AP2: 사용자 의도를 결제 및 결제 결과에 연결하는 암호화된 승인 아티팩트.
• Agent Pay: 등록된 에이전트, 토큰화된 결제 자격 증명, 동의, 인증 및 카드 네트워크 전체의 가시성.

신원 증명은 이러한 통제보다 먼저 그리고 그 옆에 위치합니다. 서명된 승인은 자격 증명이 올바른 사람에게 속할 때만 가치가 있습니다. 승인된 에이전트라도 합성, 도난, 제재 대상, 미성년자 또는 기타 자격이 없는 계정의 지시를 받을 수 있습니다. 토큰은 시장 판매자 또는 사업체 수혜자가 필요한 실사를 통과했음을 입증하지 않고도 결제 자격 증명을 보호할 수 있습니다.

에이전트 신원은 “어떤 소프트웨어가 작동했는가?”에 답합니다. 승인은 “무엇을 할 수 있도록 허용되었는가?”에 답합니다. 신원 확인은 “그 뒤에 누가 있는가?”에 답합니다. 사기 및 규정 준수 통제는 “이 작업이 진행되어야 하는가?”에 답합니다.

어떤 접근 방식이 승리하든 개발자가 구축해야 하는 것

• 등록 및 증명. 재사용 가능한 자격 증명 또는 위임된 지출 권한을 부여하기 전에 개인 또는 사업체를 확인합니다. 위험에 따라 KYC, KYB, 생체 인식, 문서, 데이터베이스 또는 생체 인식 확인을 적용합니다.
• 자격 증명 바인딩. 확인된 주체를 에이전트 흐름에 참여할 수 있는 계정, 장치, 패스키, 지갑 또는 기타 자격 증명에 바인딩합니다.
• 범위 지정 승인. 판매자, 카테고리, 금액, 빈도, 만료 및 승인을 위해 사람이 다시 돌아와야 하는지 여부와 같은 제한을 캡처합니다.
• 런타임 위험 결정. 작업 순간에 개인, 사업체, 지갑 및 거래를 심사합니다. 의도가 서명된 경우에도 Know Your Transaction(KYT) 통제 및 AML 확인은 여전히 유효합니다.
• 취소 및 복구. 자격 증명이 손상되거나, 사용자가 동의를 철회하거나, 위험이 변경될 경우 위임된 권한을 중지합니다.
• 감사 가능성. 확인 결과, 승인 아티팩트, 에이전트 신원, 거래 결정, 타임스탬프 및 나중 검토 작업을 별도의 증거로 보존합니다.

이 계층형 디자인은 의도적으로 표준에 구애받지 않습니다. 팀은 판매자 경계에서 TAP을 채택하고, 에이전트 워크플로에서 AP2 위임을, 카드 결제에 Agent Pay를 사용하거나 조합할 수 있습니다. 신원 및 사기 결정은 단일 결제 네트워크에 내장되어 있지 않으므로 이식성이 유지됩니다.

Didit이 현재 신원 확인 절반을 처리하는 방법

Didit은 2,000개 이상의 프로덕션 회사에서 사용하는 신원 및 사기 방지 인프라를 제공합니다. 동일한 기능은 에이전트 기반 작업용 호스팅 MCP 서버와 애플리케이션 제어 흐름용 REST API를 통해 사용할 수 있습니다. 더 넓은 아키텍처 개요는 MCP 서버가 신원 확인을 처리하는 방법과 MCP가 AI 에이전트의 신원 및 사기 확인을 연결하는 방법을 참조하세요.

호스팅된 MCP 엔드포인트는 https://mcp.didit.me/mcp입니다. Streamable HTTP(Hypertext Transfer Protocol)를 사용하며, OAuth(Open Authorization) 2.1, PKCE(Proof Key for Code Exchange), 동적 클라이언트 등록을 지원합니다. 사용자는 Didit 비즈니스 콘솔을 통해 로그인하고 범위가 지정된 액세스를 부여합니다. 호스팅된 MCP 엔드포인트는 API 키 인증을 사용하지 않습니다.

승인 후 에이전트는 11개 카테고리에 걸쳐 115개 도구를 호출할 수 있습니다. 실용적인 확인 시퀀스는 다음을 사용할 수 있습니다.

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

이러한 도구는 확인 세션을 생성하고, 선택된 확인을 실행하며, 구조화된 결정을 검색할 수 있습니다. 다른 실제 도구에는 didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select, didit_transaction_screen_wallet이 있습니다. 중요한 쓰기 작업은 연결된 사용자의 권한 및 확인 동작에 따라 달라집니다.

REST API는 애플리케이션 경로를 다룹니다. 백엔드에서 세션을 생성하고, 호스팅 또는 임베디드 확인을 통해 사용자를 보내고, 웹훅을 사용하고, 자체 시스템에 결정을 저장합니다. REST 서버 간 요청은 x-api-key 헤더를 사용합니다. 이는 OAuth 인증 호스팅 MCP 연결과는 별개입니다. 구현 세부 정보는 MCP 개요, 인증 가이드, 도구 참조를 읽어보세요.

가격은 에이전트 기반 결제 표준과 무관합니다. MCP 서버는 무료입니다. 전체 KYC 번들(신원 확인, 수동 생체 인식, 안면 매칭, IP 분석)은 0.33달러이며, 모든 계정에는 매월 500건의 무료 확인이 포함됩니다.

표준에 구애받지 않는 구현 경로

네트워크 로고를 선택하는 대신 각 작업에 필요한 보증을 정의하는 것부터 시작하세요. 저위험 탐색은 에이전트 인식만 필요할 수 있습니다. 계정 생성에는 확인된 신원이 필요할 수 있습니다. 규제된 구매에는 KYC 또는 KYB와 AML 심사가 필요할 수 있습니다. 암호화폐 전송에는 지갑 심사가 추가될 수 있습니다. 더 높은 금액 또는 변경된 위험은 사람을 다시 루프에 포함시킬 수 있습니다.

그런 다음 안정적인 내부 식별자를 사용하여 결제 아티팩트를 신원 결정에 연결합니다. 에이전트 서명, 사용자 승인, 확인 증거 및 결제 결과를 별도로 유지하여 표준이 발전함에 따라 각각 독립적으로 취소, 검토 및 업그레이드할 수 있도록 합니다.

Didit MCP 개발자 페이지를 탐색하거나 공개적으로 허용된 라이선스가 부여된 GitHub 저장소를 검사하세요. Claude 사용자는 Didit 커넥터를 추가하고 OAuth 로그인을 완료할 수 있습니다.

내구성 있는 아키텍처는 계층형입니다. 결제 표준은 에이전트 참여 및 승인을 증명하고, 신원 및 사기 인프라는 누가 관련되어 있고 작업이 허용되는지 증명합니다. 이러한 분리를 통해 개발자는 신뢰를 단일 표준에 하드 코딩하지 않고도 오늘날의 표준을 지원할 수 있습니다.