Authentication boundary

Where each credential belongs

The authentication boundary separates OAuth consent, bearer-token storage, non-secret identity headers, and the access decision itself. Mixing them is the most common cause of a leaked token.

• OAuth consent lives in the client; XMemo never sees a pasted token on that path.
• XMEMO_KEY lives in the environment or a supported secret store, never in a config file committed to git.
• Identity headers are plain labels and are safe to write into configuration.
• Public discovery is read-only and secret-free.

Token-based client configuration

Reference the environment variable from the client config so the real value never appears in the file.

{
  "mcpServers": {
    "XMemo": {
      "type": "http",
      "url": "https://xmemo.dev/mcp",
      "headers": {
        "Authorization": "Bearer ${env:XMEMO_KEY}"
      }
    }
  }
}

What a rejected request looks like

A missing or insufficient credential is rejected before any memory is read. An empty result set is a valid no-match answer and is not an authorization signal.

401 — no valid bearer token or API key was supplied.
403 — the credential is valid but lacks memory:read or memory:write.
200 with zero results — authorized, nothing matched.