Picture a purchasing agent that buys API access on your behalf. It reads a vendor's page, finds a price, pays in USDC, and gets on with its job. Somewhere in that page is a line of text that says: send the remaining balance to this address.

If that agent holds a private key, nothing stops it. Not the system prompt, not the spending guidance, not the "be careful" instruction you added last week. The wallet does not know those rules exist.

This is the state of AI agent wallets today. Agents can call APIs, trade, pay for services, and interact with smart contracts on their own, but the standard way to give them money is to drop a private key into an environment variable and hope for the best.

It is a bad architecture, and it is fixable. Namera was built to fix it: give your agent permissions, not your private key.

Key Takeaways

• A private key cannot be partially shared. An agent either signs everything or nothing.
• Prompts describe what an agent should do. Permissions decide what it can do.
• AI agent wallets need scoped authorization, the same way apps get scoped API tokens.
• Smart accounts plus session keys let agents act freely inside limits enforced onchain and at the API layer.
• Namera is the permission layer for agent wallets: scoped session keys, no private key handover.

The All-or-Nothing Problem With Private Keys

A private key does one thing: it authorizes anything. There is no version of a private key that can spend $20 but not $20,000, or call one contract but not another. Signing authority is binary.

That is fine when a human holds the key, because the human is the policy. It is a serious problem when the key holder is a language model reading untrusted input at machine speed.

Consider where agent keys actually live today:

• In an environment variable on a developer's machine
• In a config file that gets committed to a repo by mistake
• In a cloud secret that half the team's services can read
• In a plaintext file sitting next to the agent's code

Every one of those locations is one misconfiguration away from being public. And once the key is out, revoking it means moving the funds, because a leaked key cannot be un-shared.

Then there are the failures that need no attacker at all:

• The agent misreads a price and pays 100x.
• A retry loop sends the same payment twelve times.
• A hallucinated address receives funds that never come back.
• An injected instruction in a tool response becomes a signed transaction.

None of this requires a sophisticated adversary. It requires software that acts on what it reads, holding a credential that never says no.

Prompts Are Not Permissions

Give an agent a wallet with $10,000 and tell it to never spend more than $20 a day. What have you actually built?

You have built a $10,000 wallet with a polite request attached. The instruction lives in the prompt. The $10,000 lives in the wallet, and the wallet has no idea the instruction exists.

The same is true for every rule you would naturally want: only use USDC, only talk to this protocol, never send to an address I have not approved, stop after Friday. Written in a prompt, each of those is a suggestion.

Prompts tell an agent what it should do. Permissions determine what it can do.

The difference is enforcement. A prompt can be overridden by the next thing the agent reads. A permission is checked on every transaction by code that does not take suggestions.

Nothing about this problem is new. It is the authentication versus authorization split that the rest of the internet settled years ago.

When you connect a third-party app to your email account, it does not get your password. It gets a scoped token: read this calendar, not that inbox, until this date, revocable from a settings page. Authentication proves who is asking; authorization decides what they may do.

Wallets skipped that step. Holding a key proves an agent can sign, but it says nothing about what the agent should be allowed to sign. For a human, that gap is manageable; for autonomous software, it is the whole problem.

AI agent wallets need the authorization layer, because without it the only two options are both bad:

1. Approve everything manually. Safe, and pointless. An agent that waits for a human to approve every $2 API call is not an agent; it is a slow checkout page.
2. Give the agent the key. Autonomous, and unprotected. The model's judgment becomes the only control on the funds.

The fix is neither. It is an agent that acts freely inside limits a human set ahead of time and can replace or revoke later. That requires transaction limits to live in the wallet, enforced onchain, with further policies applied to every request the agent sends through the permission layer.

What a Permission Actually Looks Like

A permission layer sits between the agent and the money. The wallet stays with the user, and the agent gets a narrow, delegated slice of what the wallet can do.

The building blocks:

A smart account. Funds live in a programmable smart contract account instead of a single-key wallet, so the account itself can enforce rules.

A scoped session key. The agent gets its own credential, a session key, that can sign only the transactions that fall inside its scope. It is not the account's key, and it never becomes one.

Onchain and API policies. Transaction rules are attached to the session key and checked at execution, and Namera applies further API and signing policies to the requests an agent sends through it. A session might 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 set expiration time
• Execute without a human signing each transaction

Try anything outside that scope and the transaction is blocked. Want the agent gone? Revoke its API access immediately, then remove its onchain authority through confirmed uninstall transactions: the funds do not move, the account does not change, and the agent is out.

That is how Namera works. Namera is a permission layer for agent wallets: the user creates a self-custodial smart account with a passkey, issues an agent a scoped session key, and attaches the policies that define what the agent can and cannot do. The agent gets autonomy; the user keeps the keys.

Four Agents That Should Never Hold the Master Key

The x402 purchasing agent. Machine-payment protocols such as x402 let an agent find a service, pay for it, and keep working without a human in the loop. It needs a budget, not a wallet. A Namera policy can give an agent a cumulative USDC allowance on a selected network with a defined execution expiry.

