Using keypair isolation for AI agents using MetaMask Smart Accounts

Smart Accounts
1

Trying to understand if ERC-4337 + delegation gets you there or if the agent always inherits exposure from the owner’s signing key?

2

You’re on the right track — ERC-4337 + MetaMask Smart Accounts Kit delegation does enable true keypair isolation for AI agents. Quick summary:

  • Isolation: The agent holds its own keypair (e.g., in an HSM, secure enclave, or backend) and never receives the owner’s private key.
  • Delegation: Use the Smart Accounts Kit to issue a delegated key with caveats (method/window/value/time limits, etc.). The Smart Account contract enforces those caveats on-chain.
  • Flow: owner mints a delegation for agentKey → agent signs UserOperation with agentKey → Smart Account verifies delegation caveats and executes.
  • Best practices: store agent keys securely, set least-privilege caveats, add expirations and revoke/update delegations via the Smart Account.

See the Smart Accounts Kit delegation docs and API reference for implementation details: https://docs.metamask.io/smart-accounts-kit/delegation/ and https://docs.metamask.io/smart-accounts-kit/reference/.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours

3

With ERC-7715 delegating agent permissions from a user’s existing wallet — what’s the recommended pattern when you want the agent to have a completely isolated treasury that never traces back to the owner’s account? Is that a Smart Accounts use case or something outside your current scope?"

4

H @Ed_Scocco You may check wth Node.js SDK as it is designed for server-side authentication and key management. Kindly let us know if you need something else.

5

Built something similar for the MetaMask × 1Shot × Venice hackathon — sharing the pattern in case it helps.

Project: r402 Sentinel — a proof-bound agent firewall on Base.

Flow:
User intent → Venice planner (min-authority plan) → ERC-7715 root periodic USDC grant (MetaMask Flask) → bounded child scopes (payment / execution / proof) → x402 paid request → 1Shot relay → ProofRegistry anchor → revoke.

Key isolation pattern:

  • User Smart Account holds the root ERC-7715 permission only
  • Session orchestrator is a separate smart account identity (NEXT_PUBLIC_SESSION_ACCOUNT)
  • Child scopes are narrowed per role: x402 seller only, 1Shot relay only, ProofRegistry only
  • Every paid request is bound to a single requestDigest (method + URL + body + quote + plan + delegation hash) — replay blocked before payment

What we learned the hard way on live Base:

  1. ERC-7715 grant to must be the 1Shot relayer targetAddress from getCapabilities — NOT the session/orchestrator account, or the relayer can’t redeem
  2. Periodic permission + 1Shot needs two USDC legs in the bundle (~$0.01 relayer fee + ~$0.01 work transfer) — empty workCall → invalid-execution-length
  3. User Smart Account needs ~$0.02 USDC on Base before Execute; grant only sets limits, doesn’t fund balance
  4. Server-side anchor key must be a plain EOA — Smart Account as ANCHOR_PRIVATE_KEY hit in-flight tx limits

Revoke is immediate: invalidate root permission context → all child agents dead.

Repo: GitHub - karagozemin/r402: Proof-bound agent firewall for MetaMask Smart Accounts. One bounded permission. Narrow child agents. Every payment tied to the exact request. · GitHub (live mode works with Flask 13.9+ on Base)

Curious how others are splitting planner vs executor vs payment agent keys — did you go full 7710 redelegation or direct grant to relayer?