How an Agent Gets Permission to Spend: Smart Account, Permission, Session Key, Execute, Revoke

An agent with a raw private key has the owner's full authority forever, and every prompt injection, bug or model error is a potential total loss. A scoped permission turns that into a bounded loss: this token, this much, this venue, until this date. The difference is not a feature; it is the line between a demo and something you would run with real funds. It is also what auditors, counterparties and the agent's own operator can inspect on-chain.

• ▸1. Smart account. The owner's funds sit in a smart account, not an EOA. ERC-4337 accounts (ZeroDev Kernel, Safe, Coinbase Smart Wallet) can run arbitrary validation logic; ERC-7702 lets an existing EOA delegate to account code. Either way the account, not a human, will check the agent's signatures.
• ▸2. Permission. The agent (or its app) requests a permission from the owner's wallet: which token, a spend cap, an allowed target or method set, an expiry. ERC-7715 defines the request (`wallet_grantPermissions`); the owner approves it once in their wallet UI. The permission is data the account can verify, not a promise.
• ▸3. Session key. The permission is bound to a key the agent controls — a fresh keypair generated for this job, held by the agent's runtime or a key-management service (Turnkey, Privy, Coinbase Agentic Wallets). The owner's key never leaves the owner.
• ▸4. Execute. The agent signs a user operation with the session key. The account's validator checks the signature against the permission: right key, right target, under the cap, before expiry. Anything outside the scope reverts on-chain, whatever the agent intended. ERC-7710 is the delegation framework several accounts use to express and enforce this.
• ▸5. Revoke. The owner revokes the permission (or lets it expire). From that block the session key signs nothing that executes. Rotate the session key on a schedule regardless, because a key that exists can leak.

• •A smart account with a pluggable validator (ERC-4337) or a delegated EOA (ERC-7702)
• •A permission request and grant (ERC-7715) the owner approves once
• •A delegation the account can enforce (ERC-7710 or the account's own module system)
• •A session key the agent holds, ideally generated and stored by a key-management service
• •A bundler and paymaster so the agent's user operations get included and, optionally, gas-sponsored
• •A revocation path the owner can trigger without the agent's cooperation

• ▸A rebalancing agent granted USDC-only, 500 per day, to one DEX router, expiring in 30 days, signing with a Turnkey-held session key from a ZeroDev Kernel account.
• ▸A payments agent with a permission that allows transfers only to a list of vendor addresses, revoked by the owner when the vendor contract changes.
• ▸A research agent with a zero-spend permission (read-only calls) so it can query contracts but never move funds.
• ▸A trading agent whose session key is rotated weekly by the operator's runtime, with the previous key's permission revoked in the same transaction.

• ⚠A permission without a target restriction still lets a compromised agent send funds to any address under the cap.
• ⚠Session keys stored in the agent's process memory or environment are as exposed as the process; a key-management service moves the key out of the blast radius but adds a dependency.
• ⚠Bundler or paymaster outages can strand an agent mid-task; the agent needs a plan for a user operation that never lands.
• ⚠Not every wallet implements ERC-7715 yet; the request may fall back to a full-approval prompt, which is the thing this flow exists to avoid.

Can I do this with a normal EOA wallet?

Not with an EOA alone: an EOA has one key and no logic to check a permission. Either move funds to a smart account or use ERC-7702 to delegate the EOA to account code, after which the rest of the flow applies.

Is a session key the same as an API key?

No. An API key authorises calls to a service; a session key signs on-chain operations that the account then checks against a permission. If the service is compromised, an API key is the whole story; a session key is still bounded by the on-chain scope.

Who pays gas for the agent's operations?

Either the account (from its own balance) or a paymaster that sponsors the user operation. Sponsorship is a product choice; the permission scope should cover it either way so a sponsor cannot widen what the agent can do.

How do I know the tools listed here actually work?

Each linked listing shows its Sato Score, the share of our daily checks it answered, and whether we reproduced its documented install in a container. That is evidence the tool is maintained and installable; it says nothing about whether your permission scope is right.

What happens to in-flight operations when I revoke?

A user operation signed before revocation but included after it will fail validation at inclusion time, because the account checks the permission when it executes, not when the agent signed.

• 1.ERC-4337: Account Abstraction Using Alt Mempool ↗
• 2.ERC-7715: Grant Permissions from Wallets ↗
• 3.ERC-7710: Smart Contract Delegation ↗
• 4.EIP-7702: Set EOA account code ↗
• 5.MetaMask Delegation Framework (source) ↗

• How Agents Use Wallets
• Onchain Agent Security: The Threat Model
• How Do AI Agents Pay?