에이전트 결제(Agent payments)는 보안 작업보다 더 빠르게 프로토타입에서 인프라 단계로 넘어갔습니다. x402 프로토콜은 현재 1억 3천만 건 이상의 트랜잭션을 처리하고 있으며 Google Cloud, Cloudflare, Stripe 내부에 자리 잡고 있습니다. 지난주 두 편의 논문이 해당 인프라를 정밀 분석했으며, 그중 하나는 프리프린트(preprint)가 아닌 동료 검토(peer-reviewed)를 거친 컨퍼런스 결과물입니다.

ACM SIGOPS ATC '26에 채택된 "Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments" (arXiv:2605.30998) 논문은 공식 x402 SDK 및 프로덕션 배포 환경에 대해 최대 100%에 달하는 리소스 누수 비율(resource-leakage ratios)을 보고했습니다. 이와 함께 발표된 아키텍처 논문인 "Agent-to-Agent Finance" (arXiv:2607.00245)는 지갑 리스크를 일급 채널(first-class channel)로 다루며 다음과 같이 명확히 기술합니다: "악의적인 서비스 설명이 프롬프트 인젝션(prompt injection)을 유발할 수 있으며, 이는 에이전트가 결제 목적을 오해하게 만들어 지갑 권한 부여(wallet authorisation)가 의도하지 않은 송금을 승인하도록 유도할 수 있습니다."

이것은 특정 벤더의 버그가 아닙니다. 구조적인 문제에서 기인합니다.

격차: 동기식 요청, 비동기식 확정성

x402는 밀리초 단위로 응답이 돌아오는 동기식(synchronous) HTTP 요청과, 컨펌(confirmations) 이후에야 확정되는 블록체인 결제(blockchain settlement)를 연결합니다. "클라이언트가 결제했다고 말하는 시점"과 "네트워크가 결제되었다고 동의하는 시점" 사이에는 시간적 창(window)이 존재합니다. 이 창 안에 있는 모든 것은 공격 표면(attack surface)이며, x402 위에서 결제되는 모든 것은 이를 상속받습니다.

ATC '26 논문은 악용 가능한 표면을 네 가지 공격 프리미티브(attack primitives)로 분류합니다. 각각은 해당 격차 내에 존재합니다.

네 가지 프리미티브

교차 리소스 대체 (Cross-resource substitution). 하나의 리소스를 위해 생성된 결제 증명(payment proof)을 다른 리소스에 대해 재사용(replay)합니다. 결제 자체는 실제이지만, 결제와 결제 대상 간의 결합(binding)이 누락된 상태입니다.

중복 결제 레이스 (Duplicate-settlement race). 결제 방송(payment broadcast)과 온체인 확정성(on-chain finality) 사이의 시간 창 동안, 동일한 결제가 리소스를 여러 번 인출합니다. 하나의 결제로 여러 번의 인도가 이루어집니다.

허용액 초과 인출 (Allowance overdraft). 승인된 토큰 허용량 (token allowance)이 해당 트랜잭션의 범위를 넘어 소진되는 현상입니다. 이는 과도하게 넓은 승인 권한을 가진 세션 키 (session keys)가 단 한 번의 승인된 동작을 열려 있는 결제 창 (open tab)으로 변질시키는 지점입니다.

결제 정산 거부 (Denial of settlement). 공격자가 리소스를 소비한 후, 결제가 완료되지 않도록 최종성 (finality)을 차단하거나 지연시키는 방식입니다. 이는 돈을 갈취하는 것이 목적이 아닙니다. 결제 정산을 보류하면서 서비스를 무료로 이용하는 것이 목적입니다.

또한 이 논문은 불가능성 결과 (impossibility result)를 증명합니다: 출력 전용 가격 책정 (output-only pricing) 방식은 정직한 사용자에게 공정하면서 동시에 숨겨진 계산 토큰 (computational tokens)의 인플레이션에 대해 제한적일 수 없습니다. 추론 토큰 채우기 (Reasoning-token stuffing) 문제는 가격 책정 계층 (pricing layer)만으로는 해결할 수 없습니다. 이는 패치해야 할 버그가 아니라 설계상의 경계 (design boundary)입니다.

적합성 테스트 세트 (conformance suite)가 포착하는 것들

네 가지 원시 요소 (primitives) 중 세 가지는 현재 테스트가 가능하며, 이는 오픈 소스 에이전트 보안 하네스 (agent-security-harness, 에이전트 결제 스택 전반에 걸친 532개 테스트)의 기존 벡터들과 매핑됩니다:

