Should AI agents get expiring wallet permissions instead of private keys?

I’m experimenting with AI agents that can take small, bounded actions, and I’m increasingly uncomfortable with the usual shortcut: hand the agent a wallet’s full private key. For an externally owned account, possession of that key effectively grants control, so a bug or prompt-injection failure can become an irreversible ownership problem.

My preference is a smart-account model with least-privilege permissions: a spending cap, approved contracts and function calls, a short expiration, perhaps a single-purpose token or account, and automatic revocation. That should reduce the blast radius, but it also makes the wallet permission layer a critical piece of software. Limits need to be enforced on-chain, not merely promised by the agent.

The practical test is usability. Can a normal user understand exactly what was authorized, and can they revoke it quickly when the agent behaves strangely? I’m interested in implementations, counterarguments, or the permission model you would actually trust.

The missing piece for me is incident response. Revocation only helps if the user can find the control, pay for the transaction, and know it covers pending work and any sub-delegations. I’d want simulation before execution and a separately protected emergency path, not just an expiration timestamp.

Most users won’t reason about selectors or cumulative limits. The wallet needs to show a plain-language capability receipt: which asset, which destination, what maximum, until when, and what the agent cannot do. Anything else is technically scoped but socially opaque.

I’m not convinced narrower always means safer. An approved contract can still have surprising semantics, and a carefully constrained call may authorize more than the user thinks. A tiny, isolated wallet with a full key might be easier to explain and replace than a complicated delegation graph.

I’d separate the design from the standards. ERC-7710 and ERC-7715 are drafts, and concrete frameworks differ in revocation and recovery behavior. Before trusting one, I’d test the emergency procedure repeatedly: revoke, rotate, recover, and verify what already-submitted operations can still execute.