에이전트 월렛: AI 에이전트를 위한 세션 및 권한 모델

2026년 9월 2일에 게시됨10분 읽기

온체인에서 거래하는 AI 에이전트는 서명 한 번으로 실제 자금을 움직일 수 있는 위치에 있습니다. 시장을 읽고, DEX를 통한 경로를 선택했고, 이제 실행할 준비가 되었습니다. 이를 안전하게 처리하는 것은 결국 하나의 질문으로 귀결됩니다. 에이전트가 잘못 작동하거나, 탈취되거나, 단순히 버그가 있을 때 어떻게 되는가? 지갑을 비울 수 있는가, 그리고 피해가 발생하기 전에 막을 수 있는가?

권한 통제가 적용된 에이전트 지갑을 프로비저닝하려면, 에이전트에게 개인 키 대신 범위가 지정된 세션을 부여하세요. 코딩 에이전트나 내부 자동화에는 Alchemy CLI의 Agent Wallets를 사용하세요. alchemy wallet connect를 실행하고, 대시보드에서 허용할 작업과 만료 시점을 승인한 뒤, 작업이 끝나면 세션을 즉시 취소하면 됩니다. 자체 사용자가 에이전트에게 위임하는 제품에는 Wallet APIs 세션 키를 사용하세요. EIP-7702 스마트 지갑 위에 토큰별 지출 한도, 컨트랙트 허용 목록, 가스 한도, 만료를 추가합니다. 두 경우 모두 에이전트는 소유자의 키를 보유하지 않습니다.

에이전트 지갑이란 무엇이며, 일반 암호화폐 지갑과 어떻게 다른가?

일반 지갑은 본인만이 보유한 키로 모든 트랜잭션을 검토하고 서명하는 사람을 전제로 합니다. 에이전트 지갑은 그 반대를 전제로 합니다. AI 에이전트나 자동화된 프로세스가 매번 사람이 승인 버튼을 누르지 않고도 지속적으로 서명하되, 자금을 소유한 사람이나 회사가 궁극적인 통제권을 유지합니다.

그 차이는 지갑에 들어있는 잔액이나 주소가 아니라, 서명 키를 둘러싼 권한 모델에서 나옵니다. 즉, 에이전트가 무엇을 하도록 허용되는지(범위가 지정된 기능), 얼마나 오래 그것을 할 수 있는지(시간 제한이 있는 세션), 그리고 문제가 생겼을 때 얼마나 빨리 차단할 수 있는지입니다.

Agent Wallets는 이 각각을 직접 처리합니다:

범위가 지정된 기능: CLI 세션은 전송, 스왑, 브리지, 컨트랙트 호출 등 부여한 특정 서명 메서드만 포함합니다. 키를 하나의 컨트랙트 함수로 제한하는 것은 CLI 기능이 아니라 Wallet API 세션 키 권한입니다.
시간 제한이 있는 세션: 모든 부여에는 만료 시점이 있어서, 아무도 취소하지 않아도 접근 권한이 자동으로 소멸합니다.
빠른 차단: Alchemy 대시보드나 alchemy wallet disconnect를 통해 CLI 세션을 취소하면 검증 계층에서 즉시 적용되며, 트랜잭션이 필요하지 않습니다.

범위가 지정된 기능과 만료는 Agent Wallets CLI 제품을 EVM과 Solana 전반에서 직접 사용하든, 자체 사용자를 위해 기반이 되는 Wallet APIs 세션 키 프리미티브 위에 구축하든 동일하게 나타납니다. 채굴된 트랜잭션 없이 즉시 차단하는 것은 CLI 경로입니다. Wallet API 세션 키를 제거하는 것은 온체인 제거 작업입니다.

에이전트 지갑은 어떻게 프라이빗 키를 에이전트로부터 분리하는가?

에이전트를 위한 안전한 트랜잭션을 설계한다는 것은 일반 지갑이 하나의 키로 묶어 처리하는 것, 즉 커스터디(누가 프라이빗 키를 보유하는가), 인가(무엇이 허용되는가), 통제(누가 승인하거나 차단할 수 있는가)를 분리한다는 뜻입니다.

