Agent Wallets: AI 에이전트를 위한 세션 및 권한 모델

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

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

에이전트 지갑이란 무엇이며, 일반 크립토 지갑과 어떻게 다른가?

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

차이는 지갑에 담긴 잔액이나 주소가 아니라 서명 키를 감싸는 권한 모델에 있습니다: 에이전트가 무엇을 할 수 있는지(범위가 지정된 기능), 얼마나 오래 할 수 있는지(시간 제한이 있는 세션), 그리고 문제가 생겼을 때 얼마나 빠르게 차단할 수 있는지가 그것입니다.

Agent Wallets는 이 각각을 직접 다룹니다:

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

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

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

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

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 API 세션 키를 활용하세요. 사용자의 스마트 계정은 EIP-7702 하에서 온체인 위임되며, 세션 키와 권한 배열을 담아 wallet_createSession(또는 SDK에서 client.grantPermissions())를 호출하면, 사용자는 EIP-712 승인에 한 번 서명하고 그 이후 모든 동작에서 에이전트는 소유자의 키가 아닌 세션 키로 서명합니다.

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

여기서 위임은 두 계층에서 작동합니다: 세션이 어떤 동작을 호출할 수 있는지 전반적인 여부, 그리고 한 단계 더 들어가서 그 호출이 얼마나 많은 가치나 어떤 특정 컨트랙트에 접근할 수 있는지입니다.

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

세션에는 evm.signMessage, evm.signTypedData, evm.signAuthorization, evm.prepareCalls, evm.sendCalls, solana.signTransaction이 포함될 수 있습니다.
모든 것은 Alchemy의 지갑 호출(wallet_prepareCalls와 wallet_sendCalls)을 거치기 때문에, 순서 지정과 배치 처리 같은 트랜잭션 처리와 가스 후원이 자동으로 처리됩니다.

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

Wallet API 수준에서는 세션 키 권한이 더 세밀하게 설정할 수 있습니다. CLI의 기능 목록은 예/아니오만 답합니다: 이 세션이 sendCalls를 호출할 수 있는가 없는가? Wallet API 권한은 여기에 한도를 더합니다: 전송이 허용되는지 여부뿐 아니라, 얼마나 이동할 수 있는지, 어떤 토큰으로, 어떤 특정 컨트랙트를 통해서인지까지 포함됩니다. 에이전트가 어떤 동작이 켜져 있는지에 대한 스위치가 아니라 24시간 창에 걸쳐 100 USDC 상한선 같은 실제 지출 한도가 필요하다면, Wallet API를 활용하세요:

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 API 흐름에서는 소유자가 세션 키의 권한을 승인하는 EIP-712 타입 데이터에 서명하는 것이 이에 해당합니다.

검증은 설정 시점뿐 아니라 상태를 변경하는 모든 동작 전에 이루어져야 합니다. 에이전트가 되돌릴 수 없는 작업을 하기 전에 alchemy --json --no-interactive wallet status --verify을 실행하세요. 이는 활성 서명자, 세션 만료, 활성화된 기능을 반환하여, 에이전트(또는 당신의 오케스트레이션 코드)가 진행하기 전에 세션이 여전히 유효한지 확인할 수 있게 합니다.

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

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

에이전트 접근 취소가 즉각적으로 이루어지도록 보장하는 방법

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

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

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

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

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

Agent Wallets vs. Wallet API 세션 키

Agent Wallets와 Wallet API를 통한 세션 키 사용 모두 프라이빗 키를 에이전트로부터 격리합니다. 차이가 나는 부분은 필요한 통제 수준, 실제로 누가 에이전트에 위임하는가, 그리고 취소가 어떻게 작동하는가입니다. 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 메인넷에서만 가능합니다. 제약: 세션을 통한 원시 EVM 서명은 불가능하며, 후원 정책은 지출 한도가 아닙니다.

AI 에이전트가 프라이빗 키를 노출하지 않고 승인된 지갑 세션을 사용하도록 하는 프로바이더에는 무엇이 있는가?

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

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

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

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 API 세션 키를 통해 세션을 프로비저닝하세요.

온체인 정산을 기다리지 않고 AI 에이전트의 온체인 트랜잭션 권한을 즉시 취소하기 위한 권장 아키텍처는 무엇인가?

서명되거나 브로드캐스트되기 전에 모든 요청을 검사하는 백엔드나 엔클레이브 계층에 집행을 두고, 온체인에 저장된 권한 상태와는 분리하세요. 그곳에서 취소하는 것은 해당 검사를 삭제하거나 무효화하는 것을 의미하며, 이는 즉시 효력이 발생합니다. 유일한 취소 경로가 온체인에서 검증자나 서명자를 변경하는 것이라면, 당신의 킬 스위치는 블록 타임에 묶이게 됩니다.