# Supported permissions for session keys

> Explore the supported permission types you can apply to session keys to safely delegate access in smart accounts.

> For the complete documentation index, see [llms.txt](/docs/llms.txt).

<Tip title="Most projects should use @alchemy/wallet-apis">
  [`@alchemy/wallet-apis`](/docs/wallets/quickstart) supports session keys through [`wallet_createSession`](/docs/wallets/reference/wallet-apis-session-keys/api) and the [`grantPermissions`](/docs/wallets/reference/wallet-apis-session-keys/sdk) SDK flow. This page covers the lower-level path: composing Modular Account V2 session-key permissions directly with `@alchemy/smart-accounts`. Use it when you need lower-level control for custom onchain validation and permission wiring.
</Tip>

## What permissions can you apply to session keys?

Session keys work best when they are tightly scoped. Modular Account V2 gives you a flexible set of built-in permission types. These permissions are validated onchain, removing any dependency on an offchain engine and increasing security of users' accounts.

Use these to limit what a key can do, for how long, where it can call, and how much it can spend.

### Time Range

Supports limiting keys with a start and/or expiry time ranges

### ERC-20 Spending Limits

Supports limiting how much of a specific ERC-20 token a key may spend

### **Gas and native token spending limits**

Supports limiting how much native tokens, e.g. ETH on mainnet, a key can spend

### Access Control Lists

Supports limiting function selectors and/or external contracts that a key may interact with.

### Internal Selector Allowlist

Supports limiting what functions a key may call on the Modular Account (e.g. installing or uninstalling modules, or upgrading the account)

> You can combine multiple permissions on a single session key. These can be layered to match the minimum required access for your use case.

## Composing permissions: fine-grained control

Permissions are composable. You can apply multiple permissions to a single session key to tightly define its behavior.

Example: You could create a session key that:

* Expires after a configured time
* Can call just one staking contract
* Spend no more than 100 USDC

Use Case: One key is scoped to auto-stake a user's funds once a day, but only within a capped budget and only on a verified contract.

By combining permissions, you can build tailored, safe delegation schemes -- perfect for dApps, relayers, and complex workflows.