Turnkey는 커스터디를 하드웨어 시큐어 엔클레이브 내부에 두고, 정책 엔진도 같은 엔클레이브에서 실행합니다. 따라서 서명은 요청이 규칙을 통과한 후에만 나오며, 에이전트는 키에 전혀 접근하지 않습니다.
Crossmint와 Cobo는 대신 지갑을 소유자 키와 에이전트 키로 분리합니다(Cobo는 단일 키 대신 독립된 당사자들에 걸친 MPC를 사용). 이에 따라 에이전트의 키는 소유자가 설정한 한도 내에서만 작동합니다.
Alchemy는 동일한 분리를 CLI에 구축했습니다: 로컬에서 생성된 세션 서명자가 에이전트를 인증하는 동안, 별도의 커스터디언이 실제 프라이빗 키를 보유하므로 에이전트는 키에 전혀 접근하지 않고 인증하고 서명합니다.

실제로 어떻게 작동하는지 살펴보겠습니다.

alchemy wallet connect를 실행하면 CLI가 로컬에서 P-256 키페어를 생성하며, 이는 절대 사용자의 컴퓨터를 벗어나지 않습니다.
Alchemy 대시보드에서 세션을 승인하면, 해당 공개 키가 사용자가 설정한 특정 기능과 만료 시점으로 범위가 지정된 서명자로 연결됩니다.
지갑의 실제 프라이빗 키는 임베디드 지갑 파트너(기본값은 Privy)가 보유합니다.
모든 서명 호출은 2단계 검증을 거칩니다. Alchemy의 백엔드가 커스터디언이 기대하는 정확한 페이로드를 만들고, CLI가 로컬에서 이를 서명하며, 세션이 여전히 유효한 경우에만 요청이 커스터디언에 도달합니다. 에이전트는 프라이빗 키를 받거나 다루지 않습니다.

프로비저닝과 권한 제어에는 어떤 인프라를 사용해야 하는가?

누구를 위해 구축하느냐에 따라 두 가지 경로가 있습니다.

코딩 에이전트나 내부 자동화에 지갑을 제공하려는 경우, Alchemy CLI의 Agent Wallets가 가장 빠른 경로이며, 프라이빗 키를 Cursor에 바로 붙여넣는 방식을 에이전트가 실제로 안전하게 사용할 수 있는 방식으로 대체하는 것과 같은 접근법입니다.

대시보드에서 지갑을 생성하고, alchemy wallet connect --mode session를 실행하고, 세션의 기능과 만료를 승인하면, 에이전트는 전송과 컨트랙트 호출은 물론 EVM 메인넷에서의 스왑과 브리지에도 즉시 사용할 수 있는 범위가 지정된 세션을 얻습니다. SDK 통합이 필요하지 않으며, CLI의 agent-prompt 명령은 에이전트에게 명령어, 플래그, 오류 코드의 전체 매뉴얼을 제공하므로 표면을 올바르게 사용하기 위해 문서를 따로 읽을 필요가 없습니다.

자체 사용자가 에이전트에게 서명을 위임하는 제품을 구축하는 경우, Wallet APIs 세션 키를 활용하세요. 사용자의 스마트 계정은 EIP-7702 하에서 온체인으로 위임되며, 세션 키와 권한 배열을 사용하여 wallet_createSession(또는 SDK의 client.grantPermissions())를 호출하고, 사용자는 하나의 EIP-712 인가에 서명하며, 그 이후 에이전트는 소유자의 키가 아닌 세션 키로 모든 작업에 서명합니다.

무엇을 위임할 수 있으며, 권한은 얼마나 세밀한가?

위임은 여기서 두 계층으로 작동합니다. 첫째는 세션이 애초에 호출할 수 있는 작업이 무엇인지, 둘째는 한 단계 더 들어가서 그 호출이 얼마나 많은 가치를, 혹은 어떤 특정 컨트랙트를 다룰 수 있는지입니다.

CLI 세션 수준에서 첫 번째 계층은 허용된 메서드 목록입니다.

세션은 evm.signMessage, evm.signTypedData, evm.signAuthorization, evm.prepareCalls, evm.sendCalls, solana.signTransaction을 포함할 수 있습니다.
모든 것이 Alchemy의 wallet 호출(wallet_prepareCalls, wallet_sendCalls)을 통해 라우팅되므로 순서 지정, 배칭 같은 트랜잭션 처리와 가스 스폰서십이 자동으로 처리됩니다.

