Back
Learn

The AI Agent Wallet Problem: Why Your Architecture Needs Dual Keys

February 6, 2025
Learn why AI agent wallet architecture using dual keys, TEEs and non-custodial wallets maximizes security, autonomy, compliance & ease of use for platforms & launchpads. 

AI agent platforms, launchpads and developers need to think critically about how they set up their wallet architecture. Why? Setting up your AI agent wallets improperly can create a honeypot that hackers can attack. Here are 4 important implementation vectors that developers need to consider:

  1. Security: How secure are the agent wallets? Can the keys be leaked?
  2. Autonomy: Can the agent act autonomously?
  3. Compliant: Is my platform non-custodial? Is this legal?
  4. Ease of Use: Is the UX acceptable?

In the article below, we will explore different implementations of AI agent wallets that ultimately fail our needs and learn why a dual key architecture maximizes security, autonomous operations, compliance and ease of use.

The Core Problem

Building an AI agent platform is fundamentally different from building a web3 application. In a typical dApp, the user initiates every transaction. With AI agents platforms, the wallet needs to act autonomously while still giving the owner ultimate control.

This creates a triangle of competing needs:

  1. The agent must control the wallet 
  2. The owner must control the wallet 
  3. The platform can’t control wallet 

The platform can control the wallets but that opens the platform up to risk around user trust (users can talk about how the platform can take funds out at any time), security (hackers can go after all of your agent’s wallets), and legal risk (the platform could be understood as having control over the keys and thus the wallet would be considered as custodial, which requires additional compliance obligations).

To find a solution that satisfies all 3 of these competing needs, let’s explore the other architectures that ultimately led to our solution:

Server-side keys in env variables

  • Simple to implement
  • Not secure (agent or tools may leak the key)
  • Regulatory nightmare (infra provider has wallet control)
  • Best suited for development but not platforms

Managed key services

  • Better security (key can’t be leaked)
  • Still custodial (just with extra steps)
  • Same regulatory issues
  • Best suited for self hosted but not platforms

TEE Cloud

  • Key is generated inside of a TEE and the agent loop runs inside it
  • Better security (key can’t be leaked, but only the agent can use it)
  • Agent owner can’t control it
  • A “backdoor” needs to be introduced in order for the owner to control it

TEEs (Trusted Execution Environment) get us closer to our solution as they are hard-isolated enclaves where:

  1. Keys are secured: Encrypted in memory, inaccessible to host
  2. Logic is protected: Agent code runs in verified environments
  3. Compliance is built-in: No platform access = no custodial risk

The Solution: Dual Key Architecture

The breakthrough comes from treating wallet keys not as single entities but as authorization layers. Here's how it works:

Each agent gets a smart contract wallet with two keys:

  1. An Owner Key that stays with the owner
  2. An Agent Key that lives in a Trusted Execution Environment (TEE)

The Owner Key functions as a master override – the owner can use it to halt the agent, withdraw funds, or modify permissions. Think of it as the emergency brake.

The Agent Key operates inside a TEE and the agent uses this key for day-to-day operations, but it can only perform actions within the boundaries set by the smart contract.

A dual key architecture is ideal for hosted agents - agent keys can’t be leaked, owner and agent retain control and the launchpad can remain non-custodial. 

Implementing Dual Key Architecture

Dual Key Architecture requires a Smart Contract Wallet (or an account abstraction wallet), an Owner Key and an Agent Key:

Smart Contract Wallet

The Smart Contract Wallet is a shared wallet that is implemented using ERC-4337 on EVM chains or Squads protocol on Solana. This wallet type is a single wallet which can have multiple keys.

Examples: Crossmint Agent Wallet, ZeroDev, Biconomy

Owner Key

The Owner Key represents the owner's ultimate control over the wallet. It is a non-custodial signer, owned by the user. It can be implemented through various mechanisms:

  • Passkey authentication (Face ID or Touch ID)
  • External wallets like MetaMask, Phantom
  • Embedded wallets

Agent Key

The Agent Key is deployed by the agent within its own TEE and is subsequently registered by the agent to the smart wallet. This key needs to:

  • Generate inside the TEE
  • Stay inside the TEE
  • Only sign transactions that meet predefined criteria

Additional Benefits of Dual Key Architecture

In addition to maximizing security, autonomous operations, compliance and ease of use, this AI agent wallet architecture allows for:

  • Programmatic guardrails using modules
  • Sponsored gas
  • Transaction batching
  • Cross-chain signers and balances (using EVM and Solana wallets to sign)

Building with Crossmint Agent Wallets

Crossmint Agent Wallets allow developers to launch AI agent platforms and launchpads that can scale reliably to millions of users. They are fully non-custodial, which means:

  • Crossmint never has access to your agents’ wallets
  • Launchpads never have access to their agents’ wallets
  • Keys stay completely private
  • Agent platforms cannot be considered to control the wallet

Getting started is simple:

  • One line of code to create agent wallets
  • Connect with MetaMask, passkeys or social login
  • Build anything from DeFi to payments across all major chains and 200+ GOAT SDK plug-ins

If you’re interested in building with Crossmint Agent Wallets, reach out to our sales team!