The Missing Piece: A Self-Custody Wallet for AI Agents

Everyone talks about the web3 + AI symbiosis. Nobody is actually shipping a self-custody, agent-native wallet.

I noticed this the way you tend to notice these things: by building something that exposed the gap. I'd been working on a small MCP server for CoW Protocol so an AI agent could place swaps on my behalf. The MCP itself was the easy part: a thin protocol adapter that builds the EIP-712 typed data, exposes a few tools, and explicitly never holds a key. The hard part came right after, when I sat down to wire it up to a wallet and asked the obvious question: which wallet actually signs for the agent?

I expected to plug into something. I went looking, and none of the options were the shape I wanted.

The Landscape Today

To allow an agent to use MCP to sign a blockchain transaction, your options split cleanly into two buckets, and the asymmetry between them is the whole story.

The first bucket is the well-funded one: hand your keys to a third party. Ready-to-use MCP servers exist for several custodial or TEE-backed signing services:

The shape is consistent across all of them. The provider holds the key material in a Trusted Execution Environment or splits it via MPC. The agent calls a signing API. An off-chain policy engine on the provider's servers decides yes or no based on rules you configured ahead of time. It's fast and easy to integrate. The trust model is what it is: you trust the enclave attestation and the policy engine.

The second bucket, where you keep your keys local, is where the picture gets thin:

That's the entire list of options I found.

Why This Bothers Me

There's a phrase that's been around since 2014: not your keys, not your coins. It's a stance, not a slogan. The whole reason crypto exists as a separate thing from a Stripe account is that custody is supposed to be the user's, not a provider's. Every time we've collectively forgotten that, somebody got rugged. Self-custody isn't a power-user preference. It's the assumption that makes the rest of the system meaningful.

Now we're at the start of a wave where AI agents will move money on people's behalf, and the default products do a softer version of the same thing. Phantom, Privy, Coinbase, Turnkey. All variations of the same shape: the vendor holds the key (often in a TEE, fine), runs the policy engine, and signs on your behalf. The load-bearing trust is the vendor's: their hardware, their policy engine, their continued willingness to sign for you. Fine on the happy path. Wrong on the day they freeze you, get compromised, get compelled by a court, or quietly change policy. Most users will take that trade because the alternative isn't on the shelf. A custody model whose worst case is "trust the vendor" is the model crypto was supposed to be an alternative to.

Agents make this worse, not better. An autonomous program signing transactions on your behalf is an enormous trust surface. The right response is to bound what it can do at the layer the system can actually enforce (the smart contract), not to bolt on more vendor-side promises.

Session Keys Resolve the Tension

The classic objection: if only you can sign, the agent can't do anything autonomously, which defeats the point. That was true when the only signing primitive was the master key.

Session keys with on-chain caveats resolve the tension. You hold the master key. You sign one transaction granting a session key the right to do exactly what you want the agent to do, on-chain, enforced by a smart contract: only this protocol, only these tokens, only up to this much, only for this long. The agent holds the session key and operates within those bounds. When the session expires or you revoke it, the agent has no authority. EIP-7702 lets a plain EOA delegate to a smart-account contract directly, removing the 4337 bundler from the signing path. That matters: until now, every "self-custody smart wallet" had a paid commercial RPC sitting between the user and their signature.

The model that falls out of this is occasional human-in-the-loop, not constant.

The human approves the policy once: scope, caps, expiry. The agent operates within the policy without prompting. The human is back in the loop only when the agent wants to do something the policy doesn't cover.

That's not friction; that's the trust boundary in the right place. Constant approvals make autonomous use unworkable. Vendor policy engines hand custody back. Session keys with on-chain caveats are the answer crypto already has, and nobody ships it.

What's Missing

Concretely:

MCP signer + ERC-7715 grant + passkey-backed session. Human approves the policy once, agent operates within scope.

Every piece exists separately. ERC-7710 and ERC-7715 are still draft ERCs, but the shape has stabilized enough that wallet teams are shipping against them. The MetaMask Smart Accounts Kit (formerly Delegation Toolkit) ships an audited EIP7702StatelessDeleGator deployed on mainnet, with caveat enforcers for target contracts, function selectors, value caps, and expiry. It can be invoked directly via the EOA without a 4337 bundler. mcp-wallet-signer's transport, MCP server, and approval-routing pattern is solid. Passkeys give us a hardware-backed signer the OS already handles: keys live in Secure Enclave or TPM, the user authorizes with biometrics, and smart accounts can verify the resulting signatures on-chain via the P-256 precompile (RIP-7212 on L2s, EIP-7951 on mainnet since Fusaka).

MetaMask is the closest existing actor to shipping this, and they've said as much in public. Their 2025 roadmap names "Decentralized AI Agents — securely delegate investment and financial decisions without ceding control or locking up funds" as a target use case for the Delegation Framework. They have the delegation primitives, they have the wallet, they're clearly working toward it. The agent-facing product hasn't landed yet, and even when it does, the browser-extension form factor isn't a great fit for the local-daemon pattern. An extension can't be the persistent signing surface a long-running agent talks to without a browser tab open.

What's missing is an opinionated bundle: a local daemon that reads an encrypted keystore from disk and acts as the single signing surface for the agent. Concretely, it would:

None is novel by itself. The composition is. Frame did the OS-prompt half; session-scoped silent signing simply wasn't a problem they needed to solve. ZeroDev gets session keys right but assumes the orchestration happens in a webapp. Safe + Zodiac does the on-chain enforcement but assumes a multisig UI. Nobody fits the pieces into a thing a single user can run on their own machine, against their own keys, with their own agent on the other end of the MCP socket.

Proposed Architecture

Two MCP surfaces, on purpose. cow-mcp builds typed-data; the daemon signs it. The split is the same separation any wallet has from any dapp — the protocol adapter knows the shape of the transaction, the wallet knows how to authorize it, neither leaks into the other.

There's good prior art to draw from. mcp-wallet-signer already has the right shape for the agent-facing side: an MCP server, a local approval HTTP endpoint, a pending-store pattern that holds requests until the user resolves them. Frame already proved the OS-level signer half: encrypted keystore on disk, system-tray daemon, local JSON-RPC, native approval prompts, hardware wallet support. The cleaner answer is probably to reimplement the patterns from both in a fresh codebase aimed at the agent use case, with the signing layer wrapping the EOA in MetaMask Smart Accounts Kit delegations on top of EIP-7702. That's the piece that keeps a commercial bundler RPC out of the most sensitive code path. The master-key passphrase prompt goes through the OS keychain. Session creation is itself an MCP tool, so the agent can ask for a scoped delegation and the user authorizes it without leaving the conversation.

The crypto here is solved. The work that's left is daemon-level. A secure passphrase-prompt channel that doesn't get phished. Mid-task session revocation while the agent is in flight. Nonce management across daemon restarts. None of these are research-grade problems. They just haven't been stitched together with this use case in mind.

Back to the original problem. My CoW MCP wants to swap on my behalf. With the daemon I've described, I'd sign once (allow swaps on CoW, USDC↔ETH only, up to 0.5 ETH total, expires in 24 hours), and the agent operates inside that envelope. When the session expires, the agent has no authority. No vendor in the loop. No funds locked up. No bundler dependency.

If we're serious about web3 + AI being a symbiosis instead of a rebrand, the agent's wallet has to be ours, not the vendor's. The pieces are on the shelf. I'm starting to sketch one — follow my GitHub for the first cut.

If this is your kind of problem, I want to hear from you. Compare notes, push back on the architecture, or build it together. Tell me what I missed. Find me on Bluesky or X.