admin
An AI agent that can sign on behalf of a person does not need unlimited wallet authority. Session keys can reduce repeated approvals, but a careless permission envelope converts temporary convenience into durable financial exposure. This engineering guide separates what a session key can do from what the user intended it to accomplish.
Write the permission envelope before creating a key
A session key should have a clear statement of the allowed target contract, function selectors, spending amount, token types, chain ID, expiration and permitted frequency. A rule that says ‘may interact with marketplace’ is too broad if the marketplace later gains administrative endpoints. Specify operations in terms of actual contract calls, not natural-language intent alone. Set a maximum aggregate budget for the whole session as well as a per-transaction cap, because an agent can otherwise repeat a small authorized action indefinitely. A user interface should render this scope as plain language with a separate technical summary that power users can inspect. Avoid promising that a session key is noncustodial or safe unless the underlying wallet and contract architecture substantiate those claims.
Sign the right domain and bind the right chain
An agent may operate across testnets, multiple chains and several wallet interfaces. Typed signatures should commit to a clear domain so a message signed for one context cannot be casually replayed in another. EIP-712 standardizes typed structured-data hashing and signing, but it does not automatically solve replay resistance or define the business semantics of every signature. Include a nonce or use-specific replay protection, explicit contract identity and chain scope in the authorization logic. Validate signatures on the intended chain and in the intended contract account context. When simulating an authorization request, show that changing one destination or spending limit invalidates it. Tests should cover same nonce, expired nonce, mismatched chain and unauthorized function calls rather than checking only a happy-path signature.
Separate wallet authorization from AI planning
A model can propose an operation, but the session policy must be evaluated by deterministic code independent of the model’s narrative. A tool result, retrieved website or message from another user must not be able to widen permission by saying the account owner approved it. Represent each proposed transaction as structured parameters, then enforce limits before submitting it for simulation or signing. For a recurring agent that pays for small services, require price ceilings and approved merchants rather than merely trusting the domain that appeared in the prompt. The most effective defense is for forbidden operations to be structurally impossible: a spending limit enforced in the wallet or smart account is stronger than a warning inserted into a system prompt.
Make expiry and emergency stop observable
An expiry timestamp should be meaningful to the user and enforced by the validator, not simply displayed in the application. Some implementations allow revocation on-chain; others use off-chain registries or smart-account policies, each with different availability and trust assumptions. A user should be able to see every active session and disable a compromised key without needing to recover the AI agent’s own device. Test revocation during a network partition, immediately before an order is submitted, and after a transaction is signed but before it is included. Understand the limits of reversal: revoking future authority may not undo a valid transaction that already settled. Separate transaction cancellation, authorization revocation and asset recovery rather than describing all three as ‘undo’.
Treat delegated code and wallet upgrades as risks
Account delegation mechanisms such as EIP-7702 change how externally owned accounts may use code under specified rules, but an EIP alone is not a guarantee that every wallet or network implements session permissions identically. Examine which contract actually checks the policy, who can upgrade that contract and whether a privileged administrator can bypass limits. A vendor demo that restricts one function cannot prove that approvals, fallback methods and multicall paths are also restricted. Test alternate call paths, proxy upgrades, delegatecall behavior and malicious token callbacks against the same session scope. Document the assumed threat model: compromised agent runtime, stolen session key, malicious application, faulty contract and a user who needs to exit.
Measure containment instead of counting approvals saved
Convenience matters, but the success metric should include the maximum loss achievable under one compromised session. Run adversarial tests that attempt many small payments, repeated gas-sponsored requests, unauthorized approval changes and cross-chain replay. Track how long revocation propagates, whether alerts reach users, and whether transactions rejected by policy remain rejected after a wallet upgrade. Count false denials separately so good user operations are not silently blocked. A useful session key creates a short, comprehensible area of delegated authority with observable limits. If the scope cannot be explained in one screen, reconsider whether the agent needs that authority at all.
