에이전틱 지갑 보안: AI 에이전트가 더 안전하게 거래하는 방법

Agentic 지갑은 AI 에이전트를 신뢰할 수 있는 서명자가 아닌 낯선 트랜잭션 제안자로 취급할 때 안전합니다. 키는 에이전트의 추론 프로세스와 분리되어 있고, 권한은 범위가 지정되어 있으며 취소 가능하고, 모든 트랜잭션은 서명되기 전에 검토됩니다. 이를 통해 조작되거나 오작동하는 에이전트를 통제할 수 있습니다.

MetaMask는 What is an agentic wallet?에서 agentic 지갑이 무엇인지 설명하고, How AI agents transact without touching your keys에서 전체 트랜잭션 라이프사이클을 설명하며, Why every AI agent needs a wallet에서 자기 수탁(self-custody)의 중요성을 다룹니다. 이 글에서는 사람이 아닌 에이전트가 트랜잭션을 제안할 때 수반되는 위험을 완화하는 방법에 초점을 맞춥니다.

Agentic 지갑은 안전한가요?

Agentic 지갑의 안전성은 에이전트가 개인 키에 직접 접근할 수 있는지, 권한이 범위 지정되어 있는지 또는 무제한인지, 그리고 트랜잭션이 서명된 후가 아닌 서명되기 전에 검토되는지에 달려 있습니다. 격리된 정책 적용 지갑에 작업을 제안하는 에이전트는 자체 키를 보유한 에이전트와는 다른 위험 프로파일을 가집니다.

Agentic 지갑에 다른 위협 모델이 필요한 이유

사람을 위해 설계된 지갑은 서명 전에 사람이 각 트랜잭션을 검토한다고 가정합니다. Agentic 지갑은 그런 가정을 할 수 없습니다. 토큰의 메타데이터, 웹 페이지 또는 API 응답을 읽는 프로세스가 다음에 무엇을 서명할지 결정하는 프로세스와 동일할 수 있기 때문입니다. How AI agents transact without touching your keys에서 의도에서 실행까지의 전체 라이프사이클을 다룹니다. 보안 측면에서 중요한 것은 에이전트의 신뢰할 수 없는 입력과 트랜잭션 서명 권한이 서로 어느 위치에 놓이는지, 그리고 트랜잭션이 온체인에 기록되기 전에 에이전트와 독립적인 무언가가 개입할 수 있는지 여부입니다.

지갑이 아닌 에이전트에 특화된 위험

서명된 트랜잭션으로 이어지는 프롬프트 인젝션

프롬프트 인젝션은 사용자와의 대화가 아닌, 에이전트가 읽도록 설계된 콘텐츠(예: 토큰 설명, 웹 페이지, 이메일, API 응답) 안에 명령을 숨깁니다. 이는 대부분의 다른 상황보다 지갑 환경에서 훨씬 더 중요합니다. 잘못된 이메일에 속은 에이전트는 불편함을 초래하지만, 서명 권한을 가진 에이전트가 속으면 되돌릴 수 없는 트랜잭션이 발생할 수 있습니다.

에이전트 자체 런타임에서 접근 가능한 키

에이전트가 설정 파일, 환경 변수 또는 애플리케이션 메모리에서 자체 서명 키를 읽을 수 있다면, 해당 에이전트가 침해될 경우 에이전트가 제어하는 자금도 침해됩니다. 2026년 2월 8일 발생한 사건을 예로 들면, Gitcoin의 Owockibot이 절대 공유하지 말라는 지시에도 불구하고 여러 위치에서 자체 핫 월렛 개인 키를 노출했습니다. 지갑에 약 2,100달러만 보유하고 있었기 때문에 손실은 최소화되었습니다. MetaMask Agent Wallet의 서버 지갑 모드는 에이전트가 접근할 수 없는 신뢰 실행 환경(TEE) 내에 키를 보관합니다. 로컬 키 제어가 필요한 개발자를 위한 별도의 자체 지갑 가져오기(bring-your-own-wallet) 모드도 있으며, 해당 문서에는 명령 기록과 프로세스 목록이 자체적인 노출 경로가 될 수 있으므로 니모닉을 커맨드라인 인수가 아닌 환경 변수를 통해서만 전달해야 한다고 명시되어 있습니다.

작업 범위에 맞게 축소되지 않는 권한

잔액 확인만을 위해 범위가 지정된 에이전트에게는 모든 컨트랙트에서 무제한 토큰 지출을 승인할 권한이 필요하지 않습니다. 권한이 해당 작업에 맞게 축소되지 않으면, 침해되거나 잘못 유도된 에이전트 하나가 좁은 범위가 아닌 지갑의 전체 권한으로 행동할 수 있습니다.

트랜잭션 보험을 보안 제어로 오해하기

