Your Agent Just Paid for Nothing: 6 Attacks on x402 Payments - Ishween Kaur, SoFi

한 줄 핵심

에이전트가 결제를 대신할 수는 있지만, 가격 조작·중복 결제·무료 이용·가짜 판매자·프롬프트 인젝션 같은 공격을 막는 가드와 추적 없이는 실제 운영에서 안전하게 쓸 수 없다.

시간별 요약

1. 0:00
   소개 agentic payments와 x402를 안전한 환경에서 탐색하며, 결제 가능한 에이전트가 현실적인 공격면을 만든다는 문제의식을 소개한다.
2. 0:31
   한 번만 쓰는 것에 돈을 내는 방식 구독 대신 필요한 만큼만 즉시 결제하는 인터넷 경험을 상상하고, 에이전트가 소액 데이터를 살 때도 예산·승인·용도 확인이 필요하다는 점을 강조한다.
3. 1:33
   HTTP 402와 x402 프로토콜 HTTP의 402는 오랫동안 결제 필요를 표시만 했지 기계가 실제로 결제하는 방법은 없었고, x402가 그 공백을 메우며 소프트웨어를 구매자로 만든다.
4. 2:09
   x402의 작동 방식 buyer, seller, facilitator, chain의 4개 주체로 결제가 흘러가며, 초미세 결제에서는 카드보다 온체인 정산이 더 합리적이라는 구조를 설명한다.
5. 3:24
   에이전트가 결제할 수 있게 되면 생기는 일 에이전트가 코드나 이메일뿐 아니라 돈까지 직접 쓰게 되면, 단순 오작동이 아니라 정상 동작처럼 보여도 비용을 잃는 상황이 생기며, 이를 막기 위한 여러 공격 검증이 필요해진다.
6. 4:05
   공격 1: 가격 조작 디렉터리에 등록된 가격과 실제 402 헤더의 가격이 달라질 수 있어, 결제 직전 가격·지갑·네트워크까지 함께 검증하지 않으면 더 비싼 금액을 승인하게 된다.
7. 5:24
   공격 2: 두 번 결제하기 같은 payment number를 여러 번 보내면 검증 단계에서는 모두 정상처럼 보여도 정산에서는 일부만 인정되므로, 중복 방지를 위한 공유 저장소와 재시도 시 동일 payment number 재사용이 필요하다.
8. 7:03
   공격 3: 공짜 쇼핑 정산 전에 데이터를 내보내면 결제가 되돌려질 수 있고, paywall 밖의 엔드포인트나 공개 캐시를 통해 우회 유출도 가능하므로, 민감도와 비용에 따라 정산 대기·캐시 제어·no store가 필요하다.
9. 9:13
   공격 4: 하나의 결제로 여러 페이지 서로 연결되지 않은 여러 페이지에 같은 결제를 재사용하면 각 페이지는 유효한 요청으로 보고 데이터를 내줄 수 있으므로, shared storage로 지급 이력과 페이지 매핑을 묶어야 한다.
10. 10:04
    공격 5: 닮은꼴 판매자 유사한 이름·도메인·지갑을 가진 가짜 판매자가 더 싸게 보이면 에이전트가 속을 수 있어, 승인 목록과 probation 목록, 인간 검토 절차로 신뢰 범위를 관리해야 한다.
11. 11:43
    공격 6: 프롬프트 인젝션 판매자 응답의 문구가 추가 결제를 유도할 수 있으며, 단순 키워드 필터나 판별 모델만으로는 부족하므로 한 턴에 한 번만 호출하도록 계획을 고정해 피해 범위를 줄여야 한다.
12. 14:10
    안전하게 배포하기 결제는 겉보기엔 맞아 보여도 잘못된 결과를 낼 수 있으므로, 하나의 payment ID로 전체 흐름을 추적하고, 실패·성공 데이터셋으로 에러 분석한 뒤 가드·알림·차단을 단계적으로 적용해야 한다.
13. 16:23
    에이전트에게 결제권을 줄 것인가 에이전트가 결제할 수는 있지만, 어떤 조건에서 허용할지와 무엇을 막아야 하는지를 이해한 뒤에야 실제로 맡길 수 있다.

실무 인사이트

• 에이전트 결제는 '허용/차단'보다 '가격·지갑·네트워크·정산 상태'를 함께 검증하는 다중 가드가 핵심이다.
• 실서비스 적용 전에는 payment ID 하나를 끝까지 추적하는 로그와 실패 사례 기반의 에러 분석을 먼저 구축해야 한다.
• 민감 데이터·라이선스·활성화처럼 손실이 큰 경우에는 성능보다 정산 완료 후 공개를 우선하는 설계가 안전하다.