AI agents are moving from answering questions to taking actions. They call APIs, interact with smart contracts, trade assets, buy services, manage onchain positions, and execute transactions without a human approving every step.
That shift raises a question every team building agents eventually runs into. How do you give an autonomous agent access to money without giving it unrestricted control over the wallet?
The most common answer today is also the most dangerous one: give the agent a private key. Put it in an environment variable, a config file, or a secret on a cloud server, and let the agent sign whatever it needs to sign. Once the agent holds that key, the difference between “you can make this $5 payment” and “you can transfer everything in this wallet” comes down to whether the agent behaves.
That is the wrong architecture for AI agent wallets. Namera is built on a different model: give your agent permissions, not your private key.
Key Takeaways
- A private key gives an agent all-or-nothing control, so one exploit can drain everything.
- Prompts tell an agent what it should do. Permissions determine what it can do.
- AI agent wallets need authentication and authorization separated, like the rest of the internet.
- Smart accounts, scoped session keys, and onchain policies let agents act autonomously inside enforceable limits.
- Namera is the permission layer for agent wallets: scoped access without handing over private keys.
What Happens When an AI Agent Holds a Private Key
A private key is the root credential of a crypto wallet. Whoever holds it can sign any transaction the wallet is capable of sending: any token, any amount, any contract, any destination, at any time.
When you give an AI agent that key, you hand over every one of those capabilities at once. There is no way to share part of a private key. The agent can either sign everything or sign nothing.
That creates a blast radius problem, because autonomous agents fail in ways traditional software does not:
- Prompt injection. An agent that reads web pages, emails, or tool outputs can be manipulated by text it encounters. If that agent holds a key, an injected instruction can become a signed transaction.
- Hallucinated actions. A model can misread a task, invent an address, or misunderstand a price, then execute with full confidence.
- Exposed infrastructure. Keys stored in environment variables, config files, or server secrets are visible to every dependency, log stream, and operator with access to that environment.
- Runaway loops. An agent stuck retrying a failed purchase can repeat a payment dozens of times before anyone notices.
None of these failures are exotic. They are the ordinary failure modes of software that reads untrusted input and acts on it. A private key turns each of them into a potential total loss.
| Control | Private key access | Permissioned access |
|---|---|---|
| Spending scope | Entire wallet balance | A cumulative allowance on one network |
| Contract scope | Any contract | Approved contracts only |
| Token scope | Any asset | Specific tokens only |
| Duration | Indefinite | Until a defined expiration |
| Revocation | Move the funds to a new wallet | Revoke API access, then uninstall onchain authority |
| Enforced by | The agent’s behavior | Onchain policy for transactions, plus API-enforced policies |
Prompts Are Not Permissions
Suppose you give an AI agent a wallet holding $10,000 and tell it: “Never spend more than $20 per day.”
That is an instruction. It is not a security boundary. The wallet still allows the agent to spend all $10,000, and the only thing standing between the instruction and the balance is the agent’s willingness to comply.
The same gap appears whenever you tell an agent to interact only with a particular protocol, use only USDC, avoid sending funds to unknown addresses, or stop operating after a certain date. Each of those rules lives in the prompt. None of them live in the wallet.
Prompts tell an agent what it should do. Permissions determine what it can do.
As agents gain the ability to control real assets, that distinction becomes fundamental. A system prompt can be overridden, misread, or ignored. An enforced permission cannot be talked out of its limits, because it does not reason; it checks the transaction against the policy and either allows it or blocks it.
Why AI Agent Wallets Need Permissions, Not Private Keys
The traditional internet already solved a version of this problem. Applications do not get unlimited access to every resource simply because they authenticated successfully. Modern systems separate authentication (proving who you are) from authorization (defining what you are allowed to do).
Think about how a third-party app connects to your calendar. It receives a token scoped to specific actions, with an expiration, that you can revoke from a settings page. It never receives your password.
Crypto wallets largely skipped that layer. Proving that an agent possesses a key answers one question: can this agent sign? It does not answer the more important question: what should this agent be allowed to sign?
AI agent wallets need that second question answered in code, not in prose. Without it, teams are forced to choose between two bad extremes:
- A human signs every transaction. This is safe but destroys the autonomy that made the agent useful. A purchasing agent that pauses for approval on every $2 API call is not autonomous.
- The agent holds an unrestricted key. This preserves autonomy but removes every safeguard. The agent’s judgment becomes the only thing protecting the funds.
The middle ground is an agent that acts on its own inside boundaries a human defined in advance and can replace or revoke later. Building that middle ground requires permissions that are enforced at the wallet level, which is exactly what a permission layer for agent wallets provides.
How a Permission Layer for Agent Wallets Works
A permission layer sits between an agent and the account that holds funds. Instead of the agent owning the wallet, the wallet delegates specific capabilities to the agent. Three components make this work.
Smart accounts. The user’s funds live in a smart contract account rather than a single-key wallet. Because the account is programmable, it can enforce rules about who is allowed to do what.
Scoped session keys. The agent receives a session key, a separate credential with narrowly defined capabilities. The session key can sign transactions, but only transactions that fall inside its scope.
Enforceable policies. Transaction scope is defined by policies attached to the session key and enforced when a transaction is submitted, alongside the API and signing policies Namera applies to the requests an agent sends through it. A session could allow an agent to:
- Spend up to a cumulative USDC allowance on one network
- Interact only with approved contracts
- Use only specific tokens
- Perform only approved types of transactions
- Operate until a defined expiration time
- Execute without asking the user to sign each individual transaction
If the agent attempts anything outside those permissions, the transaction is blocked. The user can revoke API access immediately, and the agent’s onchain authority ends once uninstall transactions confirm, without moving funds or replacing the underlying account.
This is the model Namera is built on. Namera is a permission layer for agent wallets: a user creates a self-custodial smart account with a passkey, grants an agent a scoped session key, and attaches the policies that define what that agent can do. The agent operates autonomously within those limits and never receives the user’s private key, because the model does not require it.
What Permissioned Agent Wallets Look Like in Practice
The pattern is easiest to see through the agents people are actually building.
A purchasing agent using x402. Machine-payment protocols such as x402 let an agent discover a service, pay for it, and continue its task without waiting for a human. That agent needs enough autonomy to pay, but it does not need the user’s entire wallet. A Namera policy can give an agent a cumulative USDC allowance on a selected network with a defined execution expiry.
A trading agent. A trading agent can be allowed to trade through a specific set of DeFi protocols, with a cumulative allowance and an expiry that cap how much it can move. It can rebalance a position inside those limits, and its session key never becomes a key to the whole account.
A treasury agent. A treasury agent can pay approved vendors on schedule with a capped allowance rather than authority over the whole treasury. Payroll runs, and the exposure stays bounded.
An ENS automation agent. An ENS agent can receive permission to renew names or update records without receiving authority to transfer ownership of the name or control unrelated assets in the same account.
The important idea is the same in every case. Autonomy does not have to mean unrestricted authority.
Building Wallets for Agents, Not Just Humans
Most crypto wallets were designed around a human being present. The user controls a private key and signs when something needs to happen. Wallet interfaces, security assumptions, and recovery flows all assume that person is in the loop.
Agents break that assumption. If an autonomous agent needs a person to approve every transaction, much of its autonomy disappears. But removing the human and handing the agent the same unrestricted signing authority creates a new security problem instead of solving the old one.
Agent wallets need a different authorization model, and developers need to be able to integrate it rather than rebuild it for every project.
Namera currently provides a dashboard, an API, a TypeScript SDK, a CLI, and a local MCP server for developers building agent workflows. Through these, agents can simulate and execute transactions, sign messages and typed data, and verify signatures, all within the permissions they have been granted.
The security model is deliberately conservative:
- Accounts are self-custodial smart accounts created with passkeys.
- Session keys remain on the user’s machine.
- Transaction permissions are enforced onchain, while additional API and signing policies apply to requests through Namera.
- API access can be revoked immediately, and onchain authority is removed once uninstall transactions confirm.
Base and Base Sepolia are among the currently supported networks, and Namera is being built as multi-chain infrastructure. The project is open source.
The Agent Economy Runs on Authorization
The surrounding infrastructure is maturing quickly. MCP gives agents standardized ways to connect to tools. Payment protocols such as x402 make machine-to-machine payments practical, and onchain agents can already trade, purchase services, interact with protocols, and manage digital assets.
The industry is moving toward software that does not merely recommend an action but executes it. Once that software controls money, identity, or valuable onchain resources, authorization becomes one of the most important pieces of the stack.
Almost every other layer of the agent stack is being standardized: how agents call tools, how they pay, how they hand work to each other. The layer that defines what an agent is allowed to do with a wallet is still, in most deployments, a raw key and a hopeful prompt. That will not hold as agents take on real economic responsibility.
From Wallet Ownership to Delegated Capabilities
The long-term model for agentic finance will look less like giving every agent its own unrestricted private key and more like delegating capabilities.
An agent may receive permission to spend a certain amount, access a specific protocol, make a particular type of payment, or operate for a limited period of time. Different agents can receive different capabilities from the same underlying account. A research agent gets a small API budget, a trading agent gets protocol access, and a treasury agent gets a capped vendor-payment allowance.
Those permissions can evolve as an agent earns trust or as its responsibilities change. Create a replacement session with a larger budget, different contracts, or a new expiration. Or cut off its access and uninstall its authority if something goes wrong.
That model lets agents remain autonomous while humans retain control over the boundaries. It is the idea behind Namera in one sentence: give your agent permissions, not your private key.
Conclusion
AI agents are becoming economic actors, and the way they are authorized has to catch up with what they can do. A private key was the right credential for a human with a hardware wallet; it is the wrong credential for autonomous software that reads untrusted input and acts on it.
Permissions, enforced at the wallet, give agents the autonomy they need inside limits a human actually controls. As that shift plays out, the permission layer between an agent and its wallet will become as important as the wallet itself. Namera is building that layer.
FAQs
1. Should AI agents have private keys?
No, AI agents should not have private keys, because a private key grants unrestricted control over every asset in a wallet. An agent holding a private key can drain the wallet through a bug, a prompt injection, or a single bad decision. Scoped session keys with enforceable permissions give agents the access they need without exposing the full balance.
2. What is an AI agent wallet?
An AI agent wallet is a crypto account that an autonomous AI agent uses to pay for services, trade assets, and interact with smart contracts without a human signing each transaction. The safest AI agent wallets use smart accounts and scoped permissions instead of giving the agent a raw private key.
3. What is a session key for an AI agent?
A session key for an AI agent is a limited credential that lets the agent execute transactions from a smart account within defined boundaries. A session key can restrict cumulative spending, approved contracts, permitted tokens, transaction types, and expiration time. The user can revoke API access immediately and remove onchain authority through confirmed uninstall transactions.
4. What is the difference between a prompt and a permission?
The difference between a prompt and a permission is that a prompt tells an AI agent what it should do, while a permission determines what an AI agent can do. Prompts can be ignored, misread, or overridden by injected text. Permissions are checked against every transaction and block anything outside the allowed scope.
5. Can an AI agent use a crypto wallet without a private key?
Yes, an AI agent can use a crypto wallet without a private key by using a smart account and a scoped session key. The smart account holds the funds, the session key lets the agent sign transactions inside its permissions, and the account enforces those permissions when a transaction is submitted.
6. What is Namera?
Namera is a permission layer for agent wallets. Namera gives AI agents scoped, programmable access to smart wallets without giving them unrestricted private keys. It combines self-custodial smart accounts, scoped session keys, and onchain transaction policies backed by API-level policies, with a dashboard, API, TypeScript SDK, CLI, and local MCP server for developers.
7. Is Namera self-custodial?
Yes, Namera is self-custodial. Users create smart accounts with passkeys, session keys remain on the user’s machine, and the user can revoke an agent’s API access immediately and remove its onchain authority through confirmed uninstall transactions.
8. Which networks does Namera support?
Namera currently supports Base and Base Sepolia, and it is being built as multi-chain infrastructure so the same permission model can work across multiple networks.
9. What happens if an AI agent tries to make a transaction outside its permissions?
If an AI agent tries to make a transaction outside its permissions, the transaction is blocked. A transaction that exceeds the spending limit, targets an unapproved contract, uses a token outside the allowed set, or arrives after the expiration time is rejected by the policy. The agent’s permissions, not its judgment, decide what gets executed.
