# Keys and tokens

Every key and token the platform issues starts with a prefix that says what it is. A secret scanner can match them, and so can you.

| Prefix | What it is | Who makes it | Where it goes | How it's stored | How to revoke it |
| --- | --- | --- | --- | --- | --- |
| `l10p_` | A project key, for CI | An owner or admin, on the project's page under **CI keys** | Your CI's secrets, sent as `Authorization: Bearer` to the registry API | SHA-256 hash only | **Revoke** on the project's page |
| `l10m_` | An MCP key, for agents | An owner or admin, on the project's MCP page | The agent's MCP client, sent as `Authorization: Bearer` to the hosted MCP server | SHA-256 hash only | **Revoke** on the project's MCP page |
| `l10a_` | An MCP access token | The MCP server's sign-in, when a person signs in through your identity provider | Sent by the MCP client to that one server | SHA-256 hash only | The client revokes it, or an owner or admin signs the person out on the MCP page |
| `l10r_` | An MCP refresh token | The same sign-in, beside the access token | Sent by the MCP client to that server's token endpoint | SHA-256 hash only | As for `l10a_`. It's replaced on every use |
| `l10c_` | An MCP OAuth client id | The MCP server, when a client registers itself | The client's own settings | As is: it isn't a secret | An owner or admin revokes the client on the MCP page |
| `l10v_` | A host-verification token | Latitude 10, for the project's MCP server and for its API client proxy | A file or a DNS TXT record on your API's host | As is: it isn't a secret | Nothing to revoke: it proves only that you control the host |

`l10_`, with no letter after it, is the seller dashboard's key for kits and payments, not a platform key.

## How secrets are kept

CI keys and MCP keys are stored only as SHA-256 hashes, and shown once.

Your API credential for hosted MCP is sealed with AES-GCM 256 under a Worker secret, with a fresh IV each time, and one module decrypts it.

So a lost key can't be shown again: revoke it and create another. Access and refresh tokens are kept the same way, as hashes.

## Where this comes from

- `app/_lib/auth/keys.ts`
- `app/_lib/auth/tokens.ts`
- `app/workspace/_lib/keys.ts`
- `app/hosted-mcp/_lib/keys.ts`
- `app/hosted-mcp/_lib/tokens.ts`
- `app/hosted-mcp/_lib/oauth.ts`
- `app/hosted-mcp/_lib/server.ts`
- `app/hosted-mcp/_lib/credential.ts`
- `app/reference/_lib/playground/hosts.ts`
