How to Give an AI Agent a Wallet Without a Private Key

A purchasing agent can automatically buy API access on your behalf by reading vendor pages, determining prices, and making USDC payments. However, when that agent holds a private key, it can ignore any spending guidelines or restrictions you set. This is a significant security concern. The standard method of providing funds to AI agents involves placing a private key in an environment variable, which is an insecure practice.

To address this issue, Namera has been developed as a permission layer for agent wallets, enabling scoped authorization without the need to share private keys. The key takeaways are that a private key cannot be partially shared, an agent must sign or not sign at all, prompts describe desired actions, and permissions determine what an agent can do.

AI agent wallets require scoped authorization, similar to how apps use scoped API tokens. The "all-or-nothing" problem with private keys means that a key can either authorize any action or none at all, which is problematic when the key holder is a language model reading untrusted input at high speed. Today, agent keys are often stored in environment variables, config files, cloud secrets, or plaintext files, all of which can be compromised.

Once a key is leaked, revoking it requires moving the funds since the key cannot be un-shared. Common failures include misreading prices, infinite retries, paying to incorrect addresses, and executing signed transactions from hallucinated data. Prompts alone cannot provide sufficient permissions; they only describe what an agent should do.

Permissions, on the other hand, enforce what an agent can do. Without an authorization layer, the only options are either manual approval of every transaction (inefficient) or giving the agent the key (unprotected). The solution is an agent that acts within limits set by a human ahead of time and can have those limits revoked later.

This requires transaction limits to be enforced onchain, with additional policies applied to every request sent through the permission layer. A permission layer sits between the agent and the funds, with the wallet remaining with the user and the agent receiving a narrow, delegated slice of the wallet's capabilities. The building blocks include a smart account that can enforce on-chain rules, a scoped session key that can only sign transactions within its scope, and on-chain and API policies attached to the session key.

These policies can limit spending amounts, restrict interactions to specific contracts and tokens, enforce transaction types, set expiration times, and prevent unauthorized actions. To revoke an agent, simply revoke its API access and remove its on-chain authority with confirmed uninstall transactions, ensuring the funds remain untouched.