ERC-8196 AI 에이전트 인증 지갑 (AI Agent Authenticated Wallet)
Final · 계정·지갑 · 2026-03-14 작성
AI 에이전트가 자산 소유자가 정한 정책을 지켰다는 암호학적 증명이 있을 때만 거래를 실행하는 지갑 표준입니다. 개인키를 넘기지 않고 에이전트에게 권한을 위임할 수 있게 합니다.
왜 필요한가
자율적으로 움직이는 AI 에이전트에게 온체인 작업을 맡기려면 지금은 두 가지 나쁜 선택지뿐입니다. 에이전트가 직접 자금과 개인키를 들고 있으면 에이전트를 돌리는 호스팅 업체가 키를 훔칠 수 있습니다. 반대로 권한만 위임하면 강제할 수 있는 한도가 없고, 에이전트가 규칙을 지켰는지 나중에 확인할 방법도 없습니다. 악의적인 호스트는 에이전트의 출력을 숨기거나 요청을 지연시키고 확률적으로 답하는 에이전트에게 같은 질문을 반복해 유리한 답이 나올 때까지 고르는 식으로 행동을 조작할 수 있습니다. 과거에 제재 대상 자금이나 믹서를 거친 이력이 있는 에이전트가 그대로 권한을 받는 문제, 과거의 유효한 증명을 재사용하는 재전송 공격도 있습니다. 이 표준은 정책 검증을 지갑 계약 안에서 강제해 이런 위험을 줄입니다.
구현해야 하는 것
function revokePolicy(bytes32 policyHash, string calldata reason) external;: 등록된 정책을 사유를 남기고 철회합니다.
심층 설명
신뢰 스택에서의 위치와 ERC-8126 검증 강제
이 표준은 자율 AI 에이전트를 위한 모듈형 신뢰 스택의 2계층(실행)입니다. 1계층(식별과 검증)은 ERC-8126이 맡습니다. 구현체는 에이전트 행동을 실행하기 전에 반드시 ERC-8126 검증을 수행해야 하며 정책의 agentId로 getLatestRiskScore를 조회해 현재 점수가 정책의 minVerificationScore를 초과하면 행동을 거부해야 합니다. 점수는 낮을수록 위험이 낮으며 20이 Low Risk 등급, 0부터 20까지가 허용 범위입니다. 호스팅 서비스, 지갑 UI, 릴레이어 같은 오프체인 구성 요소도 거래 제출 전에 같은 검증을 수행하는 것이 권장됩니다.
정책 구조
정책에는 필수 필드로 policyId(고유 식별자), agentAddress(인가된 에이전트 주소), agentId(ERC-8126 조회 키), ownerAddress(자산 소유자), allowedActions(허용 행동 목록, 예: transfer, swap), allowedContracts(대상 컨트랙트 화이트리스트), blockedContracts(블랙리스트), maxValuePerTx(건당 최대 금액, wei 단위), validAfter와 validUntil(활성화·만료 시각), minVerificationScore(요구되는 최소 ERC-8126 검증 점수)가 들어갑니다. maxValuePerDay(일간 지출 한도)는 선택 필드입니다.
EIP-712 서명과 정책 해시 바인딩
에이전트의 행동은 AgentAction 타입으로 서명합니다. 이 타입은 agent, action, target, value, data, nonce, validUntil, policyHash, entropyCommitment 필드를 포함합니다. 위임 자체는 delegator, delegatee, policyHash, validUntil, nonce를 담는 Delegation 타입으로 서명합니다. 두 타입 모두 policyHash를 포함하므로 서명된 행동과 위임이 특정 정책에 변경 불가능하게 묶입니다. 서명 검증에 실패하면 InvalidSignature 오류가 발생합니다.
엔트로피 커밋-리빌
확률적으로 답하는 에이전트는 악의적인 호스트가 같은 요청을 반복 샘플링해 자신에게 유리한 결과를 고르는 방식으로 조작될 수 있습니다. 이를 막기 위해 executeAction에는 entropyCommitment(엔트로피 약속값)가 들어가고 공개된 값이 약속값과 맞지 않으면 EntropyVerificationFailed 오류로 거부됩니다. 다만 원문은 호스트 조작이 확률적 위험으로 남는다고 인정하며 고가치 에이전트에는 독립적인 호스트 여러 곳을 쓰는 것을 권장합니다.
해시 체인 감사 기록
모든 감사 항목은 반드시 previousHash를 포함해 이전 항목과 해시로 연결됩니다. 중간 기록이 바뀌면 해시 연결이 끊어져 변조가 드러납니다. 구현체는 항목을 IPFS 같은 오프체인에 저장하고 머클 루트를 주기적으로 온체인에 고정하는 방식을 선택할 수 있어 전체 온체인 저장 비용 없이 변조 탐지를 제공합니다. 각 항목은 AuditEntryLogged 이벤트로 순번, 세션 ID, 행동 유형과 함께 기록됩니다.
표준 오류 코드
구현체가 공통으로 쓰는 오류는 다섯 가지입니다. PolicyExpired(정책 만료), ValueExceedsLimit(금액 한도 초과), InvalidSignature(서명자 불일치), EntropyVerificationFailed(엔트로피 약속값과 공개값 불일치), PolicyViolation(그 밖의 정책 위반과 사유)입니다. 오류에 policyHash나 한도 같은 맥락 값이 담겨 있어 거부 원인을 확인할 수 있습니다.
호환성과 설계 방향
ERC-4337 계정 추상화 지갑과 기존 표준에 호환되며 파괴적 변경이 없습니다. 구현체는 ERC-4337 지갑이나 전용 정책 집행 모듈 같은 스마트 컨트랙트로 만들어집니다. 원문은 가스 효율적인 감사 루트, 임계값 기반 격리 메커니즘, 고가치 에이전트 시나리오에서의 CROPS(검열 저항, 오픈소스, 프라이버시, 보안) 속성 강제를 열린 질문으로 남겨 두었습니다. 이 표준은 Final 상태로 확정되었습니다.
쓸 때 주의할 점
- 재전송 공격 방지: 과거의 유효한 증명이 재사용되지 않도록 만료 시각 검사와 논스의 유일성을 강제해야 합니다.
- 호스트 조작 위험: 호스트의 조작은 확률적 위험으로 남습니다. 고가치 에이전트에는 독립적인 호스트 여러 곳을 사용해 위협을 줄이는 것이 권장됩니다.
- 위임 전 검증과 악성 신호 확인: 위임 전에 낮은 위험 점수의 최신 ERC-8126 검증이 필요합니다. 제재, 믹서 사용, 봇 패턴, 빠른 자금 이동, 위협 정보 적중이 없는 깨끗한 지갑 검증 결과에 특히 주의해야 합니다.
- 점수가 좋아도 플래그가 있으면 거부: 전체 위험 점수가 괜찮아 보여도 ERC-8126 지갑 검증이 제재 자금, 악성 행위자와의 클러스터링, 강한 자동화 지표 같은 악성 활동을 표시하면 위임을 거부하거나 철회해야 합니다.
- 사용자 주권과 능동적 격리: 사용자가 에이전트와 행동에 대한 최종 결정권을 유지하는 것이 최우선이며 맹목적 신뢰나 책임 없는 중개를 만드는 설계를 피해야 합니다. 정책 위반에 즉시 대응할 수 있는 능동적 격리 메커니즘을 가능한 곳에 구현해야 합니다.