AI 에이전트는 제품을 검색하고, 가격을 비교하며, API를 호출하고, 결제 양식을 작성할 수 있습니다. 하지만 무언가를 결제하는 단계에 이르면 워크플로우(workflow)가 어색해집니다.

많은 온라인 상점들은 여전히 수년 동안 사용해 온 것과 동일한 입력값, 즉 카드 번호, 만료일, 보안 코드(security code), 청구 주소(billing address), 그리고 때로는 추가적인 인증 단계를 요구합니다. 에이전트가 페이지를 이해할 수는 있겠지만, 가맹점이 수락하는 결제 수단이 여전히 필요합니다.

에이전트에게 개인 카드나 회사 카드의 접근 권한을 부여하는 것이 기술적으로는 가장 간단한 접근 방식입니다. 하지만 보안 관점에서는 이를 정당화하기 어렵습니다.

일반적인 카드는 훨씬 더 큰 잔액이나 신용 한도와 연결된 장기적인 자격 증명(credential)입니다. 에이전트에게는 현재의 구매를 완료할 수 있을 만큼의 지출 능력만 필요합니다. 이 두 가지 권한 범위(permission scopes)는 서로 일치하지 않습니다.

가상 카드(Virtual cards)는 그 간극을 좁힐 수 있는 방법을 제공합니다.

일반 카드를 공유할 때의 문제점

에이전트에게 25달러짜리 소프트웨어 라이선스를 구매하라는 요청을 받았다고 가정해 봅시다.

작업을 완료하려면 에이전트는 결제 페이지에 결제 정보를 입력해야 합니다. 만약 일반 카드를 제공한다면, 우리는 단순히 그 25달러의 구매를 승인하는 것뿐만 아니라, 몇 달 동안 유효할 수 있고 수천 개의 다른 가맹점에서 수락될 수 있는 자격 증명을 노출하는 것이 됩니다.

이는 몇 가지 문제를 야기합니다.

첫째, 지출 한도는 작업이 아닌 카드 계정에 귀속됩니다. 한도가 5,000달러인 카드는 프롬프트(prompt)에서 "25달러 이상 사용하지 마세요"라고 말한다고 해서 25달러짜리 자격 증명이 되지 않습니다.

둘째, 카드 정보가 있어서는 안 될 곳에 나타날 수 있습니다: 브라우저 흔적(browser traces), 스크린샷, 도구 인자(tool arguments), 애플리케이션 로그(application logs), 또는 모델 컨텍스트(model context). 에이전트가 올바르게 동작하더라도, 워크플로우의 다른 구성 요소가 해당 정보를 저장할 수 있습니다.

셋째, 접근 권한을 깔끔하게 취소(revoke)하기 어렵습니다. 만약 해당 자격 증명이 다른 곳에서 재사용된다면, 이를 취소하는 것은 사용자의 다른 결제에도 영향을 미칩니다.

이것은 본질적으로 권한(permissions)의 문제입니다. 결제 수단이 에이전트에게 작업에 필요한 것보다 더 많은 권한을 부여하고 있는 것입니다.

에이전트에게 실제로 필요한 것

대부분의 구매에서 에이전트는 결제 계좌에 대한 지속적인 접근 권한을 필요로 하지 않습니다. 에이전트에게는 다음과 같은 몇 가지 제약 조건이 포함된 일시적인 자격 증명 (credential)이 필요합니다:

• 최대 금액 (A maximum amount)
• 제한된 유효 기간 (A limited lifetime)
• 정의된 사용 횟수 (A defined number of uses)
• 사용자가 승인한 작업과의 연결 (A connection to the task the user approved)

단순화된 권한 부여 (authorization)는 다음과 같은 형태일 수 있습니다:

