Authentication

Mneva uses one credential type: per-tenant API keys. Every customer brain has a key; that key authorizes every read and write against the brain.

Tenant API keys

Keys look like:

mnv_c8f92f82050d9b141e72fbb2d60b407df76f527b5f9a042a

The prefix mnv_ is permanent. The body is 24 random bytes hex-encoded. The key is shown once at signup; only the last 4 characters are persisted by the SaaS as a display hint. If you lose it, rotate.

A key resolves to exactly one tenant brain. Tenant brains are structurally isolated — see Data isolation for the model.

Headers

The MCP wrapper sets the right headers automatically. If you're calling the REST API directly, the customer-facing endpoints want:

x-mneva-key: mnv_...your_key...

The header is required on every /v1/* request. Missing or invalid → HTTP 401:

{ "error": "invalid or missing API key" }

Rotation

From your dashboard at mneva.dev/dashboard, the Rotate key button mints a fresh key. The old key dies the moment the new one is created — there is no overlap period. The brain itself is untouched: same memories, same beliefs, new credential.

This is the right move whenever a key has been (or might have been) exposed: committed by accident, included in a screenshot, pasted into the wrong tab.

The agent header

For multi-agent / Team plan use, pass MNEVA_AGENT to the MCP wrapper:

"env": {
  "MNEVA_KEY": "...",
  "MNEVA_AGENT": "alice"
}

The wrapper forwards this as X-Mneva-Agent on every request. It is used by note_about to attribute observations. Unset → defaults to default. Solo users can ignore it.

The agent name is not a secondary credential. It does not authorize anything; the key alone does the auth.