Session keys and auto-confirm: what you're really turning on
97% of EIP-7702 delegations pointed to attacker contracts. What session keys and auto-confirm grant, and the limits that bound them.
Session keys and auto-confirm let an app act on your wallet without asking you to sign every time. That's useful for trading and gaming, where a pop-up every few seconds makes an app unusable. It's also a permission that keeps working long after you've forgotten about it. Wintermute found that within four weeks of Ethereum's Pectra upgrade (May 7, 2025), over 97% of on-chain EIP-7702 delegations pointed to copy-pasted sweeper contracts — attacker infrastructure, not real features. This guide covers what these permissions grant, what limits them, and how to set one up so it can't cost you more than you decided to risk.
Last updated: August 2026
What are session keys and auto-confirm?
A session key is a temporary signing permission. It lets an app do a narrow set of actions for you, without your main key signing each one.
Auto-confirm is the consumer version of the same idea: the wallet stops showing a confirmation pop-up for a specific app, for a limited time.
They aren't the same thing. Auto-confirm is a wallet setting that hides prompts for an app you've already connected to. A session key is a real delegated key with rules attached — spend limits, an expiry, a list of contracts it may call. Auto-confirm hides the click. A session key hands over bounded authority.
What they share is that your review step goes away. That's the point of the feature, and also the risk.
| Token approval | Session key | Auto-confirm | |
|---|---|---|---|
| What it grants | Right to spend one token, up to a limit | Bounded signing authority under wallet-enforced rules | Suppression of confirmation prompts for one app |
| Scope | Per token, per contract | Per app, per rule set | Per app, per session |
| Expires on its own? | No — lives until revoked | Yes, if an expiry was set | Yes, in wallets that time-limit it |
| Where it's enforced | The token contract | The smart account | The wallet |
If token approvals are new to you, our guide to dApp permissions and token approvals covers the layer this builds on.
How delegated signing works
Session keys need a smart account — a wallet that can run rules — not a plain key pair. That's what account abstraction provides. Under ERC-4337, your account is a contract that can check custom permission logic before a transaction runs, and ERC-7715 defines how an app requests a scoped permission from it. Our explainer on account abstraction and ERC-4337 goes deeper on that layer.
The flow is: you approve a permission request once, the app gets a key that can only do what the rules allow, and your main key stays out of it. A properly built session key never gives the app your private key.
EIP-7702 is a different mechanism, and the difference matters. It lets a normal wallet address temporarily act like a smart contract by pointing at an implementation. Used well, that's what makes batching and sponsored gas work on an ordinary address. Used against you, it's the most dangerous signature in this article. More on that below.
One trap to name early: sponsored gas. When an app pays the network fee, the transaction costs you nothing and feels like it barely happened. It's still a real wallet action moving real funds.
The three limits that make a session key safe
A session key is only as safe as the limits on it. Three do most of the work:
Spending limit. The most value or tokens the session can move. Without one, you've signed a blank check.
Time limit. An expiry — a timestamp or block window — after which the permission is dead whether you remember it or not. Some wallets enforce this for you. Phantom's auto-confirm expires after two hours and switches back off until you re-enable it. It's also opt-in per account and per domain, limited to six allow-listed apps, and active only in the tab where you turned it on.
Action limit. Which contracts and which functions the key may call. People skip this one, and it's what separates "can place trades on this exchange" from "can do anything, anywhere."
MetaMask's July 2026 guidance on agentic wallets adds two more: a rolling 24-hour cap on total outflow, on top of the per-transaction cap, and allow-lists for recipients, tokens, and networks. Its core advice fits any delegated permission — treat whatever is signing as "an unfamiliar transaction proposer rather than a trusted signer."
Red flags at the approval screen, from Crypto Adventure's session-key research: no expiry shown, unlimited spending, a vague description of what the permission does, contracts you can't identify, and no clear way to revoke.
Where this goes wrong
Four failure modes, roughly in order of what they cost people.
Malicious EIP-7702 delegations. This is the severe one. A fake mint or giveaway site gets you to sign what looks like a routine authorization, and the signature points your address at an attacker's implementation. Relay's security guidance describes the result: the attacker can auto-drain tokens "in the same block your funds arrive," with no further signature from you. Deposit into that wallet six months later and the funds leave immediately. Most wallets can't revoke a delegation from their own interface, and account-level delegations are invisible to approval scanners, which only look at token allowances.
The app itself gets compromised. A session key is only as trustworthy as the app's front end and keys. If the app is breached, your permission becomes the attacker's permission — up to the limits you set. This is exactly why the limits exist.
Prompt injection, if you use an AI agent. MetaMask treats this as a first-class risk. Hidden instructions planted in content the agent reads — a token description, a web page, an API response — can steer it into signing something you never asked for. The wallet has to enforce policy, outside the model, because a system prompt is not a security control.
Key exposure in automated setups. If whatever automates your transactions can read your private key, any compromise of it compromises everything. MetaMask cites the Gitcoin Owockibot incident of February 8, 2026, where an agent exposed hot-wallet keys despite instructions not to. Losses were about $2,100, but the mechanism scales.
For scale on the first one: Three Sigma records a single victim losing $1.54 million to a 7702 batch-transaction phishing attack by late August 2025, and around $146,000 lost to an Inferno Drainer variant riding on a legitimate delegator address.
In Coin98 Super Wallet, the Cypheus AI assistant runs transaction agents for transfers, swaps, and staking — the same kind of automation these controls are written for. The question isn't whether to use delegation, but how tightly to bound it.
How to turn it on without regretting it
If the convenience is worth it to you, this sequence keeps the downside bounded.
- Use a separate wallet. Fund a dedicated wallet with the amount you're willing to risk in that app, and grant the session from there. Nothing else in your portfolio is reachable.
- Set a spend cap you'd shrug at. Pick a number where losing all of it would annoy you, not hurt.
- Set the shortest expiry the app accepts. A session for one trading afternoon shouldn't outlive the afternoon.
- Check the contract list. If the permission screen won't tell you which contracts the key can call, decline.
- Grant it per session, not permanently. Re-granting takes seconds. A forgotten permission runs for months.
- Keep threat scanning on. Hiding the confirmation pop-up isn't the same as turning off the wallet's checks — Phantom keeps scanning transactions even with auto-confirm active. If a wallet offers to disable both together, don't.
Cleaning up: how to revoke what's still live
Review delegated permissions on a schedule, not from memory. Three things to check:
- Connected apps. Remove anything you're not actively using — Coin98 documents the steps for managing wallet connections.
- Token allowances. Session keys don't replace approvals, and old allowances outlive the sessions that created them. Wallet Approval lists what's outstanding, and our guide on revoking wallet permissions covers the monthly routine. A Wallet Health scan surfaces risky ones you'd otherwise miss.
- Account-level delegations. Check these separately, because approval tools don't show them.
If you find a delegation you don't recognise, treat it as a compromise, not a cleanup task. Relay's guidance is blunt: an unknown delegation usually means your keys are already compromised, and the answer is moving assets to a fresh wallet rather than trying to revoke. Coin98's docs cover what to do when a wallet is compromised, including when starting over is safer.
Frequently asked questions
Does auto-confirm give an app my private key? No. A properly built session key or auto-confirm setting delegates bounded authority; your private key stays in the wallet. The risk isn't key theft. It's that the authority may be broader than you realised, or last longer than you intended.
How is a session key different from a token approval? A token approval lets a contract spend a specific token up to a limit, and the token contract enforces it. A session key delegates signing authority under rules your smart account enforces, which can cover several actions and usually carries an expiry. Approvals last until revoked; well-configured session keys expire on their own.
Will a hardware wallet protect me if auto-confirm is on? Only partly. A hardware wallet stops your private key from being extracted, but the point of auto-confirm is that you're no longer reviewing each action. If you signed a permission that turned out to be malicious, the hardware wallet signed it too.
Why can't revoke tools see an EIP-7702 delegation? A delegation works at the account level, not the token level. Tools built to scan token allowances are looking in the wrong place. Checking for delegations is a separate step.
Is sponsored gas a red flag? Not by itself — it's a legitimate feature that removes real friction. But it also removes a useful signal. When a transaction costs nothing to submit, there's no fee prompt to make you pause, so give it the same scrutiny you'd give a transaction you were paying for.
Should I use this at all? For frequent activity in an app you already trust, with a capped separate wallet and a short expiry, it's a reasonable trade. For occasional transactions, the convenience is small and a standing permission isn't worth it.
Bottom line
Session keys and auto-confirm aren't dangerous because they're delegated. They're dangerous when they're unbounded. A spend cap, a short expiry, and a contract allowlist turn an open-ended permission into a defined, survivable risk. Reviewing what's still live is the other half: Wallet Approval and Wallet Health in Coin98 Super Wallet make that a monthly check instead of something you discover after the fact.