{
  "purpose": "선택한 소프트웨어 라이선스 구매",
  "maximum_amount": 25,
...

이 객체는 카드가 아닙니다. 이는 카드가 생성되기 전에 존재해야 하는 권한을 나타냅니다.

그 후 카드는 권한 그 자체로 취급되는 대신, 해당 권한으로부터 발급될 수 있습니다. 만약 작업이 취소되면, 사용자의 메인 카드에 영향을 주지 않고 자격 증명을 폐쇄할 수 있습니다. 만약 구매 후에 정보가 유출되더라도, 더 이상 사용할 수 없어야 합니다.

이로 인해 가상 카드 (virtual card)는 전통적인 금융 계좌보다는 일시적인 기능 (temporary capability)에 더 가까워집니다.

왜 에이전트 네이티브 결제 프로토콜을 사용하지 않는가?

가상 카드가 에이전트가 결제할 수 있는 유일한 방법은 아닙니다.

API가 프로그래밍 가능한 결제 방식 (programmable payment method)을 지원할 때, 결제는 요청 흐름 (request flow) 내에서 직접 이루어질 수 있습니다. HTTP 서비스가 가격을 반환하면, 에이전트가 결제를 승인하고, 결제 완료 후 요청이 계속 진행되는 방식입니다. 직접적인 스테이블코인 (stablecoin) 결제나 x402와 같은 프로토콜 또한 브라우저 체크아웃 (browser checkout)보다 머신 간 거래 (machine-to-machine transactions)에 더 적합합니다.

문제는 커버리지 (coverage)입니다.

에이전트는 SaaS 플랜을 구매하거나, 서비스를 예약하거나, 에이전트 전용 결제 API를 구축하지 않은 가맹점으로부터 물리적 제품을 주문해야 할 수도 있습니다. 가맹점은 이미 Visa나 Mastercard를 수락하고 있으며, 단 하나의 새로운 유형의 클라이언트를 위해 기존 체크아웃 시스템을 교체할 이유가 거의 없습니다.

그러한 상황에서 가상 카드는 어댑터 (adapter) 역할을 합니다. 에이전트는 프로그래밍 가능한 자격 증명을 얻고, 가맹점은 일반적인 카드 결제를 받게 됩니다.

이것이 에이전트에게 가장 네이티브한 결제 경로 (payment rail)는 아닙니다. 하지만 기존 상거래 인프라와 작동하는 방식입니다.

실질적인 체크아웃 흐름

합리적인 구현 방식은 결제 승인 (payment authorization)과 브라우저 자동화 (browser automation)를 분리하는 것입니다.

흐름은 다음과 같이 작동할 수 있습니다:

1. 에이전트가 제품을 선택하고 예상 총액을 계산합니다.
2. 해당 구매를 위한 예산을 요청합니다.
3. 사용자 또는 기존 정책이 요청을 승인합니다.
4. 승인된 금액으로 가상 카드 (virtual card)가 생성됩니다.
5. 에이전트가 체크아웃 페이지를 작성합니다.
6. 제출 전 최종 주문 내용을 확인합니다.
7. 결제 완료 후 카드는 폐쇄됩니다.

미리보기 단계는 매우 중요한데, 제품 페이지에 표시된 가격이 체크아웃 시 결제되는 금액과 항상 일치하지는 않기 때문입니다.

세금, 배송비, 팁, 환전 (currency conversion), 구독 (subscriptions), 그리고 선택적 추가 항목들이 총액을 변경할 수 있습니다. 카드의 한도를 25달러로 설정할 수 있지만, 그렇다고 해서 24.99달러의 결제가 실제로 사용자가 원했던 구매인지까지 알 수 있는 것은 아닙니다.

금액 제어 (Amount controls)는 재무적 노출 (financial exposure)을 줄여주지만, 의도 (intent)를 검증해주지는 않습니다.

시스템은 여전히 가맹점 (merchant), 제품, 최종 금액, 그리고 구매 조건을 원래의 요청과 비교해야 합니다.

하나의 구현 사례로서의 FluxA AgentCard

FluxA AgentCard는 FluxA 지갑 (FluxA Wallet)에서 생성된 일회용 가상 카드를 사용하여 이 모델을 적용합니다.

에이전트는 특정 금액에 대한 카드를 요청하고 이를 승인된 위임 사항 (mandate)과 연결할 수 있습니다:

fluxa-wallet card create \
  --amount 25.00 \
  --mandate mand_abc123

그 후 카드는 지원되는 브라우저 체크아웃에서 사용될 수 있습니다. 트랜잭션 (transaction)이 완료되면 카드는 무효화되며, 사용되지 않은 잔액은 지갑으로 반환됩니다. FluxA는 또한 카드의 생성, 결제, 폐쇄 및 관련 위임 사항을 기록합니다.

이 설계의 유용한 점은 단순히 카드가 가상이라는 점에 있지 않습니다. 이미 많은 금융 상품들이 가상 카드를 제공하고 있습니다.

에이전트에게 중요한 속성은 카드가 다음과 같다는 점입니다:

• 작업에 필요할 때 생성됨
• 고정된 금액을 가짐
• 단일 트랜잭션을 목적으로 함
• 독립적으로 취소 (revoked) 가능함
• 별도의 활동 기록을 가짐

FluxA의 더 넓은 지갑 흐름(wallet flow) 또한 에이전트의 접근 권한과 결제 승인(payment authorization)을 분리합니다. 에이전트가 지갑에 연결되어 있더라도, 여전히 사용자가 승인한 예산과 목적 범위 내에서 작동해야 합니다.

이러한 구분은 인증(authentication)만으로는 결제 문제를 해결할 수 없기 때문에 중요합니다. 어떤 에이전트가 요청을 보냈는지 아는 것만으로는 요청된 구매가 허용되는지 여부를 알 수 없습니다.

브라우저 자동화(Browser automation)는 예측 불가능성이 더 높은 부분입니다

카드를 발급하는 것은 상당히 구조화되어 있습니다. 하지만 체크아웃 페이지는 그렇지 않습니다.

각 가맹점(merchant)은 서로 다른 양식, 임베디드 결제 프레임(embedded payment frames), 주소 검증(address validation), 로그인 요구 사항 및 안티 봇(anti-bot) 시스템을 사용할 수 있습니다. 심지어 동일한 커머스 플랫폼에서 운영되는 두 상점이라도 플러그인이나 커스텀 스크립트 때문에 다르게 동작할 수 있습니다.

FluxA는 현재 이를 '미리보기 및 실행(preview-and-execute)' 체크아웃 흐름을 통해 접근하고 있습니다. 에이전트는 먼저 페이지를 제출하지 않은 상태로 채운 뒤, 검사를 위해 체크아웃 상태를 저장합니다. 문서화된 검증된 인터페이스(validated surfaces)에는 현재 표준 Shopify 체크아웃 경로와 Stripe 호스팅 직접 결제 페이지가 포함됩니다.

페이지에 CAPTCHA, OTP, 3D Secure, 로그인 벽(login wall) 또는 지원되지 않는 위젯이 나타나면, 워크플로우는 중단되며 성공적인 주문을 보고하는 대신 현재 상태를 사람에게 다시 전달합니다. ([FluxA][1])

이는 모든 체크아웃이 완전히 자율적일 수 있다고 가정하는 것보다 더 현실적인 접근 방식입니다.

일부 검증 단계는 인간 카드 소유자가 존재하는지 확인하기 위해 특별히 존재합니다. 에이전트 결제 시스템은 장바구니, 작성된 양식 또는 트랜잭션 컨텍스트(transaction context)를 잃지 않고 일시 중지할 수 있어야 합니다.

가상 카드(Virtual cards)가 모든 결제 리스크를 해결하는 것은 아닙니다

일회용 카드는 자격 증명 유출(credential leakage)로 인한 피해를 줄여주지만, 기본적으로 전체 트랜잭션을 안전하게 만들어주지는 않습니다.

에이전트는 여전히 다음과 같은 행동을 할 수 있습니다:

• 잘못된 제품 선택
• 월간 플랜 대신 연간 플랜 선택
• 오도하는 (misleading) 도메인에서 구매
• 원치 않는 정기 구독 (recurring subscription) 수락
• 잘못된 배송 주소 입력
• 사용자의 요청과 일치하지 않는 가맹점(merchant)에 결제

이것들은 카드 보안의 실패가 아닙니다. 의도 (intent)를 이해하거나 집행하는 데 실패한 것입니다.

운영상의 문제들도 존재합니다.

세금이 계산된 후 어느 정도의 가격 변동을 허용해야 할까요? 가맹점이 최종 결제 금액보다 더 큰 임시 승인 홀드 (authorization hold)를 설정하면 어떻게 될까요? 기존 카드가 해지된 후 환불금은 어디로 가야 할까요? 에이전트가 동일한 자격 증명 (credential)으로 거절된 트랜잭션을 재시도할 수 있어야 할까요?

프로덕션 시스템 (production system)은 이러한 사례들에 대한 정책이 필요합니다. "카드는 지출 한도가 있다"는 설계의 시작일 뿐입니다.

카드 데이터는 카드가 활성화되어 있는 동안에도 민감한 상태로 유지됩니다. 일회용 자격 증명 (single-use credentials)은 여전히 프롬프트 (prompts), 모델의 영구 메모리 (persistent model memory), 분석 이벤트 (analytics events), 그리고 일반적인 애플리케이션 로그 (application logs)에 노출되지 않도록 관리해야 합니다. 이상적으로는 브라우저 자동화 레이어 (browser automation layer)가 모델에 직접 노출하지 않고 보호된 채널을 통해 세부 정보를 전달받아야 합니다.

가상 카드가 유용한 경우

가상 카드는 에이전트가 전통적인 카드 결제 방식만을 지원하는 가맹점과 상호작용해야 할 때 유용합니다.

양측 모두 이미 머신 네이티브 결제 방식 (machine-native payment method)을 지원하는 경우에는 유용성이 떨어집니다. 동일한 서비스를 x402나 다른 프로그래밍 가능한 레일 (programmable rail)을 통해 요청당 결제할 수 있다면, 브라우저를 통해 카드로 API 비용을 지불하는 것은 불필요한 단계를 추가하는 것이 됩니다.

따라서 실용적인 결제 스택 (payment stack)은 다음과 같은 여러 방식을 지원할 수 있습니다:

• 기존 온라인 가맹점을 위한 카드 결제
• API를 위한 HTTP 레벨 결제
• 에이전트 간 정산을 위한 직접 송금
• 추가 검증이 필요한 트랜잭션을 위한 인간 개입 (human handoff)

에이전트는 모든 트랜잭션을 동일한 프로세스로 강제하기보다, 판매자가 지원하는 방식에 따라 레일 (rail)을 선택할 수 있습니다.

주요 설계 원칙

AgentCard의 핵심 아이디어는 AI가 자신만의 브랜드 카드를 갖는 것이 아닙니다.

핵심은 결제 권한 (payment access)이 작업 (task)으로부터 생성되어야 한다는 점입니다.

사용자가 목적과 예산을 승인하면, 시스템은 해당 승인을 제한된 자격 증명 (restricted credential)으로 변환합니다. 에이전트는 체크아웃 (checkout) 과정에서 이를 사용하며, 더 이상 필요하지 않게 되면 해당 자격 증명은 제거됩니다.

이는 영구적인 카드를 공유하고 에이전트가 지침을 따르기만을 기대하는 것보다 훨씬 더 작은 보안 경계 (security boundary)를 형성합니다.

가상 카드 (Virtual cards)가 에이전트 네이티브 결제 (agent-native payments)를 대체하지는 않을 것입니다. 가상 카드는 다른 문제를 해결합니다. 즉, 에이전트에게 사용자의 기본 결제 자격 증명 (primary payment credentials)에 대한 무제한 접근 권한을 부여하지 않으면서도, 에이전트가 기존 카드 네트워크를 여전히 사용하는 가맹점으로부터 구매할 수 있도록 허용하는 것입니다.