Session keys and agent permissions explained: contract-enforced delegation for onchain agents

Session keys and agent permissions are a way for a smart account to delegate a tightly scoped mandate to an app or AI agent, enforced on-chain by the wallet’s validation logic. The point is autonomous onchain execution without turning an agent into a full-power signer, using limits like time windows, allowlists, and a spend cap that the contract can refuse to exceed.

Key Takeaways

• A session key is a temporary signing credential with limited authority, designed so one approval can cover a bounded set of actions inside a defined scope.
• The safety upgrade comes from smart accounts enforcing policy on-chain, not from the key being “temporary.”
• ERC-4337 makes delegated execution operational through UserOperations, bundlers, and a canonical EntryPoint contract, with optional paymasters that can sponsor gas.
• ERC-8196 proposes the next step for agent wallet design: cryptographic proof of policy compliance plus a hash-chained audit trail for session activity.

Session keys and agent permissions basics

Delegation starts with a simple split: one credential keeps full control, another credential gets a narrow job. In a smart account setup, the owner’s master key stays “root,” while a session key is minted or authorized for a specific window and scope. That scope is what people mean by agent permissions or scoped agent access. The app or agent can sign, but only inside the box the wallet contract recognizes.

This framing matters for autonomous onchain execution because agents already know how to sign transactions. The failure mode is giving them an all-access key and hoping the host, the prompt, the dependency tree, and the UI never betray you. Session keys are the opposite posture. They are a risk budget you can price: time + targets + value limits, with the wallet contract acting as the bouncer.

A useful mental model is “badge, not master key.” The badge can open a few doors, during a few hours, for a specific task. If the badge leaks, the blast radius is supposed to be bounded by design. That is why the phrase session keys crypto often shows up alongside smart accounts and embedded wallets. The whole point is fewer repeated approvals without handing permanent, unlimited control to an app.

Two details are easy to miss. First, “temporary” is not the security property. Scope is. Second, session keys are not standardized everywhere today. Implementations are still wallet-by-wallet, which means the exact semantics of revocation, allowlists, and edge cases vary across providers.

How smart accounts enforce permissions

ERC-4337 changes where authorization happens. Instead of an EOA broadcasting a normal transaction to the public mempool, a smart account expects a UserOperation that it can validate against its own rules before anything executes. The agent signs the UserOperation with an authorized key, a bundler aggregates UserOperations, and the bundler calls a canonical EntryPoint contract that processes them. The permission system lives at the smart account validation layer, not in the UI.

That architecture is why “trust the app” can be replaced with “the contract refuses.” RebelFi captures the shift with two lines that are worth keeping verbatim: “trust the agent application code to not overspend” versus “the contract enforces the spending policy regardless of what the application does.” The second sentence is the actual mechanism. If the policy says no, the operation does not validate, and EntryPoint does not execute it.

Paymasters are the other piece that makes agents feel always-on. In ERC-4337, a paymaster can sponsor gas, which means an agent holding USDC and no ETH can still transact if a paymaster is configured to accept USDC in exchange for covering ETH gas costs. That is not a cosmetic UX trick. It removes the operational requirement to keep a separate ETH balance topped up just so the agent can keep working.

This is also where eip 7702 enters the conversation. ZeroDev positions its stack as supporting both ERC-4337 and eip 7702, with session keys as a first-class UX primitive for automation. The common thread is the same: move delegation into a wallet that can enforce policy, rather than leaving it as an off-chain promise.

Common permission scopes and limits

A session policy is only as good as the knobs it exposes and enforces. RebelFi’s concrete example is a clean template for how agent permissions should look when someone actually has capital at stake: a per-transaction maximum spend (example: $50), an approved recipient list, an expiration window (example: 24 hours), and a total session budget (example: $500) before re-authorization. That last one matters because “many small hits” can add up even when each individual transfer is capped.

Those knobs map to how smart accounts validate intent:

1. Time bounds. A validAfter and validUntil window makes the key useless outside the session, which reduces the value of stealing it. 2. Target constraints. Allowlists of recipients or allowed contracts stop the key from being repurposed for arbitrary transfers. 3. Value constraints. A spend cap per transaction limits single-shot damage, while a total budget limits drip damage.

Revocation is the operational backstop. In the RebelFi architecture, the root signing key retains full account control and can revoke session keys at any time. That is the difference between delegation and surrender. The owner key is not “sharing identity.” It is issuing a mandate that can be killed.

One more nuance: session keys are often described as “temporary private keys,” but that description is incomplete. The key is just a signer. The safety comes from the smart account refusing to validate operations that violate policy. Without that on-chain enforcement, “temporary” can still be catastrophic inside the window.

Agent workflows enabled by delegation

Delegation is not only about convenience. It changes what workflows are feasible without turning every step into a new signature ceremony. The obvious use case is agent payments. An agent wallet can be allowed to pay a set of pre-vetted service providers while being blocked from transferring funds to arbitrary addresses.