트레이드오프는 세션이 독립형 프라이빗 키처럼 임의의 raw EVM 트랜잭션에 서명할 수 없다는 것입니다. 따라서 에이전트가 raw EVM 트랜잭션을 서명하도록 넘겨주는 서드파티 SDK나 프로토콜과 연동해야 한다면, 이 흐름은 현재 CLI 세션을 통해서는 작동하지 않습니다. 이것이 필요한 사용 사례라면 문의해 주세요.

Wallet APIs 수준에서는 세션 키 권한이 더 세밀하게 구성 가능합니다. CLI의 기능 목록은 이 세션이 sendCalls를 호출할 수 있는지 여부만 예/아니오로 답합니다. Wallet API 권한은 그 위에 한도를 추가합니다. 전송이 허용되는지 여부뿐만 아니라, 얼마나, 어떤 토큰으로, 어떤 특정 컨트랙트를 통해 움직일 수 있는지까지 다룹니다. 에이전트에게 특정 작업이 켜져 있는지에 대한 스위치가 아니라, 24시간 창에서 하나의 토큰에 대해 100 USDC 한도 같은 실제 지출 한도가 필요하다면 Wallet APIs를 활용하세요:

Permission type	What it restricts
`native-token-transfer`	Caps how much native token (ETH, say) the key can move, via a fixed allowance
`erc20-token-transfer`	Caps cumulative ERC-20 transfers and approvals for one token contract to a set allowance
`gas-limit`	Caps how much gas the key can spend across transactions
`contract-access`	Allows every function on one named contract, nothing else
`functions-on-contract` / `account-functions` / `functions-on-all-contracts`	Allows only specific function selectors, on one contract, on the account itself, or everywhere
`root`	Full access to everything, a very dangerous permission to grant. Use judiciously.

모든 권한에는 expirySec도 함께 적용되므로, 하나의 부여로 세션 키를 예를 들어 하나의 스테이킹 컨트랙트, 100 USDC 한도, 24시간 창까지 한 번에 범위를 지정할 수 있습니다.

에이전트의 지갑 세션을 승인, 검증, 취소하는 방법

승인은 사람이 한 번 수행합니다. CLI 흐름에서는 세션을 연결할 때의 대시보드 승인 단계가 이에 해당합니다. Wallet APIs 흐름에서는 소유자가 세션 키의 권한을 인가하는 EIP-712 타입 데이터에 서명하는 것이 이에 해당합니다.

검증은 상태를 변경하는 모든 작업 전에 이루어져야 하며, 설정 시점에만 이루어져서는 안 됩니다. 에이전트가 돌이킬 수 없는 작업을 하기 전에 alchemy --json --no-interactive wallet status --verify을 실행하세요. 이는 활성 서명자, 세션 만료, 활성화된 기능을 반환하므로, 에이전트(또는 오케스트레이션 코드)는 진행하기 전에 세션이 여전히 살아있는지 확인합니다.

취소에는 두 가지 메커니즘이 있습니다:

대시보드에서 또는 alchemy wallet disconnect을 통해 세션을 취소하면 검증 계층에서 취소됩니다. 다음 서명 시도는 커스터디언에 도달하기 전에 즉시 거부되며, 트랜잭션이 필요하지 않습니다.
스마트 계정 수준에서 세션 키를 직접 관리하는 경우(CLI 제품 외부), 세션 키를 제거하는 것은 유저 오퍼레이션으로 밸리데이터를 제거 설치하는 것을 의미하며, 이는 다른 온체인 작업과 마찬가지로 전송되고 채굴되어야 합니다.

에이전트 접근 권한 취소를 즉각적으로 만드는 방법

에이전트가 잘못된 행동을 하는 것을 발견하고 취소 버튼을 눌렀다고 가정해 봅시다. 킬 스위치가 온체인에 저장된 규칙을 변경하는 방식으로 작동한다면, 그 변경이 실제로 반영되기 전에 여전히 트랜잭션으로 전송되고 채굴되어야 합니다. 따라서 블록 타임, 혹은 그 이상의 시간 동안, 이미 시스템에 멈추라고 알렸음에도 에이전트가 여전히 행동할 수 있는 창이 존재합니다. 문제는 이런 공백이 없도록 취소를 어떻게 설계할 것인가입니다.

