> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Session keys

> Authorize scoped actions once so your application can transact without repeated wallet prompts.

Session keys let your application execute approved actions without asking the user to sign every transaction. The user authorizes a set of permissions with their passkey once; your application uses a separate signing key for subsequent actions within that scope.

This supports repeated interactions and background automation, such as trading or scheduled vault deposits, without giving your application unrestricted control of the wallet.

## Define the permitted actions

A session specifies which chains, contracts, and functions your application can use. Parameter rules can fix a recipient or cap an amount, while time windows and usage limits bound how long and how often an action remains available.

These permissions are enforced onchain by the account's session-key validator. Calls outside the approved scope are rejected, even if your application submits them.

For crosschain workflows, permission to execute on the destination chain is separate from permission to claim assets on a funding chain. A session must explicitly authorize both.

## Application-held signing

Your application holds the session private key. Rhinestone stores public grant metadata and coordinates transaction preparation and submission, but does not receive that key.

Anyone with the key can exercise its remaining permissions. Use narrowly scoped, short-lived grants and protect the signer accordingly. Deleting a local key does not revoke its onchain authority, and the current app-origin SDK does not expose a revocation method. See [Security](/wallets/session-keys/security) for custody and revocation boundaries.

## Get started

Start with an authenticated [embedded wallet](/wallets/embedded-wallets/accounts), then define the authority your workflow needs.

| Guide                                                      | What it covers                                                           |
| ---------------------------------------------------------- | ------------------------------------------------------------------------ |
| [Create a session](/wallets/session-keys/create-a-session) | Obtain user approval and execute with an application-held signer.        |
| [Session limits](/wallets/session-keys/session-limits)     | Constrain actions, parameters, chains, validity, and usage.              |
| [Security](/wallets/session-keys/security)                 | Protect the signer, recover grant metadata, and handle compromised keys. |

## Choose an integration path

Both paths configure the same onchain validator, so the permission model and its enforcement are identical. The setup differs.

**Embedded wallet** is the default. The user grants the session with their passkey, your application holds an ECDSA session signer, and Rhinestone prepares and submits each later intent. The guides above cover it.

**Custom setup** covers accounts your own stack creates and operates:

* **Agent wallets** — an account an autonomous agent transacts from, with the session's permissions bounding what it can do.
* **Backend-only wallets** — an account with no end user, operated entirely by your service.
* **Your own signer** — an account owned by an external wallet, a key you hold, or a multisig rather than a Rhinestone passkey.

You install the validator and configure each policy yourself, which is also what to use when you need something the embedded flow does not expose yet: session owners other than a locally held ECDSA key, ERC-1271 signing by the session itself, enabling a session per chain, unrestricted sessions, or a non-exportable KMS or HSM signer.

Start at [Create a session with a custom setup](/wallets/session-keys/custom-setup/create-a-session).