Web3 컴패니언: 오픈소스 보안 에이전틱 지갑

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

AI가 사용자를 대신해 온체인 트랜잭션을 실행하도록 하는 것은 현재 크립토 업계에서 가장 뜨거운 트렌드입니다. Coinbase는 2026년 2월 Agentic Wallets를 출시했으며, McKinsey의 추산에 따르면 AI 에이전트 기반 커머스는 2030년까지 전 세계적으로 3조~5조 달러 규모에 달할 수 있습니다. Coinbase CEO 브라이언 암스트롱은 이렇게 말했습니다: AI 에이전트는 은행 계좌를 개설할 수 없지만, 크립토 지갑은 소유할 수 있습니다.

문제는 AI가 온체인 자산을 운용하도록 허용하는 것이 캘린더나 이메일을 관리하도록 하는 것과는 전혀 다르다는 점입니다. 온체인 트랜잭션은 되돌릴 수 없습니다. 환불도, 차지백도 없습니다. 악의적인 서명 하나로 단 한 블록 만에 지갑 전체를 비울 수 있습니다. 보안 없이는 어떤 기능도 의미가 없습니다.

BlockSec은 보안을 최우선으로 설계된 Agentic Wallet인 Web3 Companion을 오픈소스로 공개했습니다. 이 글에서는 그 보안 설계를 살펴봅니다. 현재 Agentic Wallet 아키텍처가 근본적으로 왜 취약한지, 그리고 우리가 어떻게 처음부터 지갑 아키텍처에 보안을 내재화했는지를 다룹니다.

현재 에이전트는 얼마나 위험한가: OpenClaw 사건

AI 에이전트에 보안 경계가 없으면 어떤 일이 벌어질까요? 2026년 초의 OpenClaw 사건이 그 답을 보여줍니다.

OpenClaw은 5일 만에 GitHub 스타 100,000개를 획득한 오픈소스 범용 AI 에이전트입니다. 범용 에이전트로서는 잘 작동했지만, Web3 트랜잭션에 닿는 순간 모든 보안 허점이 드러났습니다.

개인 키가 에이전트가 읽을 수 있는 로컬 파일에 평문으로 저장되어 있었습니다. 프롬프트 인젝션 이메일 하나만으로 키를 탈취할 수 있었습니다.

서명에는 격리가 없었습니다. 신뢰할 수 없는 웹 페이지를 가져오는 것과 동일한 프로세스가 트랜잭션에도 서명할 수 있었기 때문에, 단 하나의 RCE 취약점으로 공격자가 악성 웹 페이지를 통해 에이전트와 키 모두를 완전히 장악할 수 있었습니다.

스킬 마켓플레이스도 취약점이었습니다. 연구자들은 ClawHub 스킬의 7.1%가 자격증명을 누출하며, 일부는 아예 크립토 지갑을 비우도록 설계되어 있음을 발견했습니다.

난수 생성도 취약했습니다. OpenClaw은 보안 크리티컬한 경로에 시스템 클록으로 시드된 PRNG인 math/rand를 사용했습니다. 연구자들은 연속된 두 개의 토큰 값만으로 내부 상태를 재구성하고 이후 모든 토큰 및 챌린지 값을 예측할 수 있음을 증명했습니다. 일부 코드 경로에서는 이것이 지갑 키 복구까지 이어졌습니다.

무엇보다 최악은 정책 레이어가 없었다는 점입니다. 프롬프트 인젝션과 자금 이체 사이에는 아무것도 없었습니다. 차단이 전혀 없었습니다.

결론: 범용 AI 에이전트 아키텍처는 Web3 트랜잭션에 안전하지 않습니다.

현재 AI 에이전트 아키텍처의 근본적인 결함

