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

# How Totem keeps games isolated

> Understand game origins, iframe isolation, upload validation, and API-key storage.

Totem treats every uploaded game as untrusted static content. It separates games from each other and validates an archive before extracting or serving it.

## One isolated origin per game

Each game is served from its own isolated user-content origin. The public play URL is a Totem platform page that frames that isolated game.

Because browser storage follows origins, one game cannot read another game's cookies, local storage, or other origin-bound data.

## Sandboxed frame

The platform loads the game in a sandboxed iframe. The game runs as browser content, not as part of the dashboard or the Totem platform application.

## Validation before extraction

Totem rejects unsafe archive contents before a build goes live:

* Path traversal, absolute paths, backslashes, empty paths, dotfiles, and `node_modules` paths.
* Symlinks, hardlinks, and non-regular files.
* File extensions outside the web-build allowlist.
* Archives over the compressed, unpacked, or file-count limits.
* Corrupt gzip or tar data.
* Builds without `index.html` at the archive root.

## API keys

API keys begin with `ttm_`. Totem shows the plaintext once, then stores only a hash. A lost key cannot be recovered. Create a replacement and revoke the old key.

You can keep separate keys for separate MCP clients. Revoking one key does not affect the others.

## Current limits

Totem does not currently provide:

* Server code or a database inside a game build.
* Teams or organizations.
* Custom domains.
* Payments or monetization.
* A public REST API.
* Offline play.
* Self-service game deletion.

This page describes the shipped isolation model. It is not a security certification or a claim that uploaded games have been manually reviewed.