에이전트의 지갑에는 서명자(signer)가 아닌 정책(policy)이 필요합니다

AI 에이전트에 지갑을 주면 API 비용을 지불할 수 있습니다. 이 부분은 오늘날 작동합니다. x402 플로우는 간단합니다: 서버가 결제 요구 사항과 함께 402 응답을 보내고, 에이전트가 서명하고, 결제가 정산되며, 리소스가 도착합니다.

문제는 에이전트가 무엇에 서명하느냐입니다. 참고로 x402 클라이언트는 402가 요구하는 모든 금액을 지불합니다. 즉, '서버가 가격을 명시'한 시점과 '지갑이 그것을 결제'한 시점 사이에 체크포인트가 없습니다. 서명자는 설계상 하나의 질문에 답할 뿐입니다: 이 키가 유효한 서명을 생성할 수 있는가? 이는 결제가 이루어져야 하는지에 대해서는 의견을 제시하지 않습니다. 아래의 모든 손실 모드는 에이전트가 지시받은 대로 정확히 작동하면서도, 완벽하게 유효한 서명으로 발생합니다.

그렇기 때문에 에이전트 결제의 제어점은 서명자가 아닙니다. 그것은 서명하기 전에 내려지는 정책 결정입니다: 허용(ALLOW), 거부(DENY) 또는 인간에게 에스컬레이션(ESCALATE)하는 것입니다. 이 글은 그 결정이 포착하기 위해 존재하는 네 가지 실패 모드와, 사전 점검(preflight check)이 실제로 평가하는 것이 무엇인지에 대해 다룹니다.

에이전트가 올바르게 작동하면서 돈을 잃는 네 가지 방법

1. 무한 결제 루프. 엔드포인트가 계속 402를 반환하거나, 에이전트가 실패한 유료 호출을 반복적으로 시도하는 경우입니다. 각 시도는 작고 유효하며, 첫 번째 시도를 승인했던 것과 동일한 논리에 의해 권한 부여됩니다. 손실은 하나의 잘못된 결제가 아니라, 기계 속도로 수백 번 발생하는 동일한 결제액입니다. 서명자는 아무 문제도 발견하지 못합니다. 정책 계층은 빈도 문제를 감지합니다.

2. 악성 엔드포인트를 통한 프롬프트 주입. 에이전트가 오염된 도구 결과, 손상된 페이지, 조작된 지침에 의해 자신이 한 번도 다루어 본 적 없는 엔드포인트에 비용을 지불하도록 유도됩니다. 결제 자체는 잘 구성되어 있습니다. 문제가 있는 것은 거래 상대방과 맥락이며, 이 둘은 서명 기능에는 보이지 않습니다. 하지만 '이 수신자가 이 에이전트, 이 행동, 이 금액에 대해 정책 내에 있는지'를 묻는 점검에서는 보입니다.

3. 금액 환각(Amount hallucination). 모델이 요구사항을 잘못 읽거나, 소수점을 잘못 배치하거나, 단위를 느슨하게 변환하여 의도했던 가격의 100배에 해당하는 서명을 합니다. 서명 유효. 잔액 충분. 결제 완료. 이를 잡아내는 검사는 암호학적(cryptographic)이 아니며, 모델이 아닌 다른 주체가 서명하기 전에 금액을 비교하는 거래별 한도(per-transaction cap)입니다.

4. 빈도 기반 고갈(Frequency-based drainage). 단일 결제는 주목할 만하지 않습니다. 중요한 것은 총합입니다: 하루 동안 동일한 상대방에게 정책을 따르는 것처럼 보이는 수천 건의 소액 결제가 지갑 잔액을 거래별 한도 이하로 떨어뜨립니다. 이것이 왜 거래별 한도만으로는 충분한 정책이 아닌지 보여줍니다. 일일 총합과 비율 역시 호출 간에 지속되는 상태(state)와 비교하여 평가되어야 합니다.

패턴에 주목하세요: 네 가지 경우 모두 서명(signature) 자체에는 아무 문제가 없습니다. 만약 당신의 유일한 통제 지점이 서명자(signer)에게만 있다면, 이러한 실패가 발생하는 시점에서는 어떠한 통제도 할 수 없습니다.

사전 비행 점검이 실제로 평가하는 것

사전 승인 검사(preflight authorization check)는 제안된 결제 — 에이전트, 행동, 상대방, 금액, 그리고 그 결제가 답변하는 지불 의도(payment intent) — 를 가져와서 서명이 존재하기 전에 정책에 따라 평가합니다. 중요한 검사들은 실패 모드(failure modes)와 일대일로 매핑됩니다:

• 거래 및 일일 한도(Limits per transaction and per day). 금액은 액션별 상한선과 총합 일일 상한선과 비교됩니다. 금액 환각(Amount hallucination)은 거래별 상한선에서 멈추고, 빈도 소진(frequency drainage)은 일일 총합에서 멈춥니다. 단, 이 확인 과정이 에이전트가 오늘 이미 지출한 내역을 추적할 때만 가능하며, 이는 정책 계층(policy layer)이 단순히 규칙뿐 아니라 상태(state)를 유지한다는 것을 의미합니다.
• 거래 상대방(Counterparty). 이 수취인이 해당 에이전트가 결제하도록 허가된 엔드포인트인지 확인해야 합니다. 화이트리스트 정책은 주입된 엔드포인트 사례를 정산 대신 거부로 전환시킵니다.
• 의도 바인딩(Intent binding). 승인은 특정 의도—이 결제, 이 액션, 이 요구사항에 대한 것—에 묶입니다. 논스(nonce)와 재전송 방지(replay protection)를 통해 한 결제를 위해 발행된 승인이 다른 것을 승인하는 데 재사용될 수 없으며, 재시도가 동일한 의도에 대해 조용히 두 번째 결제가 될 수 없습니다.
• 빈도(Frequency). 비율과 반복은 결정의 일부로 평가되며, 이것이 루프와 합법적인 반복 구매를 구분하는 요소입니다.

