How EIP-7702 Session Keys Let AI Agents Run Crypto Wallets Without Your Private Key

AI agents can already trade, pay for services and move money on-chain, and the hard part is no longer making them smart enough. It is deciding how much power to hand them. The answer taking shape on Ethereum is EIP-7702, a change from the 2025 Pectra upgrade (often searched for as “ERC-7702”) that lets an ordinary wallet run smart-contract rules. Combined with session keys, it lets an agent act on your wallet within strict limits, without ever holding your master private key.

This guide explains how that works, how agents use it to pay each other, and where it has already gone badly wrong, including the October 2026 Binance theft.

The short answer

• An AI agent should not hold your private key, because a single leaked or manipulated key means total loss.
• EIP-7702 lets your existing Ethereum address delegate its behavior to a smart contract, which can enforce rules such as spending caps and expiry times.
• A session key is a separate, limited key the agent uses. You approve its permissions once, and the contract checks every action against them.
• The agent is autonomous only inside the box you drew. You still sign the first approval, and you can revoke it.
• The same mechanism is dangerous when you delegate to the wrong contract. A malicious delegation was how attackers drained Binance hot wallets.

Why an AI agent should not hold your private key

A standard Ethereum account, called an externally owned account or EOA, is controlled by one private key. Whoever holds that key can do anything the account can do: send every token, approve any contract, sign anything. There is no way to say “you can spend $50 but not $5,000.”

That is a bad fit for software that reads untrusted text for a living. An agent can misunderstand an instruction, pick the wrong service or follow a malicious prompt even when the payment itself works as designed, as CoinDesk noted in its report on agents paying with stablecoins. Giving such a program a master key puts the whole balance one mistake away from disappearing.

Until recently, the safer options all had a cost. You could use a custodian, which means trusting a company. You could move funds to a new smart-contract wallet with a different address. Or you could keep the agent on a tiny balance and accept that it can do very little. EIP-7702 adds a fourth route that keeps your address and adds rules on top of it.

What EIP-7702 actually changes

EIP-7702 went live on Ethereum mainnet with the Pectra upgrade on May 7, 2025. It adds a new transaction type, 0x04, that carries a list of authorizations. Each authorization is a signed tuple containing a chain ID, the address of a smart contract, a nonce and a signature, as set out in the EIP itself.

When the network processes a valid authorization, it writes a short marker into the account’s code field: the bytes 0xef0100 followed by the contract’s address. From then on, calls to your address run that contract’s logic in the context of your account. Your address, balance and history stay the same.

Three details are often misreported:

• It is an EIP, not an ERC. It changes the protocol itself. ERCs, such as the permission standards below, are application-level conventions.
• It is not temporary. Some explainers describe the delegation as lasting one transaction. The delegation stays in place until the owner signs a new one, and pointing it at the zero address clears it.
• It does not create session keys by itself. The delegated contract defines the permission rules. EIP-7702 only makes it possible for an ordinary account to run that contract.

A sponsor can also submit the transaction and pay the gas, so an account does not need ETH of its own to set up a delegation. That helps agents, which should not need to hold gas tokens in every wallet they control.

Session keys: how the agent gets power without your key

A session key is a second key, generated for the agent, that can sign only within limits the account’s contract enforces. The master key never leaves the owner. If the session key leaks, the damage is capped by whatever the contract allows.

Several standards describe how this works. ERC-7715 defines how an app asks a wallet to grant permissions, through a call named wallet_grantPermissions. ERC-7710 describes delegations that can be passed along to others. Smart accounts built on ERC-4337 reach the same result through validator modules. In practice, a flow looks like this, following the pattern described in Alchemy’s guide to agent wallets:

1. The owner’s account delegates to a smart-contract implementation under EIP-7702.
2. The app or agent framework requests a set of permissions: which tokens, how much, which contracts, which functions and for how long.
3. The wallet shows the request in plain language, and the owner signs one authorization.
4. The agent signs each later action with its session key. The contract verifies the signature and checks the action against the permissions before executing.
5. The owner can revoke the grant at any time, and it also lapses when it expires.

The claim that agents can act “without human private-key approvals” is therefore accurate in a narrow sense. A person does not approve each transaction. But a person did sign the first approval, and the rules that bind the agent live on-chain rather than in the agent’s prompt.

A worked example

Take a hypothetical trading agent. You want it to rebalance a stablecoin position on one decentralized exchange, and nothing else. You would grant a session key that can spend up to 50 USDC per day, call only that exchange’s swap function, and expire after seven days.

If a hidden instruction on a web page tells the agent to send everything to an unknown address, the contract rejects the transfer, because that address and that function are not on the list. The agent may be fooled. The wallet is not. That is the main appeal of moving guardrails out of the prompt and into the account.

When machines pay machines

The more interesting use is agent-to-agent commerce, where no human is present at any step. Three pieces are emerging.

Payments. The x402 protocol revives the old HTTP 402 “Payment Required” status code. An agent requests a paid resource, the server replies with a price, and the agent’s wallet pays in stablecoins and retries. Coinbase launched Agentic Wallets in February 2026, with keys held inside its secure infrastructure and spending controls set by the user.

Identity. ERC-8004 defines on-chain registries for agent identity, validation and reputation. It reached Ethereum mainnet in late January 2026 but remains a draft in practice, according to a Coincub analysis, with adoption depending on wallet and framework support.