이 문제는 OpenClaw을 넘어섭니다. 모델을 바꾸거나 프롬프트를 더 엄격하게 작성해도 문제는 해결되지 않습니다. 현재 AI 에이전트 아키텍처는 본질적인 보안 결함을 안고 있습니다. LLM 자체가 영구적으로 노출된 공격 표면이라는 것입니다.

근본 원인: LLM은 명령과 데이터를 구분할 수 없습니다. 시스템 프롬프트, 사용자 메시지, 웹 페이지 콘텐츠, 심지어 토큰 이름까지 모두 동일한 토큰 스트림으로 입력됩니다. 모델은 "이것을 실행하라"와 "이것을 그냥 읽어라"를 신뢰성 있게 구분할 메커니즘이 없습니다. 이로부터 세 가지 결과가 따릅니다.

첫째, 프롬프트 인젝션은 모델 레이어에서 해결 불가능합니다. 공격자는 에이전트가 받아들이는 이메일, 컨트랙트 주석, 웹 페이지, 토큰 이름 등 어디에든 명령을 숨길 수 있습니다. 에이전트가 트랜잭션에 서명할 수 있다면, 인젝션 하나의 성공이 장난을 절도로 바꿔놓습니다.

둘째, 에이전트 자체의 스킬 기반 보안 검토가 무력화될 수 있습니다. LLM이 트랜잭션 안전성을 판단하는 것은 전적으로 컨텍스트에 의존합니다. 컨텍스트를 오염시키면 판정이 뒤집힙니다. 악의적인 서명이 통과됩니다.

셋째, 에이전트는 24시간 내내 실행되며 신뢰할 수 없는 입력을 지속적으로 소비하고 자율적으로 트랜잭션을 실행할 수 있습니다. 공격 창이 닫히지 않으며, 한 번의 침해가 즉각적인 자금 손실을 의미할 수 있습니다.

보안 커뮤니티는 대체로 동의합니다. 프롬프트 인젝션에 치료법이 없는 세상에서 LLM에 개인 키에 대한 직접 접근 권한을 부여하는 것은, 언제든 탈취될 수 있는 컴포넌트 안에 사용자 자산을 두는 것과 다름없습니다. 모델 레이어는 강화할 수 없으므로, 리스크는 아키텍처 레이어에서 봉쇄되어야 합니다. 완전히 침해된 모델조차도 사용자 자금을 이동시킬 수 없어야 합니다.

Web3 Companion의 보안 아키텍처는 바로 이 아이디어 위에 구축되었습니다.

위협 모델: 에이전트는 신뢰할 수 없다

Web3 Companion의 위협 모델은 한 문장으로 요약됩니다. 에이전트 자체는 신뢰할 수 없습니다. 전체 아키텍처는 에이전트가 언제든 침해될 수 있다고 가정합니다.

우리는 에이전트가 모든 공격을 탐지할 만큼 강인해지도록 만드는 것에 의존하지 않습니다. 위에서 보여주었듯, 모델 레이어 방어는 작동하지 않습니다. 오늘 모스 부호 인젝션을 잡도록 훈련하면, 내일 공격자는 Base64, 이미지 속 스테가노그래피 텍스트, 또는 무해해 보이는 PDF로 전환합니다. 대신, 우리는 가정을 뒤집었습니다. 에이전트는 위협 모델 안에 위치하며, 나머지 시스템은 그것을 봉쇄하도록 설계되었습니다. 공격자가 에이전트를 완전히 장악하더라도, 사용자 자산은 안전합니다. 한 줄 포지셔닝: The Secure Agentic Wallet, 자신의 에이전트를 기본적으로 신뢰하지 않으며 그에 관계없이 안전을 유지하는 지갑입니다.

이 위협 모델로부터 다섯 가지 설계 원칙을 도출했습니다.

원칙 1: 에이전트는 절대 개인 키에 접근해서는 안 됩니다. 개인 키는 온체인 자산을 제어하는 유일한 자격증명입니다. 에이전트가 키를 읽을 수 있다면, 침해는 키 유출을 의미합니다. 키는 에이전트가 아키텍처적으로 접근할 수 없는 곳에 있어야 합니다.

