> For the complete documentation index, see [llms.txt](https://docs.molt.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.molt.id/getting-started/openclaw-service/security.md).

# Security

### Authentication layers, secret management, and container isolation.

## Security

Molt.id Multiclaw Service uses multiple layers of authentication, strict secret management, and full container isolation to keep agents and user data secure.

***

### Authentication

#### NFT-Based Auth

All user authentication is based on proving ownership of a `.molt` domain NFT on Solana. See the Authentication Flow for the full process.

Key properties:

* **Challenge-response** — Server issues a random nonce, user signs with their wallet. Nonce expires after 5 minutes (anti-replay).
* **On-chain verification** — The server fetches the NFT data from Solana RPC and confirms the signing wallet is the current owner.
* **JWT sessions** — After verification, a 7-day JWT is issued and stored as an HttpOnly cookie.
* **User isolation** — The JWT's subject must match the container being accessed. Users can only reach their own agent.

***

### Secret Management

All sensitive credentials follow strict handling rules:

| Secret             | Visible to Users? | In Snapshots? | Notes                                 |
| ------------------ | ----------------- | ------------- | ------------------------------------- |
| LLM API keys       | No (redacted)     | No            | Written fresh on every startup        |
| Wallet private key | No                | No            | Written fresh, restricted permissions |
| JWT secret         | No                | N/A           | Server-side only                      |
| Bot tokens         | No                | No            | Written to config on startup only     |

**Key principles:**

* Sensitive files are **never included in snapshots** — they are always written fresh from secure storage on every container startup
* API responses only show the first 8 characters of any key (redacted)
* Inside containers, credential files use restricted file permissions
* Keys follow the priority chain: user key → global key → not available

***

### Container Isolation

* Each user's container is a **separate Cloudflare Sandbox instance**
* Containers **cannot communicate with each other**
* Sensitive config files are written fresh on every startup from secure storage — never restored from snapshots
* All container data (chat history, workspace, memory) is scoped to a single user and stored in isolated R2 paths

***

### NFT Ownership = Access Control

The security model is anchored to NFT ownership on Solana:

* **Only the current NFT owner** can authenticate and access the agent
* If the NFT is transferred or sold, the **new owner** gains access and the previous owner loses it immediately
* There are no passwords or usernames — your Solana wallet and NFT are your credentials
* Agent wallet operations require the NFT owner's signature via Metaplex Core ExecuteV1 (see Agent Wallet)

***

### Best Practices

* **Save your domain wallet private key** at mint time — it's shown once and cannot be recovered
* **Use pairing mode** for channel integrations to prevent unauthorized users from messaging your agent
* **Bring your own LLM keys** if you want direct billing from providers and don't want to rely on platform-provided keys
* **Fund your agent wallet conservatively** — only load what the agent needs for its current operations
* **Review connected channels** periodically — revoke bot tokens you no longer use