일부 agentic 지갑은 보안 스택에 문제가 발생했을 때의 환급 기능을 결합합니다. MetaMask의 구독 서비스인 Transaction Shield는 트랜잭션 보호와 우선 지원을 결합하여, MetaMask의 보안 검사를 통과했음에도 손실이 발생한 적격 트랜잭션에 대해 월 최대 10,000달러를 mUSD로 환급합니다. 단, 침해되거나 유출된 Secret Recovery Phrase 또는 개인 키로 인한 손실, 일반적인 시장 손실, 프로토콜 수준의 익스플로잇, P2P 이체는 명시적으로 제외됩니다. 환급은 안전해 보였지만 그렇지 않았던 트랜잭션의 결과를 보완할 수 있습니다.

Guard Mode와 Beast Mode가 노출 위험에 미치는 영향

MetaMask Agent Wallet의 두 가지 운영 모드는 어떤 제어가 자동으로 적용되고, 어떤 제어가 사용자가 실시간으로 문제를 발견하는 것에 의존하는지를 결정합니다. MetaMask의 거래 모드 문서에는 트랜잭션이 진행되기 전에 각 모드가 적용하는 가드레일이 나열되어 있습니다.

두 모드 모두 MetaMask의 위협 스캔에서 악성으로 표시된 트랜잭션이나 위험으로 표시된 컨트랙트를 차단하며, 두 경우 모두 진행 전에 2FA 승인이 필요합니다. Guard Mode에서는 설정된 허용 목록 외부의 항목이나 출금 한도를 초과하는 항목도 승인을 위해 일시 중지됩니다. Beast Mode에서는 허용 목록 자체가 없기 때문에 그렇지 않습니다. Beast Mode는 악성 트랜잭션 탐지 기능 자체를 약화시키지는 않습니다. 다만, 에이전트가 시도해서는 안 되는 정상적으로 보이는 트랜잭션을 차단하는 허용 목록 및 지출 한도 레이어를 제거합니다.

지갑 내부의 격리 작동 방식

MetaMask의 에이전트 대상 서버 지갑 구축을 위한 개발자 가이드는 일반적인 패턴을 설명합니다. 서명 키는 외부 네트워킹과 영구 저장소가 없는 신뢰 실행 환경 내에 존재하고, 에이전트는 서명을 요청하는 데 사용되는 별도의 자격 증명만 보유하며, 에이전트가 아닌 엔클레이브가 요청을 검증하고 정책을 적용하며 서명을 생성합니다. 에이전트는 제안할 뿐, 결코 소유하지 않습니다. MetaMask Agent Wallet의 아키텍처는 이 분리를 직접 적용합니다. 서버 지갑 모드에서 키는 에이전트가 접근할 수 없는 TEE 내에서 관리되며, 사용자는 여전히 자기 수탁을 유지하고 기본 Secret Recovery Phrase를 내보낼 수 있습니다. 승인이 필요한 요청은 AWAITING_MFA 상태로 진입하며, 에이전트가 아닌 사용자 본인의 MetaMask Mobile 승인 또는 이메일 확인을 통해서만 진행할 수 있습니다.

에이전트를 실제 자금에 연결하기 전 체크리스트:

• 에이전트의 런타임이 개인 키를 읽거나 내보낼 수 없습니다.

• 서명은 에이전트 자체 프로세스가 아닌 격리된 환경에서 이루어집니다.

• 지출은 트랜잭션별 및 롤링 기준으로 제한됩니다.

• 컨트랙트, 네트워크, 수신자를 개방된 상태로 두지 않고 허용 목록에 추가할 수 있습니다.

• 모든 트랜잭션은 서명 전에 시뮬레이션되고 위협 스캔됩니다.

• 정책 한도는 모델 외부에서 적용됩니다. 시스템 프롬프트는 지침이지 강제 수단이 아닙니다.

• 권한을 취소하거나 세션을 즉시 종료할 수 있습니다.

• 표시된 작업과 완료된 작업이 기록되고 감사 가능합니다.

• 예상된 프롬프트뿐만 아니라 프롬프트 인젝션 시나리오에 대해서도 설정이 테스트되었습니다.

• 환급 보장 범위는 포함 사항뿐만 아니라 제외 사항도 이해하고 있습니다.

Agentic 지갑 모델 전반에 걸친 보안 경계의 위치

Agentic 지갑 공급업체들은 동일한 결론에 수렴하고 있습니다. 에이전트가 보안 경계가 되어서는 안 된다는 것입니다. 그 경계가 대신 어디에 위치하는지가 차이점입니다.

Coinbase, Cobo, Ledger, BitGo, OKX에 대한 전체 공급업체별 평가는 Best agentic wallets in 2026, compared를 참조하세요.

이 중 어느 것도 에이전트를 조작으로부터 완전히 보호하지는 않습니다. 현실적인 목표는 절대 속지 않는 모델이 아닙니다. 속더라도 무제한 금융 권한으로 이어지지 않는 지갑, 즉 침해된 에이전트가 할 수 있는 최악의 행동이 지출 한도, 허용 목록, 그리고 에이전트 스스로는 결코 접근할 수 없었던 서명에 의해 제한되는 지갑이 목표입니다.