원칙 2: 준비는 승인이 아닙니다. 트랜잭션을 구성하는 것과 승인하는 것은 별개의 행위입니다. 에이전트는 사용자가 온체인 상태를 이해하고 인텐트를 조합하는 것을 도울 수 있지만, 서명 결정은 에이전트가 접근할 수 없는 독립적인 백엔드 모듈에 속합니다.

원칙 3: 검토는 감지이지, 집행이 아닙니다. 트랜잭션 시뮬레이션, 콜데이터 분석, 주소 레이블링은 일반적인 공격 패턴을 포착하고 사용자가 리스크를 이해하도록 돕지만, 최종 판정은 아닙니다. 시뮬레이션은 실패할 수 있고, 레이블이 없을 수 있으며, LLM 자체의 분석도 프롬프트 인젝션에 취약합니다.

원칙 4: 하드 정책이 최후의 보루입니다. 에이전트가 속아서 $100,000 이체를 시작하고 보안 검토가 조작되어 승인했다고 가정합시다. 코드로 강제되는 일일 한도 $1,000이 여전히 이를 차단합니다. 에이전트는 이 한도를 변경할 권한이 없습니다.

원칙 5: 증거 없이는 실행 없음. 스캔 실패는 통과가 아닙니다. 데이터 누락은 "안전"이 아닙니다. 보안 증거가 없거나, 모순되거나, 오래되었거나, 불충분할 때, 시스템은 중단하고 명시적인 사용자 확인을 기다립니다.

이 다섯 가지 원칙은 개인 키 보안과 트랜잭션 보안이라는 두 가지 보안 모듈을 통해 구현됩니다.

개인 키 격리: 에이전트가 아키텍처적으로 접근 불가

첫 번째 문제는 단순합니다. 우리는 온체인 트랜잭션을 준비하는 보조자를 원하지만, 서명 능력을 부여하면 실제 돈을 이동시킬 권한을 넘기는 것입니다. 2025년과 2026년의 Web3 에이전트 침해 사건 거의 대부분이 동일한 공격 패턴을 따랐습니다. 개인 키가 에이전트 프로세스 안에 있었고, 공격자가 키를 추출하는 방법을 찾아냈습니다.

그래서 우리는 질문을 재구성했습니다. 에이전트가 문자 그대로 서명할 수 없다면 어떨까요? "하지 말라고 지시받은" 것이 아니라, 아키텍처적으로 불가능한 것입니다. 소프트웨어 수준의 접근 제어는 언제나 우회될 수 있습니다. 우리는 더 강력한 무언가가 필요했습니다.

Web3 Companion은 프로세스 수준의 격리를 적용합니다. 개인 키에 접근하는 컴포넌트는 단 하나입니다. 독립적인 Go 프로세스인 Secure Signature Module(SSM)입니다. 에이전트의 프로세스 메모리, 환경 변수, 파일시스템에는 키 재료가 전혀 없습니다. 에이전트가 보는 것은 트랜잭션 인텐트 ID뿐입니다. SSM에 해당 인텐트에 서명하도록 요청할 수 있지만, 그 뒤의 키는 절대 볼 수 없습니다.

키 저장을 위해 세 가지 옵션을 평가했습니다. 디스크의 평문: 디스크 읽기 한 번으로 키가 즉시 노출됩니다. 거부. 패스워드 파생 암호화: 재시작마다 재입력이 필요하여 장시간 실행되는 Docker 서비스에는 비실용적입니다. 거부. 우리는 봉투 암호화를 선택했습니다. 각 지갑 키는 고유한 데이터 키로 암호화되고, 그 데이터 키는 마스터 키(AWS KMS 또는 로컬 AES-256)로 래핑됩니다. 암호화된 파일이 통째로 유출되더라도 마스터 키 없이는 쓸모가 없습니다. 키는 SSM 메모리 내에서 서명 직후 즉시 제로화되며, 잠깐 평문으로 존재할 뿐입니다.