Atomic batching is the second-order unlock. ERC-4337 smart accounts can execute atomic batch transactions, so sequences like withdraw-from-yield + pay-for-service succeed or fail together. That matters because it prevents half-completed state. If the payment leg fails, the withdrawal leg reverts, and funds do not end up stranded in an unintended intermediate state.

Batching also shows up as a measurable cost lever. RebelFi estimates two ERC-20 transfers separately at roughly 2 × 65,000 gas versus about 1 × 110,000 gas batched, which is around a 15% savings. On a screen, that is the difference between an agent workflow that is economically viable at scale and one that bleeds fees.

Gas sponsorship ties the loop together for “no-ETH” agents. With a paymaster, the agent can operate while holding only USDC, assuming the paymaster accepts USDC for gas. That is the practical answer to the misconception that agents must hold ETH to function.

ZeroDev’s positioning is consistent with this workflow view. Its documentation frames session keys as part of a broader smart account UX toolkit that includes batching and gas abstraction, and it claims to power more than 6 million smart accounts across 50+ networks for 200+ teams. That scale claim is not a security guarantee, but it is a signal that these patterns are already being used in production stacks.

Policy-bound execution and audit trails

ERC-8196 is the clearest statement of where agent permissions are heading: wallets that execute actions only when accompanied by cryptographic proof that the action complies with an owner-defined policy. This is not just “set limits in a UI.” It is “prove compliance at execution time,” with the wallet acting as the enforcement point.

The proposal specifies required policy fields that look like a formalized version of today’s session policies: allowed actions, allowed and blocked contracts, max value per transaction, a validity window, and a minimum verification score gate. It also introduces an immutable, hash-chained audit trail concept for session activity, where each audit entry includes a previous hash for integrity. ERC-8196 allows implementations to store entries off-chain and periodically post roots on-chain, which is a pragmatic trade between cost and verifiability.

This is the endgame implied by the thesis: session keys only become meaningfully safe when the wallet can enforce policy on-chain, and the next moat is verifiable compliance plus auditability. If an agent host is compromised, “the logs say it behaved” is not good enough. A tamper-evident trail plus policy-bound execution is closer to the posture regulated platforms and serious operators want.

Two caveats belong in the same breath. ERC-8196 is explicitly in peer review, so the interface and requirements can change. Separately, even a perfect standard does not remove implementation risk. The wallet’s validation logic, verification checks, and audit plumbing still have to be built correctly.

Risks, caveats, and best practices

The expensive misconception is thinking a session key is safe because it is temporary. Time limits help, but a wide-open scope inside the window is still a wide-open scope. A 24-hour key that can transfer to any address is a 24-hour drain button.

The second misconception is portability. Session keys are not standardized everywhere today, and implementations vary wallet-by-wallet. That means “agent permissions” can look similar across products while behaving differently at the edges, including revocation behavior and how strictly allowlists are enforced.

The third misconception is operational: agents need ETH to operate. ERC-4337 paymasters can sponsor gas, enabling an agent holding USDC and no ETH to transact if the paymaster is configured to accept USDC.

Best practice is to write policies like risk limits, not like feature toggles:

1. Start with a tiny per-transaction spend cap. This is the fastest way to bound single-shot damage. 2. Use a hard allowlist of recipients or contracts. If the agent cannot name the target in policy, it should not be able to touch it. 3. Keep the validity window short. Expiry reduces the value of a leaked key. 4. Add a total session budget. This stops “many small hits” from bleeding the account.

Batching is also a safety tool, not just a gas trick. Atomic batches reduce the chance of ending up with half-completed state when an agent workflow spans multiple steps.

Revocation needs to be treated as a first-class control. The sources are explicit that the owner’s root key can revoke session keys. Operationally, that implies designing for fast kill switches and treating nonces and expiry as core controls to reduce replay and timing issues.

This is where the broader autonomous execution story lands: the winning designs move delegation out of app promises and into contract-enforced limits, then add verifiable compliance and an audit trail on top.

The Take

I’ve watched teams treat “temporary key” as a security argument and then quietly ship a session that was wide open on targets or budget. The key expired, sure. The funds were still gone inside the window. The only version of this that holds up is when the smart account validation layer is the one saying no, not an agent host or a UI checkbox.

The clean posture is to think of a session key as a priced mandate: short clock, tight allowlist, small per-tx spend cap, and a hard total budget. If the system also supports atomic batching and paymasters, the agent can feel always-on without being always-dangerous. That is the direction autonomous onchain execution is converging on, and ERC-8196 is the first serious attempt to make compliance and auditability part of the wallet’s job, not an afterthought.

Sources

• RebelFi
• Ethereum Improvement Proposals
• CryptoAdventure
• ZeroDev Docs