이는 시행(enforcement)이 어디에 있는지에 달려 있습니다. 에이전트와 체인 사이를 가로막는 유일한 것이 스마트 컨트랙트 내부에 저장된 규칙이라면, 그 규칙을 끄는 것은 컨트랙트의 상태를 변경하는 트랜잭션을 보내는 것을 의미하며, 그 변경이 실제로 반영되려면 트랜잭션이 채굴되어야 합니다. 대신 요청이 서명되거나 브로드캐스트되기 전에 이를 확인하는 계층에서 시행이 이루어진다면, 취소는 그 확인을 삭제하거나 무효화하는 것일 뿐이며, 이는 실행하는 즉시 적용됩니다.

Alchemy의 Agent Wallets, Turnkey의 정책 엔진, Cobo의 pact 시스템 모두 후자의 패턴을 사용합니다.

Turnkey는 루트가 아닌 에이전트 사용자를 삭제하며, 이후 해당 자격 증명으로부터의 모든 요청은 엔클레이브에서 실패합니다.
Cobo는 pact와 그 API 키를 서버 측에서 취소하며, 에이전트의 다음 API 호출이 거부된다고 명확히 명시합니다.
Alchemy는 백엔드 검증 계층에서 세션을 취소하며, 다음 서명 시도는 Alchemy의 인프라를 벗어나기 전, 즉 커스터디언에 도달하기 전에 거부됩니다.

Crossmint는 다른 접근법을 취합니다. 권한이 스마트 컨트랙트 지갑 자체 내부에 존재하므로, 에이전트의 서명자를 제거하는 것은 해당 컨트랙트의 온체인 상태에 대한 변경입니다. 체인 자체에 의해 규칙이 시행된다는 점이 서버보다 탈취된 에이전트가 우회하기 더 어렵게 만들지만, 트레이드오프는 속도입니다. 온체인 권한을 변경한다는 것은 트랜잭션을 보내야 한다는 뜻이므로, 취소는 백엔드 확인 방식이 완전히 피할 수 있는 체인의 결제 시간을 그대로 물려받습니다.

Agent Wallets 대 Wallet API 세션 키

Agent Wallets와 Wallet APIs를 통한 세션 키 사용 모두 프라이빗 키를 에이전트로부터 멀리 둡니다. 차이가 나는 부분은 얼마나 많은 통제가 필요한지, 누가 실제로 에이전트에게 위임하는지, 그리고 취소가 어떻게 작동하는지입니다. CLI 세션은 트랜잭션 없이 검증 계층에서 차단됩니다. Wallet API 세션 키를 제거하는 것은 채굴된 유저 오퍼레이션을 기다립니다.

Use Agent Wallets (the CLI)	Use Wallet APIs session keys
You're wiring up a coding agent or an internal script and want it signing in minutes, no SDK integration required.	You're building a product where your own end users delegate signing to an agent on their own smart account.
A yes/no capability list, can this session send, swap, bridge, or make contract calls, is enough scoping for what the agent does.	You need an actual spend cap, like a fixed allowance on native token or one ERC-20, enforced by the permission itself.
The Alchemy dashboard is a fine place to create the wallet and approve sessions by hand.	You need contract- or function-level allowlists as the real enforcement boundary, not just a capability flag.
The CLI already handles what the agent needs to do: sending, batching calls, and getting its gas sponsored across EVM and Solana, plus swapping and bridging on EVM mainnet.	You need to grant session keys from your own app. Neither path signs an arbitrary raw EVM transaction for a third-party SDK today. Reach out to us if that's the use case.

Alchemy는 Turnkey, Crossmint, Cobo와 어떻게 비교되는가

