Why "just give the agent a private key" breaks in production
Handing a private key to an AI agent is the onchain equivalent of giving a contractor your house keys, your car keys, and your bank card — because they need to fix the sink. The access is wildly disproportionate to the task.
In 2026, autonomous agents are executing real transactions at real scale. The infrastructure question is no longer "can an agent sign a transaction?" It's "how do you constrain what it signs, when, and against which contracts?" and "what degree of autonomy you want for your agent, without compromising on safety."
That's the problem session keys and programmable smart accounts solve. Below are seven production-ready use cases where this matters concretely.
Use Case 1: DeFi Trading, Rebalancing, and Yield Optimization
A trading bot needs to call swap() on Uniswap or rebalance() on a vault contract. It does not need to transfer your entire treasury to an arbitrary address.
With a scoped session key, you issue the agent a key that is valid only for specific contract addresses, capped at a defined gas limit per transaction, and expires after a set window. If the agent gets compromised or behaves unexpectedly, the blast radius is bounded by policy, not by your response time.
The policy composition here is practical: a call policy restricts which contract methods can be invoked, a gas policy caps per-transaction spend, and a timestamp policy enforces the trading window. All three rules must pass onchain before execution proceeds. The owner key stays offline the entire time.
For high-frequency strategies that need parallel execution, Namera supports nonce lanes, which let you run multiple transactions concurrently without nonce collisions. That's a real architectural requirement for any bot doing meaningful volume.
And when it comes to Yield Optimization, monitoring rates across Arbitrum, Base, and Optimism simultaneously and moving funds when the spread justifies the bridge cost is exactly the kind of task that benefits from automation. It's also exactly the kind of task where a mistake is expensive and difficult to unwind.
The constraint architecture here involves multichain routing with per-chain spending limits and approved bridge contract lists. The agent can move funds between chains — but only through whitelisted bridge contracts, only up to a defined amount per 24-hour window, and only into approved yield protocols on the destination chain.
Namera's smart accounts support multichain routing natively, so you can issue a single session key that carries consistent policy enforcement across chains rather than juggling separate keys per network.
Use Case 2: Autonomous Payment Agents
Subscription billing, payroll disbursement, pay-per-use API settlement, x402 micropayments: these all share a pattern. An agent needs to move value on a recurring or triggered schedule, but the amounts, recipients, and timing are bounded and predictable.
The naive implementation is a hot wallet with a private key sitting in an environment variable. The production implementation is a session key with a rate-limit policy (e.g., max N transactions per hour) and a call policy scoped to the specific payment contract or token address.
This matters for multi-tenant systems especially. If you're running payment agents for multiple customers, each agent gets its own session key with its own policy envelope. One agent's permissions cannot bleed into another's. Revocation is per-key, so you can terminate access for a single tenant without rotating the owner signer or touching other agents.
Agent-native payment protocols like x402 and MPP are designed for exactly this execution model. The agent pays for what it uses, within defined limits, with no human in the loop per transaction.
Use Case 3: Agent-to-Agent Commerce with Micropayments
This one is less obvious but increasingly real. Agents are starting to hire other agents: an orchestrator agent spins up a specialized sub-agent to perform a task and needs to pay it onchain for the result.
The problem is that the orchestrator can't hand the sub-agent a private key (that's the root-access problem again), and you don't want the orchestrator to have unbounded spending authority either.
The pattern that works: the orchestrator holds a session key scoped to a specific payment contract with a per-call spend cap. It can pay the sub-agent for completed work, but it cannot drain the parent account or call arbitrary contracts. The sub-agent receives payment to its own smart account, which can have its own policy constraints for how those funds get used downstream.
This is agent-to-agent commerce with auditable, revocable, bounded access at every layer. It's also where Namera's MCP server integration becomes directly useful: agents can interact with the execution layer through structured tool calls rather than raw RPC, which fits naturally into how most orchestration frameworks operate today.
Use Case 4: AI-Powered Treasury Management
Internal treasury operations are a strong fit for programmable agent wallets, and also the use case where the security requirements are highest.
A treasury management agent might need to: move funds between yield protocols, execute approved vendor payments, or rebalance across chains. Each of these is a distinct permission surface. You don't want the same key that can call deposit() on Aave to also be able to call transfer() to an external EOA.
With composable policies, you can issue separate session keys for each operation class. The yield rebalancing key is scoped to specific protocol contracts. The vendor payment key is rate-limited to a daily cap and scoped to a whitelist of recipient addresses. Neither key can call anything outside its defined envelope.
Namera's multichain routing support matters here too. Treasury operations often covers multiple chains, and a chain-agnostic execution layer means you're not forced into a single-chain architecture just because that's what your wallet SDK supports. Unlike Coinbase's CDP wallets, which are Base-locked, or Polygon's tooling, which is ecosystem-specific, the session key model here works across chains without requiring separate infrastructure per network.
Use Case 5: Onchain Task Automation and Scheduled Workflows
Not everything is finance. Agents are increasingly responsible for onchain governance participation, NFT minting on schedule, data publication to decentralized storage, and protocol maintenance tasks like liquidation monitoring or keeper functions.
These workflows share a requirement: the agent needs to execute specific contract calls on a schedule or in response to events, without human approval per action, but also without unlimited authority.
Timestamp policies handle the scheduling constraint: a session key can be valid only between specific Unix timestamps, so an agent authorized to run a weekly keeper job cannot execute outside that window even if the key is somehow obtained by a third party. Call policies restrict which functions can be invoked. Rate-limit policies prevent runaway execution if the triggering condition misfires.
The local-first CLI in Namera's tooling is particularly useful for this pattern. You can script session key issuance and revocation as part of a deployment pipeline, with no cloud dependency required. The key exists for the duration of the task window and is revoked programmatically when the window closes.
Use Case 6: AI-Powered NFT Trading and Curation
NFT trading agents need to monitor floor prices, place bids, and execute purchases when conditions are met. The risk surface is real: an unconstrained agent could drain a wallet chasing worthless assets or get manipulated into buying wash-traded collections.
Session keys address this by scoping the agent to specific marketplace contracts — fulfillBasicOrder() on Seaport, for example — with a hard spending cap per transaction and a daily aggregate limit. The agent can trade actively within those rails, but it can't transfer assets to arbitrary addresses or touch contracts outside the approved list.
Transaction batching matters here too. An agent placing bids across multiple listings can bundle those calls into a single UserOperation, cutting gas overhead and making execution atomic.
Use Case 7: Autonomous Gaming Agents and NPC Economies
Web3 gaming is where the agent wallet problem gets genuinely interesting — and where failure modes are most visible to end users.
AI agents in onchain games can function as autonomous NPCs with real economic behavior: managing in-game inventory, executing trades in decentralized item marketplaces, optimizing Play-to-Earn yields through automated resource harvesting and crafting cycles. A well-designed gaming agent doesn't just follow a script — it responds to market conditions, adjusts crafting priorities based on material prices, and executes trades when spreads are favorable.
The critical security constraint is asset segregation. A player-delegated bot should be able to spend Gold tokens and Materials NFTs freely within the game economy. It should never be able to transfer Legendary or Rare NFTs to an external wallet. Those are the player's high-value assets, and the agent has no business touching them regardless of what instruction it receives.
With Namera's scoped session keys, you encode this directly into the policy:
import { createAccountClient } from "@namera-ai/sdk/account";
import { createSessionKey } from "@namera-ai/sdk/session-key";
import { createPublicClient, http, parseEther } from "viem";
import { createPaymasterClient } from "viem/account-abstraction";
import { generatePrivateKey, privateKeyToAccount } from "viem/accounts";
import { mainnet } from "viem/chains";
import {
CallPolicyVersion,
toCallPolicy,
toGasPolicy,
toRateLimitPolicy,
toTimestampPolicy,
} from "@/policy";
const publicClient = createPublicClient({
chain: mainnet,
transport: http(),
});
const paymaster = createPaymasterClient({
transport: http("ZERO_DEV_PAYMASTER_URL"),
});
const signer = privateKeyToAccount(generatePrivateKey());
const sessionPrivateKey = generatePrivateKey();
const GOLD_TOKEN_CONTRACT = "0x...";
const MATERIALS_NFT_CONTRACT = "0x...";
const MARKETPLACE_CONTRACT = "0x...";
const sessionKey = await createSessionKey({
accountType: "ecdsa",
clients: [publicClient],
entrypointVersion: "0.7",
kernelVersion: "0.3.2",
policies: [
// Only allow the session key to call the following contracts
toCallPolicy({
permissions: [
{ target: GOLD_TOKEN_CONTRACT },
{ target: MATERIALS_NFT_CONTRACT },
{ target: MARKETPLACE_CONTRACT },
],
policyVersion: CallPolicyVersion.V0_0_5,
}),
toTimestampPolicy({
validUntil: Math.round((Date.now() + 7 * 24 * 60 * 60 * 1000) / 1000), // 7-day session
}),
toRateLimitPolicy({
count: 20,
interval: 60 * 60, // 1 hour
}),
toGasPolicy({
allowed: parseEther("0.05"), // 0.05 ETH allowed
}),
],
sessionPrivateKey,
signer,
type: "ecdsa",
});The agent cannot exfiltrate LegendaryItems because LEGENDARY_NFT_CONTRACT isn't in the allowedContracts list. This isn't application-level logic that can be worked around — it's enforced at the smart account layer. Even if the agent's underlying model is manipulated into attempting a transfer, the transaction reverts onchain.
This architecture also scales to NPC economies. A game studio can deploy hundreds of autonomous NPC agents, each with a session key scoped to its role — a merchant NPC that only interacts with shop contracts, a crafting NPC that only consumes materials, a guild treasury agent that only executes approved disbursements. The permission model maps directly to game logic.
Batching matters here too. An agent running a crafting loop — harvest materials, craft items, list on marketplace — can batch those three calls into a single UserOperation rather than three sequential transactions, cutting both latency and gas cost.
The common thread across all 7
Every use case above has the same underlying structure: an agent needs to execute a specific set of onchain actions, within defined limits, without access to the owner signer. The implementation primitive is a session key with composable onchain policies. The security guarantee is that policy enforcement happens at the contract layer, not in your backend.
EOAs cannot do this. A private key is binary: the holder can sign anything. Smart accounts with scoped delegation are the only model that gives you bounded, auditable, revocable agent access.
If you're building any of these systems, the infrastructure decisions you make now will determine how much of your security posture is real versus assumed. Explore the docs and start building at namera.ai.
FAQs
What is an AI agent wallet? An AI agent wallet is a smart account that an autonomous agent can use to execute onchain transactions within a defined permission boundary. Unlike a standard wallet controlled by a human, an agent wallet issues scoped session keys to the agent so it can sign and submit transactions without access to the owner's private key.
Why can't I just give an AI agent a private key? A private key grants unrestricted signing authority. If the agent is compromised, behaves unexpectedly, or is exploited, there is no onchain mechanism to limit the damage. Session keys with policy enforcement constrain what the agent can do at the contract layer, so the blast radius is bounded regardless of what happens to the agent.
What kinds of policies can you enforce on an agent session key? Common policy types include call policies (which contracts and methods the key can invoke), gas policies (per-transaction spend caps), rate-limit policies (max executions per time window), timestamp policies (valid-from and expiry times), and signature policies. Multiple policies compose together, and all must pass for a transaction to execute.
How does agent-to-agent commerce work with session keys? An orchestrator agent holds a session key scoped to a payment contract with a per-call spend cap. It can pay sub-agents for completed work without having access to the full account. Each layer of the agent hierarchy can have its own session key with its own policy envelope, keeping permissions narrow and auditable throughout.
Is this approach chain-agnostic? Yes. Namera's session key model works across chains through multichain routing support. You're not locked into a single network. A single owner account can issue session keys that operate on different chains without requiring separate infrastructure per network.
How do you revoke a session key if something goes wrong? Session key revocation is owner-controlled and onchain. The owner signer can revoke a specific key without rotating the primary account or affecting other session keys. For multi-tenant systems, this means you can terminate one agent's access without disrupting others.
What's the difference between Namera and a custodial wallet API? Custodial solutions move execution offchain and rely on the provider's backend to enforce rules. Namera enforces policies onchain at the contract layer, which means the rules apply regardless of what happens at the API level. You also retain composability with existing onchain protocols, which custodial abstractions typically break.