그 후 이 확인 과정은 세 가지 판결 중 하나를 반환합니다:

• 허용(ALLOW) — 결제가 모든 축에서 정책을 준수합니다. 진행됩니다.
• 거부(DENY) — 하드 한도를 위반한 경우입니다: 상한 초과, 거래 상대방 미승인, 재전송 감지. 진행되지 않으며, 거부 기록이 남습니다.
• 상향 조정(ESCALATE) — 명확하게 금지된 것도 아니고, 명확하게 일상적인 것도 아닙니다: 인간 검토를 위해 설정한 임계값을 초과했거나, 정책이 모호하다고 플래그를 지정하는 패턴입니다. 에이전트는 멈추고 제안된 결제를 사람이 승인하거나 거부하도록 제출합니다. 이것이 자율성을 사용 가능하게 만드는 판결입니다: 에이전트는 정의된 범위 내에서 단독으로 행동하고, 인간은 돈이 움직인 후에가 아니라 이 범위의 경계에서 결정합니다.

허용(allow), 거부(deny), 상향 조정(escalate) 등 모든 판결은 감사 추적(audit trail)에 기록됩니다. 나중에 운영자가

Veyline (Payload에서 제작)은 x402 에이전트 결제를 위한 권한 부여 계층입니다. 이는 지갑 자산 관리(non-custodial) 거래 승인으로, 지출 한도, 액션별 제한, 상대방 및 의도 확인을 기반으로 ALLOW / DENY / ESCALATE를 반환하며, nonce/재사용 방지 기능과 모든 결정에 대한 감사 추적(audit trail)을 제공합니다. 이 서비스의 첫 번째 사실은 자산 관리 여부입니다: Veyline은 귀하의 자금을 보유하지 않으며, 귀하의 키도 보유하지 않습니다. 이는 고객 거래를 승인할 뿐이며, 돈을 보관하거나 이동시키지 않습니다. 지갑 보호를 위해 귀하의 키가 필요한 권한 부여 서비스는 그 자체가 되어야만 문제를 해결할 수 있습니다.

이제 현황을 기능만큼 명확하게 설명합니다. 이 분야에서는 발표 내용과 실제로 증명 가능한 범위 사이에 격차가 생겨 구매자들이 피해를 보는 경우가 많기 때문입니다:

• 오늘 증명 가능: Veyline은 Base에서 실제 비보관(non-custodial) 파일럿 정산을 수행했습니다 — $0.01 USDC 거래 두 건으로, 의도적으로 엄격한 파일럿 한도($0.01/거래, 일일 $0.05) 내에서 실행되었으며, 모두 성공적으로 정산되어 온체인에 기록되었습니다. 숫자가 작은 것은 의도적입니다: 이는 제품이 설계된 대로 작동하는 형태 — 제한되고, 승인되고, 기록되는 것입니다.
• 오늘 호출 가능: 사전 비행 결정(preflight decision)을 평가를 위해 노출했습니다 — veyline_preflight는 MCP를 통해 이용 가능하며, 읽기 전용 MCP/A2A 인터페이스와 함께 제공되므로, 아무것도 통합하지 않고도 정책 확인이 어떤 결과를 반환하는지 테스트할 수 있습니다.
• 실시간 사용 불가: 관리형 실행(managed execution). KMS 기반의 서명 경로는 실패 시 폐쇄(fail-closed) 상태이며, 별도의 메인넷 승인을 통과하지 못했습니다. 따라서 관리형 실행의 상업적 배포는 오늘 이용할 수 없습니다. 만약 귀하의 결제가 지금 바로 실행되어야 한다면, Veyline이 솔직하게 답하는 것은 권한 부여 및 사전 비행 계층만 존재한다는 것이지, 즉 원스톱(turnkey) 실행 서비스가 아니라는 것입니다. 저희는 통합 과정에서 이 사실을 발견하시게 하는 것보다 이 문장을 공개하는 것을 선호합니다.

체크리스트

귀하의 통제 하에 있는 에이전트가 다음 결제를 서명하기 전에, 다음 다섯 가지 질문에 모두 답할 수 있어야 합니다:

1. 이 에이전트가 인간의 확인 없이 단일로 할 수 있는 최대 결제액은 얼마이며, 그 금액이 모델 외 다른 곳에서 강제되는 부분이 있습니까?
2. 일일 한도는 얼마이며, 호출 전반에 걸친 누적액을 추적하는 것이 있습니까?
3. 어떤 상대방에게 결제할 수 있습니까? 만약 답변이 '402를 반환하는 모든 엔드포인트'라면, 이는 로드맵과 함께 제시된 주입(injected)-엔드포인트 실패 사례입니다.
4. 각 승인(authorization)은 재사용 방지 기능이 있는 하나의 의도(intent)에 묶여 있습니까? 아니면 재시도가 두 번째 결제가 될 수 있습니까?
5. 에이전트가 거부되거나 에스컬레이션될 경우, 그 기록은 어디에 남겨지며, 나중에 결정 사항을 읽어볼 수 있습니까?

만약 이 질문들에 답할 수 없다면, 귀하의 에이전트는 결제 정책(payment policy)을 가지고 있지 않습니다. 그것은 서명자(signer)와 희망만을 가졌습니다. 서명자는 자신의 역할을 수행하고 있습니다. 다만 그 역할 자체가 필요하지 않았던 것일 뿐입니다.