Provider	Where custody lives	Where policy is enforced	Instant revoke without a mined transaction
Alchemy Agent Wallets	Embedded wallet partner (Privy by default) for CLI sessions, or any signer you choose via Wallet APIs	Backend session-verification layer for CLI sessions; onchain session-key permissions on the smart account for custom Wallet APIs integrations	Yes for CLI sessions, via dashboard or `wallet disconnect`. Wallet API session keys: no, uninstalling the validator is a mined user operation
Turnkey	AWS Nitro secure enclave (TEE)	Policy engine running inside the same enclave, evaluated before every signature	Yes, delete the non-root agent user or toggle a DENY policy
Cobo Agentic Wallet	MPC across independent parties, no single key	Three-stage server-side policy engine (permission, rule, counter), evaluated on every request	Yes, freeze or revoke a pact; the API key gets invalidated server-side
Crossmint	Dual-key smart contract wallet: owner key plus an agent key sealed in a TEE	Onchain, inside the smart contract itself (per-transaction limits, allowlists, time windows checked at execution)	By design, no. Removing a signer changes the wallet contract's onchain signer set, so it settles like any other onchain operation rather than a synchronous backend check

요약하면: Alchemy CLI 세션, Turnkey, Cobo 모두 오프체인에서 시행하며 즉시 취소됩니다. Crossmint와 Wallet API 세션 키는 온체인에서 시행하므로, 취소가 결제 시간을 물려받습니다.

피해야 할 흔한 실수

가스 스폰서십을 지출 한도로 취급하지 마세요. 스폰서십 정책은 누가 수수료를 지불하는지를 결정하는 것이지, 에이전트가 얼마나 움직일 수 있는지를 결정하는 것이 아닙니다. 실제 지출 한도를 위해서는 세션 키 권한이나 컨트랙트 허용량을 사용하세요.
온체인 권한 변경을 킬 스위치로 의존하지 마세요. 접근 권한 취소가 밸리데이터를 제거하거나 온체인에서 서명자를 변경하는 것을 의미한다면, 사고 상황에서 블록 타임에 묶이게 됩니다. 대신 서명 앞단에 백엔드나 엔클레이브 확인을 두고, 온체인 계층은 2차 방어선으로 유지하세요.
더 빨리 차단을 해제하기 위해 root 권한을 부여하지 마세요. Alchemy의 자체 문서조차 이를 부여하기에 매우 위험한 권한이라고 명시하고 있으며, 이는 애초에 세션을 범위 지정하는 목적 자체를 무의미하게 만듭니다. 에이전트가 실제로 필요로 하는 특정 컨트랙트, 함수, 토큰으로 범위를 지정하세요.
돌이킬 수 없는 작업 전에 검증을 건너뛰지 마세요. 한 시간 전에는 유효했던 세션이 이미 취소되었거나 만료되었을 수 있습니다. 돌이킬 수 없는 작업 바로 직전에 wallet status --verify(또는 여러분의 통합에 해당하는 방법)로 확인하세요.
"에이전트 지갑"이 하나의 아키텍처를 의미한다고 가정하지 마세요. Turnkey, Crossmint, Cobo, Alchemy는 모두 커스터디, 정책 시행, 취소를 서로 다른 위치에 둡니다. 배포하기 전에 여러분이 의존하는 규칙을 실제로 시행하는 계층이 어디인지 확인하세요.

자주 묻는 질문

에이전트 지갑이란 무엇이며 일반 암호화폐 지갑과 어떻게 다른가요?

에이전트 지갑은 사람이 각 트랜잭션을 승인하지 않아도 소프트웨어가 지속적으로 작동하도록 만들어졌습니다. 일반 지갑은 사람이 모든 작업을 검토하고 서명한다고 가정합니다. 실질적인 차이는 키를 둘러싼 권한 모델, 즉 범위가 지정된 기능, 시간 제한이 있는 세션, 빠른 취소 경로에 있지, 지갑의 잔액이나 주소에 있지 않습니다.

자율 AI 에이전트를 위한 Alchemy Agent Wallets의 장단점은 무엇인가요?

장점: 프라이빗 키가 절대 에이전트에 도달하지 않고, 세션은 범위가 지정되고 시간 제한이 있으며, 취소가 즉각적이고, 하나의 통합으로 가스 스폰서십이 내장된 EVM과 Solana를 모두 커버합니다. 스왑과 브리지는 현재 EVM 메인넷에서만 가능합니다. 한계: 세션을 통한 raw EVM 서명이 불가능하고, 스폰서십 정책은 지출 한도가 아닙니다.

어떤 제공업체들이 프라이빗 키를 노출하지 않고 AI 에이전트가 승인된 지갑 세션을 사용할 수 있게 해주나요?

