Agent Payment 위협모델
도입
Agent payment의 핵심 질문은 "agent가 결제할 수 있는가"가 아니다. 핵심은 "agent가 어디까지 결제하지 못하게 막는가"다. x402, ERC-3009, Paymaster, session key, ERC-7579 module은 모두 이 경계를 만드는 재료다.
위협모델은 보안 문서만이 아니다. 제품 요구사항이다. 어떤 API에 얼마까지 결제할 수 있는지, prompt injection이 결제를 유도할 때 어디서 막는지, 결제는 됐지만 서비스가 실패했을 때 어떻게 환불하는지까지 제품 화면과 운영 runbook에 들어가야 한다.
학습 목표
- agent 결제 시스템의 asset, actor, trust boundary를 그린다.
- 오남용, prompt injection, 지출 한도, dispute를 통합 위협모델로 정리한다.
개념 설명
Sponsored gas
정상
agent 결제 시스템의 asset, actor, trust boundary를 그린다.
Policy rejects
주의
paymaster 정책이 설명 가능한가
Session exposure
검토
Agent Payment 위협모델 이해 점검
UserOp failures
대기
위협모델 다이어그램을 만들었다.
medium가정 불일치서명 권한과 지출 한도가 분리되는가
high실패 상태 누락paymaster 정책이 설명 가능한가
watch산출물 미완료Agent Payment 위협모델 이해 점검
각 trust boundary마다 방어가 다르다.
| 경계 | 위협 | 방어 |
|---|---|---|
| Owner to session key | 너무 넓은 권한 발급 | scope, expiry, cap, revoke |
| Agent runtime | prompt injection으로 고가 API 반복 호출 | policy engine, endpoint allowlist |
| x402 server | price, payee, network 바꿔치기 | signed requirement hash, merchant registry |
| Facilitator | 검증 장애 또는 잘못된 settlement | 자체 검증 fallback, receipt reconciliation |
| Token/chain | replay, wrong token, wrong chain | nonce domain, token allowlist, CAIP-2 |
| Smart account module | 악성 module 설치 또는 hook 우회 | module registry, install approval, hook coverage tests |
| Backend ledger | 중복 paid 처리 또는 receipt 누락 | idempotency key, tx hash + log index unique key |
코드로 확인하기
agent payment threat model은 다이어그램으로 끝나면 부족하다. 실제 시스템에는 결제 요청을 분류하고, 자동 승인 가능한 요청과 사람 확인이 필요한 요청을 나누는 코드가 있어야 한다.
백엔드결제 요청 위험 분류
type AgentPaymentIntent = { merchant: string; amount: bigint; asset: "USDC" | "PYUSD"; purpose: string; userVisibleSummary: string;};function classifyAgentPayment(intent: AgentPaymentIntent) { if (intent.userVisibleSummary.length < 20) return "needs_human_review"; if (intent.amount > 100_000_000n) return "large_payment"; if (!intent.purpose.includes("invoice")) return "ambiguous_purpose"; return "auto_approvable";}이 분류는 보안 모델의 첫 번째 방어선이다. agent가 결제 의도를 설명하지 못하면, 서명이 유효해도 제품적으로는 승인하면 안 된다.
운영agent 결제 정책 파일
agent_payment_policy: auto_approve: max_usdc: 100 required_fields: - merchant - invoice_id - user_visible_summary require_human_review: - new_merchant - changed_recipient_address - amount_above_daily_average always_block: - empty_summary - unsupported_asset - expired_invoice정책 파일은 threat model을 운영으로 옮기는 연결점이다. capstone에서는 이 정책이 checkout, session key, x402 흐름에 공통으로 적용되는지 확인한다.
클라이언트사용자가 읽을 수 없는 agent 결제 차단
type AgentReviewCopy = { merchantName?: string; amountLabel?: string; resourceLabel?: string; chainLabel?: string;};function requireHumanReadablePayment(copy: AgentReviewCopy) { const missing = Object.entries(copy) .filter(([, value]) => !value || value.trim().length < 3) .map(([key]) => key); if (missing.length > 0) { return { ok: false, reason: "missing_user_visible_fields", missing }; } return { ok: true, reason: "reviewable" };}agent가 내부적으로 정확한 payload를 만들었더라도, 사용자가 merchant, amount, resource, chain을 읽지 못하면 자동 결제를 허용하지 않는다. UI copy는 단순 설명문이 아니라 지출 권한의 마지막 확인 단계다.
인덱서receipt anomaly 탐지
select agent_id, merchant_id, count(*) as payments, sum(amount_usdc) as total_usdcfrom agent_payment_receiptswhere created_at >= now() - interval '1 hour'group by agent_id, merchant_idhaving count(*) > 10 or sum(amount_usdc) > 100;정책은 요청 시점의 방어고, indexer는 사후 이상 징후를 잡는다. prompt injection이나 merchant misconfiguration은 정상 서명처럼 보일 수 있으므로 receipt 집계가 반드시 필요하다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| asset | 어떤 token, chain, payment method가 위험 자산인가 | asset inventory |
| actor | user, agent, server, facilitator, wallet, module, merchant 역할이 분리됐는가 | actor table |
| boundary | 어느 경계에서 어떤 검증을 하는가 | trust boundary diagram |
| abuse | prompt injection, over-spend, replay, service failure를 다뤘는가 | abuse case table |
| controls | onchain module과 offchain policy가 서로 보완하는가 | control mapping |
실무 예시
agent가 유료 data API를 하루 20 USDC 한도로 사용한다고 가정한다.
| abuse case | 예상 방어 | 실패 시 조치 |
|---|---|---|
| prompt injection이 고가 endpoint 반복 호출 | endpoint allowlist, per-request cap, daily cap | agent stop, receipt audit |
| x402 requirement가 wrong payee로 바뀜 | merchant registry와 requirement hash 검증 | 서명 전 거절 |
| session key 유출 | short expiry, revoke, remaining cap 제한 | key revoke, pending payload invalidation |
| module hook 우회 | hook coverage tests for batch/executor/fallback | emergency uninstall |
| payment settled but API response failed | receipt required, refund/credit queue | dispute workflow |
| wrong chain payment | CAIP-2 check, token address allowlist | policy reject |
| reused nonce | token/backend replay protection | duplicate receipt block |
| facilitator down | self-verify fallback 또는 retry policy | status page, delayed settlement queue |
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| agent 결제는 wallet permission만 있으면 안전하다고 본다. | wallet/module policy와 backend policy engine이 함께 필요하다. |
| prompt injection은 LLM 문제라 결제 설계와 별개라고 본다. | prompt injection은 실제 지출을 유도할 수 있으므로 payment policy의 핵심 위협이다. |
| receipt는 회계용 부가 데이터라고 본다. | receipt는 dispute, refund, 중복 결제 방지, user trust의 근거다. |
| offchain policy가 있으면 onchain hook은 필요 없다고 본다. | server compromise나 replay를 고려하면 onchain spending boundary도 필요하다. |
| cap만 있으면 충분하다고 본다. | cap 외에도 merchant, endpoint, chain, token, method, expiry가 필요하다. |
실습 과제
- Agent Payment 위협모델 이해 점검: asset, actor, trust boundary, abuse case, control, residual risk를 포함한 표를 작성한다.
- end-to-end 위협모델 작성: agent가 x402 유료 API를 구매하는 흐름을 request, policy, signing, settlement, receipt, refund 단계로 나눈다.
- abuse case 8개 작성: prompt injection, malicious merchant, wrong chain, session key leak, module bypass, replay, service failure, facilitator outage를 포함한다.
- 정책과 기술 방어 연결: session key, ERC-7579 hook, backend policy engine, receipt ledger, dashboard alert가 각각 어떤 abuse case를 막는지 mapping한다.
완료 기준
- 위협모델 다이어그램을 만들었다.
- abuse case 8개를 작성했다.
- 정책과 기술 방어를 연결했다.
근거 자료
- Agent Payment 위협모델: 05-계정추상화-에이전트결제/07-Agent-Payment-위협모델.md