모든 서명 요청은 동일한 경로를 따릅니다. 빠른 우회로도, 지름길도 없습니다. 트랜잭션은 위임 확인, 시뮬레이션, 보안 검사, 에이전트 보안 검토, 정책 평가, Passkey 승인, 마지막으로 SSM 서명까지 순서대로 일곱 단계를 거칩니다. 한 단계를 완료해도 다음 단계를 건너뛸 수 없습니다.

언급할 가치 있는 저수준 세부사항 하나: 시스템의 모든 랜덤 바이트(개인 키 생성, AES-GCM 논스, 인증 토큰, WebAuthn 챌린지)는 OS 암호학적 난수 소스인 crypto/rand에서 나옵니다. math/rand는 모든 보안 크리티컬 코드에서 금지되며, 테스트와 CI로 강제됩니다.

트랜잭션 보안: 심층 방어의 4개 레이어

개인 키 격리는 키 보안을 다루지만, 트랜잭션 수준의 리스크는 여전히 남습니다. 침해된 에이전트는 사용자를 속이거나 자동 서명 정책을 우회하기 위해 완벽하게 합법적으로 보이는 트랜잭션 인텐트를 조합할 수 있습니다. 프롬프트 인젝션은 개인 키가 필요하지 않습니다. 정상적인 흐름을 통해 악성 트랜잭션에 서명하도록 시스템을 유도하기만 하면 됩니다.

핵심 질문: 트랜잭션을 준비하는 에이전트 자체가 침해되었을 수 있을 때, 어떻게 악성 트랜잭션을 포착할 수 있을까요?

단일 방어 레이어만으로는 버티지 못합니다. 시뮬레이션만? 시뮬레이션은 실패하고, RPC가 다운되고, 새로운 공격은 알려진 패턴 밖에 있습니다. LLM 기반 검토만? 에이전트를 침해한 것과 동일한 인젝션이 검토자를 침해합니다. 둘 다 LLM에서 실행되기 때문입니다. 단순 하드 한도만? 정당한 사용자가 막히고, 모든 스왑에 $100 한도는 사용 불가능합니다.

우리는 네 가지를 모두 겹쳐 쌓습니다. 각 레이어는 이전의 모든 레이어가 이미 무너졌다고 가정합니다.

레이어 1: 트랜잭션 시뮬레이션. 서명 전, 시스템은 실행을 시뮬레이션합니다. 콜데이터 디코딩, 리버트 예측, 필드 형식 검사. 시뮬레이션은 명백한 문제를 포착하지만 맹점이 있습니다. 새로운 공격 기법과 RPC 중단 모두 이를 무력화할 수 있습니다.

레이어 2: 상대방 평가. 일련의 정적 검사가 상대방을 대상으로 합니다. 수신자/금액 일치, 무제한 승인 감지, 번 주소 감지, 예상치 못한 위임 호출. 주소 리스크 점수 산정은 BlockSec의 x402 컴플라이언스 서비스를 통해 실행되며, 에이전트는 API 키나 구독 없이 x402 마이크로페이먼트를 통해 레이블과 리스크 점수를 조회합니다. 레이어 1과 2를 합치면 대부분의 일반적인 문제를 포착하지만, 둘 다 우회될 수 있습니다. 이들의 역할은 의도적으로 탐지와 설명으로 제한되며, 최종 결정이 아닙니다.

