금요일 오후 4시 52분, 기업 재무 서비스에 하나의 지시가 전달됩니다: 이 송장을 결제하십시오. Meridian Labs라는 고객을 대신하여 벤더 지갑으로 48,000달러 상당의 USDC를 송금하십시오. 발신자는 Meridian의 CFO가 아닙니다. 서명된 허가증을 소지한 소프트웨어 조각인 Meridian의 조달 에이전트(procurement agent)입니다.

전화할 수 있는 사람은 없습니다. 결제가 완료되는 순간 그 지급은 되돌릴 수 없습니다. 그리고 올해 사람들이 AI 에이전트에 대해 배운 한 가지 사실은, 일부 에이전트가 해킹당했거나, 혼란 상태에 빠졌거나, 혹은 20분 전에 취소된 권한으로 실행되고 있다는 점입니다.

이 포스트에서는 제가 두 번의 API 호출을 통해 어떻게 그 질문에 답하는지 설명합니다: 무엇이 입력되는지, 무엇이 반환되는지, 왜 모든 답변이 점수(score)가 아닌 서명된 불리언 (signed boolean)인지, 그리고 생성된 API를 신뢰하지 않고 어떻게 직접 서명을 검증할 수 있는지에 대해 다룹니다.

양자 간의 문제 (The two-party problem)

에이전트 결제가 일반적인 체크아웃과 다른 점은 행위자(actor)와 소유자(owner)가 서로 다른 당사자라는 것입니다. 에이전트는 지출하고, 돈은 Meridian의 것입니다. 결제를 실행하는 주체는 이 두 사실이 불일치할 경우 책임을 지게 되는 중간 위치에 있게 됩니다.

따라서 두 개의 서로 다른 지갑에 대한 질문이 발생합니다:

