Confirmation Token (보안 Floor)

mcpweave 의 두번째 핵심 약속은 server-side confirmation token enforcement 입니다 (ADR-030).

문제

MCP 표준의 elicitation/create 메소드는 client 가 명시적으로 지원해야 동작합니다 (2026-05 시점):

Client	Elicitation 지원
Claude Code / Cursor / Codex / VS Code Copilot	✅
Claude Desktop / Continue / Cline / LM Studio	❌

→ Provider 가 elicitation 만 의존하면 절반의 사용자는 보호 없음.

mcpweave 의 해결책

서버측 confirmation token 으로 client 무관 강제:

Agent → mcpweave (no token)
  ↓
mcpweave wrapper:
  1. Phase B: client 가 elicitation 지원? → 시도
       ├─ accept → 즉시 실행 (1-call UX)
       ├─ decline → {declined: true}
       └─ -32601 → Phase A fallback
  2. Phase A: token mint + 425 응답 + summary
       ↓
  Agent → 사용자에게 보여주고 승인 받음
       ↓
  Agent → mcpweave (token 포함 재호출)
       ↓
  validate (op + args_hash + org match) → execute

보호 대상 16개 op (ADR-030 §D3)

A. 외부 수신자 도달 (10)

SOLAPI: send_sms / send_alimtalk / send_friendtalk
Channel Talk: send_message
Gmail: send_message / send_draft
네이버 톡톡: send_text_message / send_image_message / send_carousel / send_quick_reply

B. 영구 삭제 (1)

Google Drive: delete_file

C. Money flow (4)

PortOne: instant_payment / cancel_payment / confirm_payment / pay_with_billing_key

D. 세무 / 법적 (1)

PortOne: issue_cash_receipt

Token 보안 속성

TTL 5분 — confirm 의도 분명한 시간창
Single-use — Redis GETDEL atomic
(op + args_hash + org_id) 바인딩 — token swap 공격 차단
CSPRNG ≥192 bits — 추측 불가능
Audit log — audit_events 5년 (PIPA §29)

Recoverable destructive op 는 보호 X

cafe24 create_product / update_inventory / cancel_order 등은 recoverable (display=F / 이전 값 PUT / 재주문) 이라 token flow 미적용. 자동화 use case (30개 update) 가 confirmation 으로 깨지는 것 회피.

Phase 2 trigger: 실수 호소 ≥3건/월 시 amendment 검토.

문제