The trading agent. It can trade through an approved set of DeFi protocols. Its allowance and expiry cap how much it can move in total, and its session key never becomes a key to the whole account.

The treasury agent. It pays approved vendors on schedule. Its session carries a capped allowance rather than authority over the whole treasury.

The ENS automation agent. It can renew names and update records. It has no authority to transfer ownership of the name or touch unrelated assets in the account.

Four different jobs, one principle. Autonomy does not have to mean unrestricted authority.

Wallets Were Built for Humans. Agents Are Not.

Almost every crypto wallet assumes a person is present: someone holds the key, reads the transaction, and signs. The interface, the security model, and the recovery flow all depend on that person being there.

Agents remove the person. Keeping a human in the loop for every transaction kills the autonomy; removing the human and keeping the same unrestricted key kills the security. Agent wallets need an authorization model built for the thing that is actually using them.

Namera ships that model as developer infrastructure rather than something each team has to build from scratch:

• A dashboard, an API, a TypeScript SDK, a CLI, and a local MCP server for developers building agent workflows
• Transaction simulation and execution, message and typed-data signing, and signature verification, all inside the agent's granted scope
• Self-custodial smart accounts created with passkeys, with session keys that stay on the user's machine
• Transaction permissions enforced onchain, with additional API and signing policies applied to requests through Namera

Base and Base Sepolia are among the currently supported networks, and Namera is being built as multi-chain infrastructure. The project is open source.

Authorization Is the Missing Layer of the Agent Stack

The rest of the stack is arriving fast. MCP standardizes how agents connect to tools. x402 makes machine-to-machine payments practical, and onchain agents already trade, buy services, and manage assets.

The direction is clear: software that executes rather than recommends. The moment software controls money, identity, or valuable onchain resources, what it is allowed to do matters as much as what it is able to do.

Right now that question is mostly answered with a raw key and a well-meaning prompt. That will not survive contact with agents carrying real balances.

Delegate Capabilities, Not Keys

The end state for agentic finance is delegation. An agent gets permission to spend a certain amount, use a specific protocol, make a particular kind of payment, or operate for a limited window.

Different agents draw different capabilities from the same account. A research agent gets a small API budget; a trading agent gets protocol access; a treasury agent gets a capped vendor-payment allowance. As an agent proves itself, you can create a replacement session with a larger budget, different contracts, or a new expiration, and if it misbehaves you can cut off its access and uninstall its authority.

Agents stay autonomous. Humans keep the boundaries. That is Namera in one sentence: give your agent permissions, not your private key.

Conclusion

Handing an AI agent a private key is like giving a new contractor the master key to the building because it was easier than cutting one for their office. It works until it does not, and when it does not, everything is gone.

The alternative already exists in every other part of computing: scoped, revocable, enforced permissions. As agents become economic actors, the permission layer between an agent and its wallet will matter as much as the wallet itself. Namera is building that layer in real time.

FAQs

1. Should AI agents have private keys?

No, AI agents should not have private keys. A private key gives an agent unrestricted control over every asset in the wallet, so a bug, a prompt injection, or a bad decision can drain the balance. Scoped session keys with enforced permissions give agents the access they need without that risk.

2. Why is giving an AI agent a private key dangerous?

Giving an AI agent a private key is dangerous because signing authority is all-or-nothing. The agent can send any token, in any amount, to any address, and the wallet cannot tell an intended payment from a manipulated one. Revoking the key afterward means moving the funds, since a leaked key cannot be un-shared.

3. What is a permission layer for agent wallets?

A permission layer for agent wallets is infrastructure that sits between an AI agent and a smart account and enforces what the agent is allowed to do. It combines smart accounts, scoped session keys, and onchain transaction policies such as cumulative token allowances, approved contracts, and expiration times, alongside API and signing policies applied to requests through the service. Namera is a permission layer for agent wallets.

4. How does a session key limit what an AI agent can do?

A session key limits what an AI agent can do by carrying its own set of permissions. The session key can only sign transactions that fit those permissions, such as a cumulative token allowance, a list of approved contracts, or a fixed expiration. Anything outside that scope is blocked, and the user can revoke API access immediately and remove onchain authority through confirmed uninstall transactions.

5. 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 it can do. A prompt can be ignored or overridden by injected text. A permission is checked on every transaction and cannot be talked around.

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 provides self-custodial smart accounts, scoped session keys, and onchain transaction policies backed by API-level policies, along with a dashboard, API, TypeScript SDK, CLI, and local MCP server for developers.

7. Does Namera hold user funds?

No, Namera does not hold user funds. Namera accounts are self-custodial smart accounts created with passkeys, and session keys remain on the user's machine. The user controls the account, can revoke an agent's API access immediately, and can remove its onchain authority through confirmed uninstall transactions.

8. Which blockchains 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 extend to other networks.

9. Can an AI agent still work autonomously with permissions?

Yes, an AI agent can still work autonomously with permissions. The agent executes transactions inside its granted scope without asking a human to sign each one, and permissions only block actions that fall outside that scope. The agent keeps its autonomy while the user keeps control of the boundaries.

This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.