레이어 3: 하드 정책 집행. Go에서 순수 코드 집행. LLM은 관여하지 않으며, 에이전트는 규칙을 수정할 수 없습니다. 트랜잭션별 한도, 일일 예산, 수신자 화이트리스트, 자동 서명 임계값: $100 트랜잭션 한도에 대한 $5,000 이체는 즉시 거부됩니다. 정책 자체를 변경하려면 Passkey가 필요합니다. 이유는 무엇일까요? 에이전트가 정책을 편집할 수 있다면, 인젝션 하나가 먼저 한도를 올리고 지갑을 비울 것입니다. 자동 서명은 기본적으로 꺼져 있으며, 사용자가 명시적으로 선택하기 전까지 모든 트랜잭션에는 수동 승인이 필요합니다.

이것은 모든 탐지 레이어가 우회되고 완전히 침해된 에이전트가 악성 트랜잭션에 서명하더라도, 실제 손실은 정책에 의해 제한된다는 것을 의미합니다. 사용자가 일일 자동 서명 임계값을 $500로 설정하면, 최악의 경우 손실은 지갑 전체가 아닌 $500입니다. 정책 레이어는 침해를 재앙적인 사건에서 제한된 손실로 바꿉니다.

레이어 4: 사용자 확인 (Passkey). 정책이 수동 승인을 요구할 때, 시스템은 WebAuthn 인증(지문 또는 얼굴)을 요구합니다. 소프트웨어만으로는 이를 위조할 수 없습니다.

네 개의 레이어는 상호 불신 위에서 작동합니다. 각 레이어는 이전의 모든 것이 이미 실패했다고 가정합니다. 완벽한 시뮬레이션이 정책을 느슨하게 하지 않습니다. 잘못 구성된 정책이 Passkey를 건너뛰지 않습니다. 모든 레이어가 독자적으로 존재합니다.

놓치기 쉬운 세부사항 하나: 판정 재사용. 알려진 DeFi 공격 기법은 수정된 트랜잭션에 대해 이전 보안 판정을 재생합니다. Web3 Companion은 각 쓰기 작업을 감사 가능한 상태 전환을 가진 고유한 트랜잭션 인텐트에 바인딩합니다. 보안 판정은 검토한 정확한 인텐트에만 적용됩니다. 에이전트가 트랜잭션을 재구성하면, 금액이나 수신자만 변경하더라도 시스템은 이를 완전히 새로운 인텐트로 취급하고 모든 검사를 다시 실행합니다.

네 개의 방어 레이어는 세 개의 독립적인 신뢰 경계에 매핑됩니다: 개인 키, 정책, Passkey. 어느 하나의 경계가 침해되어도 나머지 두 개는 유지됩니다:

설계에 의한 보안: 오픈소스 뒤의 철학

BlockSec은 처음부터 온체인 보안을 연구해왔습니다. 우리는 수십억 달러의 온체인 자산을 보호했으며 동일한 교훈이 반복되는 것을 목격했습니다. 처음부터 아키텍처에 내재화되지 않은 보안은 언제나 너무 늦게 도착합니다.

AI 에이전트는 온체인 트랜잭션의 새로운 관문이 되고 있습니다. 이 분야는 빠르게 움직이지만, 보안 표준은 거의 존재하지 않습니다. 대부분의 팀은 자신의 에이전트가 무엇을 할 수 있는지에 집중합니다. 이 에이전트가 탈취된다면, 아키텍처가 피해 범위를 제한할 수 있는가?를 진지하게 고민한 팀은 드뭅니다.

Web3 Companion은 수년간의 온체인 보안 연구를 Agentic Wallet 아키텍처에 담으려는 BlockSec의 노력입니다. 코드는 MIT 라이선스 하에 완전히 공개되어 있습니다(현재 리서치 프리뷰로 표시). 업계에는 지금 당장 구체적인 보안 설계 참조점이 필요합니다. 위협 모델을 어떻게 구조화할지, 키를 어떻게 격리할지, 트랜잭션 방어를 어디까지 밀어붙일지: 어떤 팀도 이것들을 처음부터 다시 발명해야 할 필요가 없습니다. 우리는 커뮤니티가 그 위에서 구축할 수 있도록 전체 설계를 공개합니다.