ERC-8004와 KYA 에이전트 신뢰 계층
도입
에이전트 결제에서 "agent가 지갑을 가지고 있다"는 사실은 신뢰의 출발점일 뿐이다. 실제 제품은 더 많은 질문에 답해야 한다. 이 agent는 누구를 대표하는가, 어떤 endpoint가 이 agent와 연결됐는가, 이전 사용자들이 어떤 feedback을 남겼는가, 고위험 행동은 누가 검증했는가, 결제가 실패하거나 악성 행동이 발생하면 어떤 증거로 조사할 수 있는가.
ERC-8004는 이 질문 중 "조직 경계 밖 agent를 발견하고 신뢰 신호를 읽는 방법"을 다룬다. A2A는 agent끼리 대화하고 task를 주고받는 통신 계층이고, x402는 HTTP 요청 단위의 stablecoin 결제 계층이다. KYA는 표준 EIP가 아니라 운영 프레임이다. agent가 어떤 주체를 대표하고 어떤 권한으로 행동하는지, 그 권한을 어떻게 감사할지 정리하는 정책 언어로 보는 편이 정확하다.
학습 목표
- ERC-8004의 Identity, Reputation, Validation Registry가 각각 어떤 신뢰 증거를 담당하는지 설명한다.
- KYA를 에이전트 결제 승인 정책, 감사 증거, 운영 중단 조건으로 연결한다.
- A2A, x402, ERC-8004, KYA가 같은 문제를 푸는 것이 아니라 서로 다른 경계를 맡는다는 점을 구분한다.
개념 설명
Communication
- A2A Agent Card로 skill과 endpoint를 발견한다
- MCP는 tool과 resource 접근을 노출한다
- 이 계층만으로는 agent의 소유자나 결제 권한을 증명하지 못한다
Onchain trust
- ERC-8004 Identity Registry가 agentId와 agentURI를 연결한다
- Reputation Registry는 client feedback과 hash pointer를 남긴다
- Validation Registry는 독립 검증 결과를 requestHash 단위로 추적한다
Payment policy
- KYA 정책은 principal, permission, constraint, audit trail을 요구한다
- x402 requirement는 resource, amount, payee, network를 고정한다
- session key와 backend policy가 자동 승인 범위를 제한한다
ERC-8004의 공식 상태는 Draft다. 따라서 제품 문서에는 "표준이 확정됐다"가 아니라 "draft standard와 reference implementation을 기준으로 설계한다"라고 적어야 한다. 이 구분은 중요하다. EIP 상태, 참조 구현 배포, 커뮤니티 채택은 서로 다른 증거다.
ERC-8004는 세 개의 registry를 중심으로 구성된다.
| Registry | 담당하는 질문 | 제품에서 남길 증거 | 주의할 점 |
|---|---|---|---|
| Identity Registry | 이 agent를 어떤 onchain identifier로 가리키는가 | agentRegistry, agentId, agentURI, verified endpoint | NFT 소유권이 법적 책임을 자동 부여하지 않는다 |
| Reputation Registry | 누가 어떤 feedback을 남겼는가 | client address, score, tag, offchain evidence hash | 점수 집계는 sybil과 담합에 취약하다 |
| Validation Registry | 누가 어떤 작업 결과를 검증했는가 | request hash, validator address, response, evidence URI | validator incentive와 slashing은 registry 밖의 문제다 |
Identity Registry는 agent를 ERC-721 token처럼 등록한다. tokenId가 agentId가 되고, tokenURI에 해당하는 agentURI가 registration file을 가리킨다. 이 file 안에는 A2A Agent Card URL, MCP endpoint, ENS, DID, email, x402 지원 여부 같은 endpoint 정보가 들어갈 수 있다. 다만 endpoint가 적혀 있다고 해서 그 endpoint가 안전하다는 뜻은 아니다. HTTPS endpoint를 신뢰하려면 /.well-known/agent-registration.json이 같은 agentRegistry와 agentId를 가리키는지 확인해야 한다.
Identity Registry에는 agentWallet이라는 reserved metadata도 있다. 이 wallet은 결제 수신 주소나 agent가 client로 feedback을 남길 때 사용할 주소로 읽힐 수 있으므로, 단순 문자열 업데이트가 아니라 EIP-712 또는 ERC-1271 방식의 control proof가 필요하다. NFT ownership이 이전되면 기존 wallet binding은 초기화되는 것으로 보고 새 owner가 다시 검증해야 한다.
Reputation Registry는 feedback을 표준 형태로 남긴다. 핵심은 단일 별점이 아니다. tag1, tag2, value, decimals, evidence URI, hash를 통해 "어떤 client가 어떤 기준으로 어떤 평가를 남겼는가"를 추적할 수 있게 하는 것이다. 좋은 제품은 이 데이터를 바로 평균 내지 않는다. getSummary를 읽을 때도 신뢰할 client address 집합을 비워두지 않고, paid interaction 증거, feedback revocation 여부, dispute response까지 함께 본다.
Validation Registry는 agent가 수행한 작업을 독립 검증자에게 맡기고 그 결과를 onchain에 남기는 구조다. 고위험 결제, code generation, market action, compliance decision처럼 실패 비용이 큰 작업에서는 reputation보다 validation이 더 강한 증거가 된다. 단, ERC-8004 자체가 검증자 보상, 슬래싱, 법적 책임을 해결하지 않는다. 참조 구현 문서도 Validation Registry가 TEE 커뮤니티와 계속 논의되는 영역이라고 경고하므로, production 정책에는 fallback과 version check를 넣어야 한다.
KYA는 이 registry들을 제품 정책으로 묶는 이름에 가깝다. 이 강의에서는 KYA를 다음 네 항목으로 좁혀 쓴다.
| KYA 항목 | 결제 시스템에서의 의미 | 자동 승인 전 확인 |
|---|---|---|
| Principal | agent가 대표하는 사용자, 팀, 법인, smart account owner | owner verified, account status, sanctions/KYT status |
| Permission | 어떤 행동과 지출이 허용됐는가 | session scope, method allowlist, daily cap |
| Constraint | 시간, chain, token, merchant, resource 제한 | CAIP-2 network, token address, expiry, payee |
| Audit trail | 문제가 생겼을 때 재구성할 증거 | request hash, receipt, feedback, validation response |
이 네 항목을 갖추지 못한 agent는 결제 능력이 있어도 자동 승인 대상으로 보지 않는다. user intent가 불명확하거나, endpoint domain이 검증되지 않았거나, Reputation Registry에 신뢰할 client feedback이 없거나, Validation Registry에서 고위험 task 검증이 없는 경우에는 사람 검토 또는 차단으로 보내야 한다.
코드로 확인하기
trust layer는 문서에서만 끝나면 안 된다. checkout backend는 payment requirement를 만들기 전에 agent trust profile을 평가해야 한다.
백엔드Agent registration file 예시
{ "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1", "name": "stablecoin-research-agent", "description": "Stablecoin liquidity reports and paid risk summaries", "image": "https://example.com/agents/stablecoin-research.png", "services": [ { "name": "A2A", "endpoint": "https://agent.example/.well-known/agent-card.json", "version": "1.0.0" }, { "name": "MCP", "endpoint": "https://agent.example/mcp", "version": "2025-06-18" } ], "x402Support": true, "active": true, "registrations": [ { "agentRegistry": "eip155:8453:0x8004000000000000000000000000000000000000", "agentId": 42 } ], "supportedTrust": ["reputation", "tee-attestation"]}이 file은 agent가 어떤 endpoint와 연결되는지 보여주는 공개 명세다. 제품에서는 이 JSON을 그대로 신뢰하지 않고, HTTPS domain verification, owner wallet proof, registry event, endpoint health check를 함께 묶어 trust profile을 만든다.
백엔드ERC-8004/KYA trust gate
type AgentTrustProfile = { agentRegistry: string; agentId: string; endpointDomainVerified: boolean; principalVerified: boolean; permissionScopes: string[]; maxAutoSpendUsd: number; reputation: { trustedClientSamples: number; successRateBps: number; revokedFeedbackCount: number; }; validation: { requiredForHighRisk: boolean; latestResponse?: number; };};type AgentPaymentRequest = { network: `eip155:${number}`; resource: string; amountUsd: number; method: string; highRisk: boolean;};function decideAgentTrust(profile: AgentTrustProfile, request: AgentPaymentRequest) { if (!profile.agentRegistry.startsWith("eip155:")) return "block"; if (!profile.endpointDomainVerified || !profile.principalVerified) return "review"; if (!profile.permissionScopes.includes(request.method)) return "block"; if (request.amountUsd > profile.maxAutoSpendUsd) return "review"; if (profile.reputation.trustedClientSamples < 5) return "review"; if (profile.reputation.successRateBps < 9500) return "review"; if (profile.reputation.revokedFeedbackCount > 2) return "review"; if (request.highRisk && profile.validation.requiredForHighRisk && (profile.validation.latestResponse ?? 0) < 90) { return "review"; } return "allow";}이 함수는 ERC-8004 registry를 직접 호출하지 않아도 설계 방향을 보여준다. product backend는 indexer가 읽어온 agentRegistry, endpoint verification, reputation summary, validation response를 하나의 profile로 정규화한 뒤 x402 결제 승인 정책에 넣는다.
운영KYA 기반 agent payment policy
agent_trust_policy: draft_standard_note: "ERC-8004 is treated as a draft trust signal, not as legal identity." auto_approve_requires: identity: registry_namespace: "eip155" endpoint_domain_verified: true principal_verified: true permission: session_scope_required: true allowed_methods: - read_paid_report - fetch_market_quote max_auto_spend_usd: 25 reputation: trusted_client_samples_min: 5 success_rate_bps_min: 9500 revoked_feedback_max: 2 validation: high_risk_requires_response_min: 90 review_queue: - new_agent_without_feedback - unverified_endpoint_domain - amount_above_auto_limit - high_risk_without_recent_validation always_block: - wrong_chain_or_token - missing_principal - method_outside_session_scope정책 파일의 핵심은 KYA를 "좋아 보이는 badge"로 쓰지 않는 것이다. principal, permission, constraint, audit trail 중 하나라도 비어 있으면 자동 결제 경로에서 제외한다.
인덱서feedback과 validation evidence 정규화
select agent_registry, agent_id, count(*) filter (where tag1 = 'paid_request_success') as trusted_client_samples, avg(value) filter (where tag1 = 'successRate') as success_rate_bps, count(*) filter (where revoked_at is not null) as revoked_feedback_count, max(validation_response) filter (where validation_tag = 'high_risk_task') as latest_high_risk_validationfrom agent_trust_eventswhere observed_at >= now() - interval '30 days'group by agent_registry, agent_id;registry event를 그대로 UI에 노출하면 학습자가 판단하기 어렵다. indexer는 여러 event를 제품 정책이 읽을 수 있는 trust profile로 바꿔야 한다. 이때 "누가 feedback을 남겼는가"가 빠지면 sybil feedback을 평균에 섞게 된다.
강의 포인트
| 관점 | 확인할 질문 | 산출물 |
|---|---|---|
| 표준 경계 | ERC-8004가 해결하는 문제와 해결하지 않는 문제를 구분했는가 | protocol boundary table |
| 신원 | agentId, agentRegistry, endpoint domain, owner wallet을 별도 증거로 봤는가 | identity evidence checklist |
| 평판 | feedback을 평균 점수가 아니라 증거 묶음으로 해석했는가 | reviewer trust policy |
| 검증 | 고위험 작업에 validation response를 요구했는가 | validation threshold policy |
| 결제 | x402 requirement와 KYA trust gate가 연결됐는가 | checkout approval rule |
실무 예시
데이터 리서치 agent가 GET /reports/stablecoin-liquidity API를 x402로 구매한다고 가정한다. API 서버는 402 response를 보내기 전에 agent를 그대로 믿지 않는다. 먼저 A2A Agent Card에서 service endpoint를 확인하고, ERC-8004 Identity Registry에서 agentURI와 agentId를 읽고, endpoint domain이 같은 registration을 가리키는지 확인한다. 그 다음 KYA 정책으로 principal과 session scope를 확인한다. 이 조건을 통과해야 x402 payment requirement를 만들고, 결제 후 receipt를 ledger에 남긴다.
| 단계 | 시스템 | 실패하면 |
|---|---|---|
| agent discovery | A2A/MCP endpoint | endpoint가 불명확하면 결제 requirement를 만들지 않는다 |
| identity binding | ERC-8004 Identity Registry | agentURI와 endpoint 증거가 어긋나면 review로 보낸다 |
| trust scoring | Reputation/Validation Registry | feedback이 부족하거나 high risk 검증이 없으면 cap을 낮춘다 |
| policy approval | KYA policy engine | principal 또는 permission이 비면 block한다 |
| payment | x402 + session key | resource, amount, payee, network가 바뀌면 서명하지 않는다 |
| evidence loop | receipt, feedback, validation | 성공/실패 결과를 다음 trust decision에 반영한다 |
이 흐름에서 ERC-8004는 결제 영수증이 아니다. x402도 agent 신원 체계가 아니다. KYA도 onchain registry가 아니다. 세 계층을 섞어 말하면 "서명된 결제니까 trusted agent다" 같은 잘못된 결론이 나온다.
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| ERC-8004 agentId가 있으면 안전한 agent라고 본다. | agentId는 발견 가능한 handle이다. endpoint 검증, feedback, validation, policy가 추가로 필요하다. |
| x402 결제가 성공하면 agent의 의도도 검증됐다고 본다. | x402는 payment rail이다. user intent와 agent permission은 별도 정책으로 확인한다. |
| KYA는 KYC를 agent에게 그대로 복사하면 된다고 본다. | agent는 사람보다 빠르게 복제되고 업데이트되므로 owner, version, scope, revocation을 따로 추적해야 한다. |
| Reputation Registry 평균 점수만 보면 된다고 본다. | reviewer 신뢰도, paid interaction 여부, revocation, dispute response를 함께 봐야 한다. |
| Validation Registry가 있으면 모든 작업을 자동 신뢰할 수 있다고 본다. | validator 선택, incentive, evidence 품질, response freshness는 별도 설계가 필요하다. |
| Draft 표준을 production 의존성으로 바로 고정한다. | fallback policy와 migration path를 문서화하고, 표준 상태 변화를 주기적으로 확인한다. |
실습 과제
- Agent Trust 경계표 작성: A2A, ERC-8004, KYA, x402가 각각 맡는 경계와 맡지 않는 경계를 표로 정리한다.
- ERC-8004 등록 파일 초안 작성: agentURI가 가리킬 registration JSON 초안을 만들고 service endpoint, agentRegistry, agentId, supportedTrust를 채운다.
- KYA 정책을 결제 승인 조건으로 연결: principal, permission, constraint, audit trail을 x402 결제 승인 전 조건과 사후 감사 증거로 mapping한다.
- x402 결제 전 trust gate 코드 검토: 제공된 trust gate 코드에서 자동 승인, 사람 검토, 차단 조건을 분리하고 누락된 증거를 보강한다.
완료 기준
- Identity, Reputation, Validation Registry 역할을 서로 다른 증거로 구분했다.
- KYA 항목을 principal, permission, constraint, audit trail로 정리했다.
- x402 결제 승인 전 trust gate와 사후 feedback 기록을 연결했다.
근거 자료
- ERC-8004 Trustless Agents: https://eips.ethereum.org/EIPS/eip-8004
- ERC-8004 reference contracts: https://github.com/erc-8004/erc-8004-contracts
- Agent2Agent Protocol specification: https://a2a-protocol.org/latest/specification/
- Coinbase x402 documentation: https://docs.cdp.coinbase.com/x402/welcome
- Know Your Agent identity overview: https://www.entrust.com/resources/learn/know-your-agent