**교차 리소스 대체 (Cross-resource substitution)**는 결제를 정확히 하나의 대상에 바인딩함으로써 포착됩니다: FB-015 (Voucher Resource-Hash Binding), X4-044 (Payment Replay Against Different Endpoint), 그리고 AP2-007 (Mandate Chain Link, 결제 위임(mandate)을 특정 체크아웃 해시와 연결함).

**중복 정산 경합 (Duplicate-settlement race)**은 하나의 승인에 대해 두 번째 인도를 거부함으로써 포착됩니다: X4-038 (Double-Spend Detection), AP2-013 (Double-Spend on Open Mandate), FB-017 (Escrow Over-Redemption), 그리고 FB-014 (Batch Voucher Replay and Monotonicity).

**허용액 초과 인출 (Allowance overdraft)**은 승인이 사용할 수 있는 금액을 제한함으로써 포착됩니다: CTK-003 및 CTK-004 (Per-Transaction Amount Cap 및 Cumulative Velocity Cap), FB-011 및 FB-012 (Amount Cap 및 Velocity Budget), 그리고 AP2-015 (Funding-Instrument Scope Binding).

모든 테스트는 '변조 후 거부 (tamper-then-reject)' 차분 방식으로 실행됩니다. 공격 방식과 동일하게 입력을 변조하면, 적합성을 준수하는 구현체는 이를 거부합니다:

PASS  AP2-013: Double-Spend on Open Mandate
PASS  FB-017: Escrow Over-Redemption
PASS  CTK-004: Cumulative Velocity Cap

탐지하지 못하는 것들

결제 거부 (Denial of settlement)에 대한 테스트는 테스트 스위트(suite)에 포함되어 있지 않습니다. 이는 무결성 (integrity) 공격이 아니라 활성 (liveness) 공격입니다. 즉, 악의적인 행위는 페이로드 (payload)를 조작하는 것이 아니라 최종성 (finality)을 보류하는 것입니다. 속도 제한 (Rate-limiting) 벡터는 이와 인접해 있지만 동일하지 않으며, 그렇지 않은 척하는 것은 녹색 테스트 실행 결과가 거짓을 말하게 만드는 '커버리지 연극 (coverage theater)'에 불과합니다. 정직한 상태를 말하자면, 이 공격 클래스는 명명되었고 이해되었으나 현재 테스트되지 않은 상태입니다. 이는 다음에 구축해야 할 벡터입니다.

불가능성 결과 (impossibility result)는 적합성 스위트 (conformance suite)의 범위를 훨씬 더 벗어나 있습니다. 자체 레이어에서 증명 불가능하게 해결할 수 없는 가격 모델에 대해서는 통과/실패 (pass-or-fail) 벡터를 작성할 수 없습니다. 그것은 테스트 커버리지 (test coverage)의 영역이 아니라 프로토콜 설계 (protocol design)의 영역입니다.

레이스 컨디션을 종결짓는 단 하나의 결정

대부분의 중복 결제 레이스 컨디션 (duplicate-settlement race)은 단 하나의 아키텍처적 선택으로 귀결됩니다. 즉, 리소스를 해제하기 전 당신의 스택이 결제를 최종적인 것으로 간주하는 권위 있는 지점 (authoritative point)이 어디인가 하는 점입니다.

만약 그 답이 "조력자(facilitator)의 콜백 (callback)"이라면, 레이스 컨디션은 완전히 열려 있습니다. 왜냐하면 콜백은 체인이 합의하기 전에 실행되기 때문입니다. 만약 그 답이 "N개의 온체인 확인 (on-chain confirmations)" 또는 "서명된 결제 영수증 (signed settlement receipt)"이라면, 당신이 설계한 지연 시간 (latency)을 대가로 하여 그 틈(window)은 닫힙니다.

테스트 커버리지는 당신의 검증기 (verifier)가 조작된 결제를 거부하는지 여부를 알려줍니다. 하지만 당신이 최종성 라인 (finality line)을 어디에 그었는지는 알려줄 수 없습니다. 그 라인이 바로 에이전트 결제의 승패가 갈리는 지점입니다.

만약 x402 위에서 구축한다면, 당신이 탐지할 수 있는 세 가지 프리미티브 (primitives)에 대한 테스트를 배포하고, 탐지할 수 없는 나머지 하나에 대해서는 당신의 최종성 지점을 명시하십시오.

전체 테스트 ID 매핑 및 논의: harness thread #231