• 에이전트의 지갑 (The agent's wallet): 이것이 등록되고 식별 가능한 에이전트인가? 그리고 본인(principal)으로부터 현재 유효한 권한을 보유하고 있는가?
• 본인의 지갑 (The principal's wallet): 이 뒤에 KYC 인증을 받은 엔티티(entity)가 존재하는가? 그리고 재무 시스템이 실제로 이 결제를 감당할 수 있는가?

증명 (attestation)은 하나의 지갑을 평가하므로, 이는 POST /v1/attest를 두 번 호출하는 것을 의미합니다. 행위자를 위한 영수증 하나, 소유자를 위한 영수증 하나가 필요합니다.

호출 1: 이 에이전트가 행동해도 되는가? (may this agent act?)

에이전트의 지갑에 대해 Base 체인의 상태(chain state)로부터 답변을 받는 두 가지 조건입니다:

POST https://insumermodel.com/v1/attest
X-API-Key: <key>

...

요약된 응답 (예시 값이며, 실제 구조와는 다를 수 있음):

{
  "pass": true,
  "results": [
...

분석할 가치가 있는 몇 가지 필드들:

erc8004_agent는 자신이 증명하는 것에 대해 정직합니다. ERC-8004 등록은 권한 없는 NFT 민팅(minting)이며, 따라서 met: true라는 것은 정확히

기업의 암호화폐 재무 관리(treasuries)는 결코 하나의 체인에만 머물지 않습니다. 콜드 리저브(cold reserve)에는 BTC가 있고, 결제 유동성(payment liquidity)이 있는 Tron에는 USDT가 있으며, XRP Ledger에는 RLUSD가 있고, Base와 Ethereum에서는 USDC가 운영됩니다. 두 번째 호출은 Meridian의 재무 지갑(treasury wallet)을 증명하며, 각 조건은 고유의 chainId를 포함합니다:

{
  "wallet": "0x51fA...Meridian's treasury",
  "xrplWallet": "rN7n...",
...

5개의 체인에 걸쳐 6개의 불리언(boolean) 값이 반환되며, 각 값은 하나의 서명(signature) 아래 블록에 고정되어 있습니다(EVM 체인의 blockNumber, XRPL의 ledgerIndex, Bitcoin의 블록 높이). 단 한 번의 호출로, 단 한 번의 신용(credit)을 얻습니다.

개발자들을 위해 강조하고 싶은 두 가지 세부 사항이 있습니다:

ratio_to_amount는 절대 유효 기간이 지나지 않는 결제 확인 방식입니다. 48,000달러 송장에 맞춰 조정된 고정 임계값(flat threshold)은 480,000달러 송장에는 맞지 않습니다. 비율(ratio) 방식을 사용하면 트랜잭션 금액과 요청당 리스크 배수(risk multiple)를 전달할 수 있으며, 서명된 불리언은 항상 눈앞의 결제 금액에 맞춰 조정됩니다: balance >= multiple * amount.

호출자는 잔액을 절대 알 수 없습니다. 서비스는 운영 계좌가 이 결제 금액의 최소 1.5배를 보유하고 있다는 사실은 알지만, 그것이 72,001달러인지 4,000만 달러인지는 알 수 없습니다. 이러한 비대칭성(asymmetry) 덕분에 거래 상대방이 기꺼이 응답하는 것입니다. (한 가지 문서화된 트레이드오프(trade-off): token_balance 조건에서 머클 증명(Merkle proof) 모드를 사용하면 증명이 잔액 저장 슬롯 자체에 대한 것이기 때문에 호출자에게 원본 잔액이 노출됩니다. 표준 모드에서는 절대 노출되지 않습니다.)

서명을 직접 검증하세요

응답은 ECDSA P-256으로 서명되었습니다. kid는 어떤 스킴(scheme)을 사용하는지 알려줍니다: insumer-attest-v2는 재귀적으로 정렬된 키를 사용하여 {v, id, pass, results, attestedAt}의 도메인 분리된 정규 프리이미지(domain-separated canonical preimage)에 서명합니다. 공개 키는 다음의 표준 JWKS에 있습니다:

따라서 검증은 어떤 JOSE 라이브러리와 문서화된 preimage(전사상)만 있으면 가능하며, 직접 처리하고 싶다면 npm install insumer-verify를 설치하면 됩니다. 요청에 "format": "jwt"를 추가하면 전체 증명(attestation)을 ES256 JWT로 받을 수 있으며, 이는 모든 표준 JWT 라이브러리가 동일한 JWKS를 통해 검증할 수 있어 판결(verdict)의 휴대성을 보장합니다. 즉, 다른 서비스에 전달하기만 하면 해당 서비스가 누구에게도 요청하지 않고 직접 확인할 수 있습니다.

그리고 나중에 블록을 변경할 수 있는 단 하나의 조항에 대해서는, API의 말을 전적으로 믿을 필요가 없습니다. proof: "merkle"와 함께 위임 확인(delegation check)을 요청하면, 응답에 DelegationManager의 취소 슬롯(revocation slot)에 대한 EIP-1186 스토리지 증명(storage proof)이 포함됩니다. 이는 사용자가 신뢰하는 어떤 소스의 블록 헤더와도 대조하여 검증할 수 있습니다. "블록 N 시점 기준으로 취소되지 않음"은 단순한 주장이 아니라 산술적 사실이 됩니다.

API 키가 없어도 되나요? 에이전트가 호출당 비용을 지불할 수 있습니다

제가 가장 적절하다고 생각하는 부분은 이 시스템이 구축된 대상인 머신(machine)은 계정이 필요하지 않다는 점입니다. 인증 헤더 없이 요청을 보내면 API는 HTTP 402 견적(quote)으로 응답합니다. Base 체인에서 EIP-3009 USDC 승인(authorization)에 서명하고, X-PAYMENT 헤더와 함께 재시도하면 증명이 돌아옵니다. 비용은 5센트이며, 지불자에게는 가스비(gasless)가 들지 않고 온체인(on-chain)에서 결제됩니다. 에이전트는 API에 대해 전혀 들어본 적이 없는 상태에서 단 두 번의 HTTP 요청만으로 서명된 위임 판결(delegation verdict)을 보유할 수 있게 됩니다.

이 시나리오보다 훨씬 더 방대한 메뉴

위의 모든 내용은 하나의 구성(composition)일 뿐입니다. 동일한 엔드포인트는 한 번의 호출로 최대 10개의 조건을 처리할 수 있으며, 9가지 조건 유형에 걸쳐 38개 체인에 혼합되어 적용됩니다. 조건 유형에는 토큰 잔액(네이티브 BTC, TRX, XLM, SUI 포함), NFT 소유권(38개 체인 중 34개), 템플릿 또는 로우 스키마(raw schema)에 따른 EAS 증명(attestation), Farcaster 신원, 사용자의 컨트랙트에 대한 임의의 불리언 뷰 호출(hasAccess(address) 스타일), 특정 금액 또는 총 공급량에 대한 비율 규칙, 그리고 여기서 보여준 두 가지 에이전트 상태 유형이 포함됩니다.

답변의 형태는 결코 변하지 않습니다: 특정 블록에서 당신이 작성한 조건과 대조된 지갑 상태 (wallet state), 그리고 서명된 결과입니다. 점수가 아닙니다. 그 누구의 모델도 무엇인가를 가중치로 계산하지 않았습니다. 정책(1.5배 배수, 예비금 하한선, 어떤 증명 (attestation)이 KYC로 간주되는지 등)은 감사자 (auditor)가 읽을 수 있도록 당신의 요청에 그대로 유지되며, 사실 관계는 감사자가 검증할 수 있도록 서명된 상태로 돌아옵니다. 14개월 후, 누군가 왜 당신의 서비스가 봇의 48,000달러 이동을 허용했는지 묻는다면, 당신은 의견을 방어하는 것이 아닙니다. 당신은 산술적 근거를 건네주는 것입니다.

직접 시도해보고 싶다면 문서(Docs)를 확인하세요: verification API reference, state attestation spec. 무료 티어는 이메일 등록 시 하루 100회 읽기가 가능하며, 키를 완전히 건너뛰고 x402 초과 호출에 대해 호출당 비용을 지불할 수도 있습니다.