아키텍처

실행 증명 없는 정산은 유료 블랙박스: 에이전트 결제 감사 루프 닫기

글쓴이: IdeaBosque최종 업데이트: 2026年7月30日

핵심 요점

x402는 첫 해에 Base에서 1억 6,900만 건의 에이전트 결제를 처리했지만, payment_hash가 증명하는 것은 거래가 정산되었다는 사실뿐——에이전트가 무엇을 했는지가 아니다——영수증 확장(OMA3/x402, 프로토콜에 통합)은 누가 지불했는지, 어떤 서비스에 접근했는지, 언제, 결제 참조를 기록하지만, 서버 측에서 어떤 스크리닝 버전, 정책 규칙, 모델 버전이 실행되었는지는 기록하지 않는다(Chainalysis, 2026; OMA3, 2026).
IETF action_ref 드래프트(draft-etcheverry-action-ref-02, 2026년 7월)는 콘텐츠 주소 지정 식별자를 정의한다——agent_id, action_type, scope, timestamp의 정규 JSON에 대한 SHA-256——발행자를 신뢰하지 않고 감사인이 재계산할 수 있는——정책 버전 감사 가능성을 위한 선택 필드를 포함하여, 감사인은 규칙 7이 발화했는지뿐 아니라 그 순간에 활성화된 규칙 7의 버전도 확인할 수 있다.
IETF x402-retention-chain 드래프트(draft-hopley-x402-retention-chain-06, 2026년 6월)는 구성을 형식화한다: Settlement-Action Binding(binding_ref)이 payment_hash와 action_ref를 하나의 영수증에 바인딩한다——더해 Policy Binding(policy_bound_ref)이 governing 정책 버전을 액션에 바인딩하고, Compliance Gate Binding(gate_ref)이 ALLOW/REFER/DENY 판정을 정책 참조에 바인딩한다.
모든 구성은 SHA-256과 JCS(RFC 8785)만 사용하며, 영수증을 보유한 어떤 당사자도 발행자에 연락 없이 검증할 수 있다——MiCA 제80조, DORA 제14조, AMLR 제56조 감사 추적 요건을 충족한다(IETF draft-hopley-x402-retention-chain-06, 2026).
실행 증명 없는 정산은 유료 블랙박스; 정산 없는 실행 증명은 검증 불가능한 주장; 에이전트에는 신뢰 루프를 닫기 위해 둘 다 필요하다——x402는 교환을 정산하고, action_ref는 실행 컨텍스트를 바인딩하며, binding_ref는 이들을 하나의 감사 가능한 영수증으로 구성한다.

문제: 여섯 개 프로토콜, 실행 영수증 제로

에이전트 상거래 스택은 2026년에 수렴했다: UCP(발견), A2A(통신), MCP(도구), ACP(체크아웃), AP2(인가), x402(정산). 6개 계층, 60개 이상의 런칭 파트너——Google, Shopify, OpenAI, Stripe, Visa, Coinbase. 모든 구매가 커버된다: 에이전트가 발견하고, 협상하고, 도구를 사용하고, 체크아웃하고, 인가를 받고, 지불한다.

한 가지를 제외하고: 에이전트가 실제로 해야 할 일을 했다는 증명.

x402는 결제를 정산한다. payment_hash는 거래가 Base에서 약 200ms 만에 완료되었음을 증명한다. x402 영수증 확장(OMA3/x402 협업을 통해 프로토콜에 통합)은 서명된, 휴대 가능한 구매 증명을 추가한다——누가 지불했는지, 어떤 서비스에 접근했는지, 언제, 결제 참조. 이 영수증은 서비스에 의해 디지털 서명되고, 변조 방지되며, 보편적으로 검증 가능하다.

서비스 내부에서 무슨 일이 일어났는지는 기록하지 않는다. 영수증은 에이전트가 지불했음을 증명한다. 어떤 스크리닝 버전이 실행되었는지, 어떤 정책 규칙이 발화했는지, 어떤 모델 버전이 결정을 생성했는지는 증명하지 않는다. 벤더 컴플라이언스 검사의 경우, 영수증은 에이전트가 스크리닝 API 호출에 대해 지불했음을 증명한다. 어떤 버전의 스크리닝 로직이 실제로 실행되었는지는 증명하지 않는다.

