Balancing Autonomy, Control, and Compliance in AI Agent Architectures

In the rapidly evolving landscape of blockchain-based AI agents, non-custodial security and developer control aren’t just nice-to-haves—they’re existential requirements. This article presents a wallet architecture that maximizes (1) security, (2) autonomous operations, (3) compliance and (4) ease of use.

---

Why This Matters

AI agent platforms like launchpads face a critical dilemma:
- How to let agents act autonomously without giving platforms custodial control (i.e. not taking the risk if something went wrong) - How to retain end-developer control without compromising security

This solution solves both, future-proofing platforms against regulatory scrutiny while empowering developers.

The Challenge

Agent launchpads face a unique set of requirements that traditional wallet architectures don't fully address. These platforms need to:

1. Enable agent creators to deploy one or multiple agents
2. Provide seamless fund management (onramp/offramp)
3. Support autonomous on-chain operations
4. Maintain non-custodial control (ensuring the launchpad cannot control agents' wallets or funds)
5. Handle gas sponsorship

Proposed Architecture: Dual Keys + Trusted Enclaves

Core Components

The architecture centers around smart contract wallets with a dual-key system:

1) Smart Contract Wallet

• Each agent operates through its own smart contract wallet
• Implements role-based access control
• Can include additional safety measures like spending limits and address whitelists

2) Dual-Key System

• Admin Key (Developer-controlled)
• Agent Key (TEE-managed)

Why Trusted Execution Environments (TEEs)?

TEEs (like Intel SGX) create hardware-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

Battle-tested platforms:
- Phala Network
- Lit Protocol (TEE + MPC)
- Marlin Protocol

Key Management

Admin Key

The admin key represents the developer's ultimate control over the wallet. It can be implemented through various mechanisms:

• MetaMask or other external wallets
• Passkeys (face or touch ID) like Crossmint
• Social login wallets like Magic, Dynamic, Privy

The crucial aspect is that this key remains exclusively under developer control, never touching the launchpad's infrastructure.

Agent Key

The agent key enables autonomous operations and requires special handling:

• Must be generated and stored in a Trusted Execution Environment (TEE)
• Can have full or restricted permissions
• Permissions can include:
  • Maximum spend limits
  • Whitelisted contract addresses
  • Blacklisted operations

TEE Implementation

The Trusted Execution Environment is critical for maintaining non-custodial status. Key requirements include:

1) Complete Control Loop Encapsulation

• LLM API interaction
• Action processing (e.g., using libraries like GOAT)
• Key signing operations

2) Example TEE Platforms

• Lit Protocol (TEE+MPC)
• Marlin Protocol
• Phala Network

Security Considerations

Maintaining non-custodial status is crucial both for security and regulatory compliance. Non-custodial control means that the launchpad platform cannot access or control the funds in agents' wallets. This is essential not only for security but also for regulatory compliance, as controlling user funds would require costly money transmitter licenses in jurisdictions like the United States.

To ensure non-custodial operation, several security measures must be implemented:

1) Prompt Isolation

• All prompt processing must occur within the TEE
• External LLM services can be used, but prompt handling must be encapsulated

2) Action Mapping

• The correlation between prompts and on-chain actions must be secured within the TEE
• No external manipulation of action execution should be possible

3) Key Segregation

• Clear separation between admin and agent keys
• No launchpad access to admin keys
• TEE-based agent key management

Conclusion

This architecture provides a robust foundation for building non-custodial agent launchpads. By carefully implementing the dual-key system within a TEE environment, platforms can offer autonomous agent operations while maintaining security and developer control.

Remember that this architecture should be treated as a blueprint and adapted to specific platform requirements while maintaining the core principles of non-custodial control and secure autonomous operation.

Comparison with Alternative Architectures

While designing this architecture, we evaluated several alternative approaches. Here's an analysis of their trade-offs:

A. Server-Side Key Storage with Environment Variables

This approach involves storing wallet keys as environment variables in agent servers running on centralized computing platforms like AWS.

Key Issues:

• Fundamentally custodial in nature
• The launchpad platform has full access to wallet keys
• Platform can access or destroy keys at will
• Violates regulatory requirements for non-custodial control

B. Server-Side Key Management Solutions

Using solutions like Fireblocks, Turnkey, or Privy server wallets.

Analysis:

• Functionally equivalent to approach A
• More sophisticated key storage
• Still custodial as platform holds API keys
• API keys enable full wallet control and token extraction
• Does not solve the fundamental custodial control issue

C. Single TEE-Based Key Architecture

Creating a single key for the wallet inside a TEE (like Lit Protocol or Marlin Network).

Limitations:

• Suitable only for fully autonomous agents
• Developers lose all control post-deployment
• Too restrictive for most agent development use cases
• Doesn't meet the common requirement for developer oversight

D. TEE with Pre-authorized Control

Implementing approach C with a pre-authorized wallet backdoor in the TEE code.

Concerns:

• Could theoretically achieve similar properties to our proposed architecture
• Significantly more complex implementation
• Higher risk of security vulnerabilities
• Increased chance of fund compromise or loss
• Not recommended for production environments

Why Alternatives Fail

Approach	Custodial Risk	Developer Control	Compliance
Env variable keys	High	None	❌
Server keys	High	Limited	❌
Single TEE Key	Low	Hard	✅
Proposed Architecture	None	Full	✅

Key flaws in alternatives:
- Server-side storage: Platforms hold API keys = custodial
- Single TEE key: Developers lose post-deployment control
- Pre-authorized backdoors: Creates attack surfaces

Our proposed dual-key architecture provides the optimal balance of security, control, and regulatory compliance while avoiding the pitfalls of these alternative approaches. It maintains non-custodial status while giving developers appropriate control over their agents. And it is built entirely on top of open source industry standards, minimizing lock in and future-proofing to future technology updates.