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

# How Phantom KMS works

> Learn how Phantom KMS handles request stamping, policy enforcement, and transaction signing for embedded wallets.

Phantom’s Key Management System (KMS) lets apps use KMS-backed wallets without storing wallet private keys on the client device.

## What is KMS?

KMS allows users to securely generate, store, and access wallet keys inside trusted enclaves (TEE). When a KMS-backed wallet is selected, the client requests signatures from KMS rather than signing locally on-device.

From a client’s point of view:

* A KMS account is a local reference to a KMS-managed wallet (not a locally stored seed).
* App-level signing APIs can stay consistent. What changes is where the signature is produced (in KMS).

## Core components

### Backend services

* KMS API: Receives stamped RPC requests from clients.
* Policy engine enclave: Authenticates requests and authorizes operations (policies, scopes, rate limits).
* Signer enclave: Holds encrypted wallet seed material and produces signatures.
* Certifier enclave: Issues certificates and attests to configurations.

### Data model (what KMS manages)

* Organization: The primary unit of access control. Contains users, authenticators, and configuration.
* Wallet: Encrypted seed material plus derived chain addresses.
* Policy: Rules linking organizations/users to wallets with scoped permissions and limits.
* User: Roles and authenticators. Users may be time-limited (ephemeral), depending on the integration.

## How signing works

When a KMS-backed wallet is selected, signing is performed by KMS. The client sends a signing request to KMS, KMS enforces policy, and KMS returns a signature.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant Client as Client
    participant Api as KMS API
    participant Policy as Policy engine enclave
    participant Signer as Signer enclave
    participant Network as Blockchain network

    Client->>Api: Send signing request
    Api->>Policy: Authenticate and authorize request
    Policy->>Signer: Request signature (if allowed)
    Signer-->>Policy: Return signature
    Policy-->>Api: Return signature
    Api-->>Client: Return signature
    Client->>Network: Submit signed transaction
```

1. The client sends a signing request to the KMS API.
2. The policy engine enclave authenticates and authorizes the request, enforcing policies (for example, spending limits).
3. If allowed, the signer enclave produces a signature.
4. KMS returns a signature to the client. The signed transaction is then submitted to the network.

Each request to KMS is cryptographically signed with an authenticator key held client-side (where it’s stored depends on the integration). KMS checks that signature and independently enforces policy before it will sign.

## The authenticator

KMS uses an authenticator to confirm that KMS signing requests are coming from the user. The authenticator is a cryptographic identifier key that’s separate from wallet keys.

The authenticator is used to stamp KMS requests so the client can request signatures without exposing wallet private keys.

## How apps authenticate to KMS

### Embedded wallet

Use embedded wallet mode when your app integrates directly with the [SDK](/wallet-sdks-overview).

What happens:

* Your app integrates with the embedded SDK directly.
* The SDK generates a non-extractable key (for example, via WebCrypto / an IndexedDB stamper).
* The SDK completes OAuth via Phantom Connect. The session returns organization and wallet identifiers.
* The embedded SDK holds a restricted authenticator and uses it to stamp KMS requests.

### MCP server

In [MCP server](/phantom-mcp-server/index) integrations, the user signs in through Phantom Connect. The MCP server stores the resulting session and uses a stamper key to sign requests to KMS. KMS validates each signed request, enforces policy, and then signs and submits.

## Where you’ll see KMS in Phantom

* Mobile: KMS accounts can appear alongside local accounts. Signatures are produced by KMS.
* Browser extension: Adds origin validation and consent screen. KMS accounts can be created or discovered depending on the flow.
* Use the embedded wallet flow. Signing routes through KMS using the embedded authenticator model.
* MCP server: Agent wallets use a Connect sign-in and a stamper key to stamp KMS requests. KMS validates each request, enforces policy, and then signs and submits.

## Glossary

* Authenticator: A cryptographic identifier key that is separate from wallet keys and is used to stamp KMS requests.
* Embedded wallet: A no-extension integration where the app uses the embedded SDK, creates a device-protected authenticator, and stamps KMS requests client-side.
* Enclave/TEE: Trusted environment used to protect key operations.
* Organization: Access-control container for users, authenticators, and policies.
* Policy engine: Enclave that authorizes operations and enforces policies/limits.
* Stamper key: A client-side key used to sign (stamp) requests to Phantom services, including KMS.