규제 대상 조달——EU AI Act 제12조, 2026년 8월 2일 시행, FCA SYSC 9.1, SOC 2 CC7.x——에 대해, 그 갭은 컴플라이언스 블로커이다. 로그는 재작성될 수 있다. 실행에 바인딩되지 않은 결제 영수증은 유료 블랙박스이다.

해결책: 정산과 실행을 구성하는 두 개의 IETF 드래프트

action_ref — 콘텐츠 주소 지정 실행 식별자

IETF action_ref 드래프트(draft-etcheverry-action-ref-02, 2026년 7월 23일)는 에이전트 액션에 대한 결정적 콘텐츠 주소 지정 식별자를 정의한다. 식별자는 다음과 같이 계산된다:

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

JCS는 JSON Canonicalization Scheme(RFC 8785)이며, 임의의 JSON 값에 대해 고유한 바이트 시퀀스를 생성한다. 네 개의 사전 이미지 필드:

필드	캡처 내용
`agent_id`	위임 해결 후의 단말 실행자(A→B→C 체인에서 agent_id는 C)
`action_type`	의미론적 라벨(`payment.send`, `compliance.screen`, `oracle.signal`)
`scope`	액션 시점의 에이전트 요청 의도 범위
`timestamp`	RFC 3339 UTC, 정확히 3밀리초 자리

설계 목표는 운영자 독립성: 네 필드를 보유한 검증자는 발행자의 인프라를 호출하지 않고 action_ref를 재계산할 수 있다. 드래프트는 정책 순환 감사 가능성을 위한 선택 필드를 포함한다——감사인은 규칙 7이 발화했는지뿐 아니라 그 순간에 활성화된 규칙 7의 버전도 확인할 수 있다.

x402-retention-chain — 바인딩 계층

IETF x402-retention-chain 드래프트(draft-hopley-x402-retention-chain-06, 2026년 6월 24일)는 일곱 개의 암호학적 구성을 정의한다. 세 가지가 결제 → 정산 → 감사 루프에 직접 관련된다:

Settlement-Action Binding(binding_ref)——x402의 payment_hash를 action_ref에 하나의 영수증으로 바인딩한다. 정산 증명은 이제 결제가 발생했을 뿐 아니라 어떤 검증된 에이전트 액션에 해당하는지도 증명한다. 영수증을 보유한 감사인은 payment_hash에서 action_ref를 거쳐 액션 기록까지 체인을 따라, 발행자에 연락 없이 둘 다 확인한다.
Policy Binding(policy_bound_ref)——governing 정책의 콘텐츠 주소 지정 스냅샷을 액션에 바인딩한다. 스크리닝 결정은 결정이 내려졌을 때 시행 중이던 정확한 정책 버전에 대해 검증 가능하다. 정책 순환은 재계산으로 검색 가능하다——정책이 변경되면 해시가 변경되고, 감사인은 전환을 본다.
Compliance Gate Binding(gate_ref)——ALLOW/REFER/DENY 컴플라이언스 판정과 PII 없는 결제자 참조를 정책 참조에 바인딩한다. 스크리닝 결과는 그것을 생성한 규칙 버전에 검증 가능하게 바인딩되며, 바인딩된 기록에 개인 데이터는 없다.

모든 구성은 SHA-256과 JCS만 사용한다. 외부 인프라 불필요. 발행자에 연락 불필요. 영수증을 보유한 어떤 당사자도 검증할 수 있다.

감사 루프: 결제 → 정산 → 감사 가능 로그

규제 대상 에이전트 상거래 거래의 완전한 루프:

결제——에이전트가 유료 API(벤더 컴플라이언스 스크리닝, 공급업체 검증, 제품 조회)를 호출한다. 서버는 HTTP 402와 결제 조건을 반환한다.
정산——에이전트가 인가에 서명하고, PAYMENT-SIGNATURE로 재시도하고, 퍼실리테이터가 검증하여 Base에서 약 200ms 만에 정산한다. 서버는 payment_hash를 포함한 정산 영수증과 함께 리소스를 반환한다.
실행——에이전트가 액션(스크리닝, 조회, 결정)을 수행한다. action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))를 발행한다——네 개의 사전 이미지 필드에서 어떤 제3자도 재계산할 수 있는 콘텐츠 주소 지정 식별자.
바인딩——binding_ref가 payment_hash와 action_ref를 하나의 영수증에 연결한다. policy_bound_ref가 governing 정책 버전을 액션에 연결한다. gate_ref가 컴플라이언스 판정을 정책 참조에 연결한다.
감사——감사인(규제자, 거래 상대방, 내부 컴플라이언스)이 구성된 영수증을 보유한다. 네 필드에서 action_ref를 재계산한다. payment_hash를 Base 블록체인에 대해 검증한다. policy_bound_ref를 확인하여 스크리닝이 올바른 정책 버전에서 실행되었는지 확인한다. gate_ref를 확인하여 판정이 일치하는지 확인한다. 운영자 호출 불필요. 신뢰 불필요.