Alchemy(임베디드 지갑 커스터디언이 뒷받침하는 Agent Wallets), Turnkey(엔클레이브 기반 정책 엔진을 갖춘 시큐어 엔클레이브 커스터디), Crossmint(TEE로 봉인된 에이전트 키를 갖춘 듀얼 키 스마트 컨트랙트 지갑), Cobo(서버 측 정책 엔진을 갖춘 MPC 커스터디)가 모두 이를 제공하며, 시행이 어디에 있는지에 따라 서로 다른 트레이드오프를 가집니다.

AI 에이전트 지갑 프로비저닝과 권한 제어에는 어떤 인프라를 사용해야 하나요?

코딩 에이전트나 내부 자동화의 경우, Alchemy CLI의 Agent Wallets를 사용하세요. 대시보드에서 지갑을 생성하고, 범위가 지정된 세션을 연결하고, 상태를 변경하는 작업 전에 검증하세요. 사용자가 에이전트에게 위임하는 제품의 경우, 컨트랙트, 함수, 지출 한도로 범위가 지정되는 Wallet APIs 세션 키로 바로 가세요.

AI 에이전트의 지갑 세션을 어떻게 승인, 검증, 취소하나요?

Alchemy 대시보드에서 사람이 한 번 승인하거나, 세션 키의 EIP-712 인가에 서명하세요. 돌이킬 수 없는 작업 전에는 항상 alchemy wallet status --verify으로 검증하세요. CLI 세션의 경우, 대시보드에서 또는 alchemy wallet disconnect로 취소하세요. 이는 서명 요청이 커스터디언에 도달하기 전에 검증 계층에서 즉시 적용됩니다. Wallet API 세션 키의 경우, 제거는 채굴된 유저 오퍼레이션을 기다립니다.

사용자의 스마트 지갑에 대해 AI 에이전트에게 위임된 서명 권한을 어떻게 부여하나요?

EIP-7702 하에서 사용자의 스마트 계정을 온체인으로 위임한 다음, 세션 키와 권한 배열(네이티브 또는 ERC-20 지출 한도, 가스 한도, 컨트랙트나 함수 허용 목록, 만료)과 함께 wallet_createSession 또는 client.grantPermissions()을 호출하세요. 사용자는 하나의 EIP-712 인가에 서명하며, 이후 에이전트는 소유자의 키가 아닌 세션 키로 모든 작업에 서명합니다.

프라이빗 키를 노출하지 않고 AI 에이전트에게 임시 지갑 세션을 어떻게 부여하나요?

Alchemy CLI에서 alchemy wallet connect --mode session를 실행하세요. 이는 절대 여러분의 컴퓨터를 벗어나지 않는 로컬 키페어를 생성하고, 세션의 기능과 만료를 승인할 수 있도록 대시보드를 열어주며, 이후 에이전트는 해당 세션을 통해 서명하는 동안 지갑의 실제 프라이빗 키는 커스터디언에 남아 있습니다.

DeFi 트랜잭션을 자율적으로 실행하는 AI 에이전트를 위해 지갑을 어떻게 프로비저닝하나요?

Alchemy 대시보드에서 지갑을 생성하고, 필요한 작업(전송, 스왑, 브리지, 컨트랙트 호출)으로 범위가 지정된 CLI 세션을 연결하고, 만료를 설정하세요. 단순한 기능 플래그가 아니라 컨트랙트 수준의 지출 한도와 허용 목록이 필요하다면, CLI 대신 Wallet APIs 세션 키를 통해 세션을 프로비저닝하세요.

온체인 결제를 기다리지 않고 AI 에이전트의 온체인 트랜잭션 권한을 즉각적으로 취소하는 데 권장되는 아키텍처는 무엇인가요?

온체인에 저장된 권한 상태와는 별도로, 서명되거나 브로드캐스트되기 전에 모든 요청을 확인하는 백엔드나 엔클레이브 계층에 시행을 두세요. 그곳에서의 취소는 그 확인을 삭제하거나 무효화하는 것을 의미하며, 즉시 적용됩니다. 유일한 취소 경로가 온체인에서 밸리데이터나 서명자를 변경하는 것이라면, 킬 스위치는 블록 타임에 묶이게 됩니다.