Approving every action in a decentralized application is tedious, and approving them blindly is dangerous. Session keys address both by granting narrow authority for a limited period.
The problem with a single all-powerful key
A conventional wallet has one key that can authorize anything the account can do, so every interaction requires an explicit approval.
Applications requiring frequent actions, such as games or trading interfaces, generate constant prompts, and users begin approving without reading.
The alternative of granting broad standing permission removes the prompts by removing the protection, which is worse rather than better.
Smart accounts allow rules
A smart contract account can define its own validation logic instead of accepting only one signature, which is what makes granular permission possible.
The account can register an additional key and record constraints on what that key may authorize.
Those constraints are enforced by the account contract itself, so an application cannot exceed them regardless of what it attempts to submit.
Constraints are the substance of the grant
Typical limits include an expiry time, a list of contracts the key may call, specific functions within those contracts and a cap on value transferred.
A gaming session key might be permitted to call only the game contract, only certain functions, only for a few hours and with no ability to move tokens.
Expiry matters most, because a key that stops working automatically limits the damage from a compromise the user never notices.
The key can live where it is used
Because authority is narrow, the session key can be stored in browser memory or in the application itself without the exposure that would imply for a full account key.
Losing it costs whatever the constraints allowed, and the account key remains untouched, so recovery means issuing a new session rather than migrating funds.
Revocation is available at any time by removing the key from the account, which takes effect immediately rather than waiting for expiry.
Why the model differs from token approvals
A conventional token approval grants a contract permission to move a specific token, often without a limit and without an expiry, and it persists until revoked.
Session keys invert this by defaulting to expiry and by scoping permission at the account level rather than per token contract.
The tradeoff is dependence on the account contract being correct, since the constraints are only as reliable as the code enforcing them, which places weight on the audit of that contract rather than on the user's vigilance.