루프는 답한다: 결제 정산됨, 이 특정 스크리닝 버전 실행됨, 이 정책 버전 하에서, 이 타임스탬프에, 이 판정과 함께. 두 계층, 하나의 영수증.

각 계층 단독으로 실패하는 이유

아래 다이어그램은 전체 루프——결제, 정산, 실행, 바인딩, 감사——와 각 계층 단독으로 불충분한 이유를 보여준다:

실행 증명 없는 정산은 유료 블랙박스이다. 영수증은 에이전트가 컴플라이언스 스크리닝에 대해 지불했다고 말한다. 어떤 버전의 스크리닝 로직이 실행되었는지, 정책이 최신이었는지, 판정이 올바랐는지는 말하지 않는다. 규제자가 "이 벤더를 2026년 7월 제재 목록으로 스크리닝했는가, 6월 목록으로 했는가?"라고 물어도 payment_hash만으로는 답이 없다.

정산 없는 실행 증명은 검증 불가능한 주장이다. 에이전트는 벤더를 스크리닝했다고 말한다. 스크리닝을 정산된 거래에 바인딩하는 결제 영수증이 없으면, 스크리닝이 실제로 발생했다는 경제적 증거가 없다. 주장은 무료로 할 수 있고 감사에는 가치가 없다.

조합이 신뢰 루프를 닫는다. 정산은 경제적 이벤트를 앵커한다——자금이 이동했다는 증명. 실행 증명은 의미론적 이벤트를 앵커한다——무엇이 되었는지의 증명. 바인딩이 그것들을 연결한다. 감사인은 하나의 영수증에서 둘 다 검증하며, 체인의 어떤 당사자도 신뢰하지 않고 해시를 재계산한다.

B2B 빌드에서의 의미

주문을 내고, 결제를 인가하고, 벤더를 스크리닝하는 조달 에이전트는 그 감사 추적에 완전한 루프가 필요하다. 아키텍처:

x402는 정산을 처리한다. 에이전트는 벤더 컴플라이언스 API에서 402 응답을 받고, Base에서 USDC로 지불하며, payment_hash를 포함한 정산 영수증을 수령한다.
action_ref는 실행 식별자를 처리한다. 에이전트는 각 컴플라이언스 스크리닝 액션에 대해 action_ref를 발행하고, agent_id, action_type(compliance.screen), scope(벤더 ID와 스크리닝 유형), timestamp를 기록한다.
binding_ref가 그것들을 구성한다. 정산 영수증은 하나의 엔벨로프에서 payment_hash와 action_ref를 운반한다. policy_bound_ref는 어떤 정책 버전이 스크리닝을 거버닝했는지 기록한다. gate_ref는 ALLOW/DENY 판정을 기록한다.
감사 추적은 구성된 영수증 체인이다. 감사인은 네 필드에서 action_ref를 재계산하고, payment_hash를 온체인에서 검증하고, 정책 버전 해시를 확인하고, 판정을 확인한다——모두 에이전트 운영자, 결제 퍼실리테이터, 스크리닝 서비스에 연락 불필요.

규제 산업——제약 GMP 컴플라이언스, 항공우주 ITAR 스크리닝, 금융 서비스 제재 검사——에 대해, 이것은 감사 가능한 에이전트와 컴플라이언스 책임 에이전트의 차이이다. EU AI Act 제12조 기록 보존 요건(2026년 8월 2일 시행)은 AI 시스템 결정의 추적 가능성을 요구한다. MiCA 제80조는 거래 기록을 요구한다. DORA 제14조는 운영 회복탄력성을 위한 감사 추적을 요구한다. binding_ref 구성은 하나의 영수증에서 셋 모두를 충족한다.