# Session Keys

> Documentation index: [llms.txt](https://namera.ai/llms.txt).

Source: https://namera.ai/docs/concepts/session-keys

Give an application or agent bounded access to one account.

A **session key** is a signing key with permissions attached to one account.
It lets an application or agent act without receiving the account owner's key.

Each session key has its own allowed actions, network installations, and
execution lifetime. Creating separate keys for different tasks makes their
permissions and access easier to manage independently.

## Three Different Kinds of Access [#three-different-kinds-of-access]

| Item                                   | Purpose                                                                              |
| -------------------------------------- | ------------------------------------------------------------------------------------ |
| Account owner                          | Approves installing or removing onchain authority.                                   |
| Session key                            | Signs operations within the authority installed for it.                              |
| API key or connected-app authorization | Authenticates a client and grants it access to selected session keys through Namera. |

An API key is not a session private key. Authorizing an app does not install
permissions onchain, and installing a session key does not authorize every app
to use it.

## Registration and Network Approval [#registration-and-network-approval]

A newly created session key starts **pending**. Its permissions must be approved
by the account owner and installed on a network before it can be used there.

The key becomes **active** after an installation is confirmed. That status does
not mean every requested network is ready: each network has its own installation
and validity period. A pending approval on Base is not made usable by a confirmed
installation on Ethereum.

Configure each network separately during creation. One key can have a 100 USDC
lifetime allowance on Ethereum and a 200 USDC allowance on Base, using each
network's token address. The allowances are independent, not a shared 300 USDC
budget. Lifetimes and signature authority can also differ by network.

The client also needs an active grant to the key. Namera evaluates the selected
key's complete permissions for each operation; it does not combine partial
permissions from different keys to make an action pass.

## Where the Signing Key Lives [#where-the-signing-key-lives]

A local session key signs on the machine where it was imported. A managed
session key signs through 1Claw. Both use the same delegated-access model and
require the appropriate network installation and Namera authorization.

Follow any encrypted import and backup instructions provided during creation.
Importing a key alone does not approve its network permissions or connect an app.
Do not share a private key or export passphrase with an agent.

## Changing Permissions [#changing-permissions]

A session key's permission configuration is fixed when it is created. To use a
different permission set, create a replacement key and authorize the intended
clients to use it. Revoke the old key when it is no longer needed.

## Ending Access [#ending-access]

Revoking a session key cuts off its grants through Namera immediately and starts
revocation. Any installed onchain permissions still require owner-approved
removal on each network. The key remains **revoking** while those operations
are unresolved; **revoked** means the removal lifecycle has finished.

Execution expiry and signature authority are different. Expiry does not remove
onchain message-signing authority. See
[Permissions and Policies](https://namera.ai/docs/concepts/permissions-and-policies#signature-permissions)
before enabling signatures.

Revocation is not a way to cancel a transaction that has already been submitted.
Track that submission separately.