Delegation chains. One hackathon prototype built with MetaMask’s tools shows where this could go. A user signs a single delegation, for example $1,000 a day for 30 days, to an orchestrator agent. The orchestrator then hands narrower slices, say $300 a day on one exchange, to sub-agents that buy services over x402. The whole chain is verifiable on-chain, and revoking the root delegation shuts it all down. It is a demo, not a production system, but it shows why standardized, narrowing delegations matter.

Real-world volume is still small and partly artificial. Coinbase has said x402 processed more than 165 million payments worth about $50 million by April 2026. CoinDesk, citing Artemis data, reported in March that daily volume was only about $28,000, with roughly half classed as self-dealing between wallets funded by the same operator. A Coinbase product executive described the market as being in its “Napster” era. Treat adoption claims with care.

Where it goes wrong

Delegation is powerful because one signature can hand control to code. That is also the weakness.

Malicious delegations

Within weeks of Pectra, trading firm Wintermute found that more than 80% of delegations pointed to copies of the same “sweeper” contract, which automatically drains wallets, Decrypt reported. A study presented at USENIX Security linked 63% of the authorization transactions it analyzed to attacker-controlled contracts and counted more than $2.3 million in confirmed thefts. Researchers stress that this is not a protocol bug. Users are tricked into signing authorizations they do not understand. The underlying paper is public.

The Binance theft

The largest example came on October 29, 2026. TRM Labs said the attacker used an EIP-7702 delegation to turn a Binance hot wallet into a sweeper it controlled, with 50 authorizations signed in advance. Fireblocks noted that a wallet delegated to a malicious contract can be drained without any further signature, which is why controls need to sit on the authorization itself.

It is fair to say EIP-7702 was the mechanism, not the root cause. The attacker still needed valid signatures, which Binance says came from a long campaign that began with fake job interviews. We cover that in our report on whether EIP-7702 caused the hack and in the FBI’s attribution to North Korea. The lesson for agents is the same: a scoped delegation is safe only if the contract it points to is trustworthy.

Prompt injection

Session keys limit what an agent can do, but they do not make it wise. In May 2026, an attacker drained a wallet linked to an AI agent without stealing a key, according to a summary of MetaMask’s May security report. It put the loss at about $204,000 and described it as the first documented prompt-injection attack on an agent with real financial powers. The agent was talked into sending the money. Limits that cap the damage matter more than any promise that the model will behave.

Contract bugs and replay

A delegate contract is code that controls real funds. A bug in it can put an account at risk, and few such contracts have been audited. An authorization signed with a chain ID of 0 is valid on every chain that supports EIP-7702, so a signature seen on one network can be replayed on another. Wallets and developers are advised to bind authorizations to a single chain.

A checklist for safer agent wallets

• Use a dedicated wallet. Never delegate your main account to an experimental agent. Fund a separate address with only what the agent needs.
• Delegate only to audited, widely used contracts. Check the address against the wallet vendor’s documentation before you sign.
• Set hard limits. Cap spending per token, allow specific contracts and functions only, and set a short expiry.
• Keep the master key away from the agent and from its host. If a server runs the agent, assume the server can be breached.
• Bind authorizations to one chain. Avoid chain ID 0 unless you understand the replay risk.
• Know how to revoke. Practice removing the delegation or session key before you need to do it in a hurry.
• Monitor activity. Alerts on unusual transfers help catch a manipulated agent early.

EIP-7702 vs ERC-4337 vs MPC wallets

These are not rivals so much as layers. Coinbase’s approach keeps keys inside its infrastructure, while many open-source agent kits combine EIP-7702 with ERC-4337 tooling. The right choice depends on how much you want to trust a provider and how much complexity you can manage yourself.

What to watch next

Three things will decide how fast autonomous wallets spread. First, wallets are adding screening that warns or blocks delegations to known sweeper contracts, and security firms say this control could have stopped the Binance sweep. Second, standards for agent identity and permissions, such as ERC-8004 and ERC-7715, still need broad wallet support. Third, regulators and insurers will ask who is responsible when an agent loses money inside permissions its owner granted. Binance founder Changpeng Zhao has argued that security gaps are a wider financial problem, and agent wallets will test that claim.

FAQ

How can an AI agent make on-chain transactions without my private key?

You delegate your account to a smart contract under EIP-7702, then approve a session key with limited permissions. The agent signs with that session key, and the contract checks each action against your limits.

Is it EIP-7702 or ERC-7702?

It is EIP-7702. It is a protocol-level change to Ethereum, so it is an EIP. Many people search for “ERC-7702,” but the proposal is formally an EIP.

Does EIP-7702 include session keys?

No. It lets an account run smart-contract code. Session keys come from the contract the account delegates to, usually following standards such as ERC-7715.

Can I revoke an agent’s access?

Yes. You can revoke a session key through the wallet, and you can remove the delegation itself by signing a new authorization that points to the zero address.

Is it safe to let an AI agent trade for me?

It can be made safer with strict limits and a dedicated wallet, but it is not risk-free. Agents can be manipulated through prompt injection, and delegating to a malicious or buggy contract can lose funds. Only commit money you can afford to lose.

This article is for information only and is not financial or security advice. The technology is new, standards are still changing, and figures cited come from the sources named.