Skip to main content

Authentication

Memanto uses a server-side Moorcheh API key combined with per-agent session tokens to scope memory operations, plus a separate management credential that gates agent lifecycle endpoints (create/list/get/delete/activate/deactivate an agent, and the status endpoint).

Server (Moorcheh)

Memanto reads MOORCHEH_API_KEY from its environment / configuration and authenticates on the server when calling Moorcheh.

Memory Operations (Client)

Memory endpoints require a session token in the X-Session-Token header. Tokens are obtained by activating an agent.

Server-Side Moorcheh API Key

Memanto does not accept a Moorcheh API key from clients. The key is set once on the server and is used for every Moorcheh call Memanto makes:
If the key is missing or invalid, Memanto fails fast at startup with MOORCHEH_API_KEY is not configured or MOORCHEH_API_KEY is invalid.

Getting a Moorcheh API Key

  1. Go to https://console.moorcheh.ai/api-keys
  2. Create a new API key
  3. Configure it on the Memanto server (env var, secrets manager, etc.)

Session Token Authentication

When Session Tokens Are Required

Memory operations require an X-Session-Token header obtained from agent activation:
  • POST /api/v2/agents/{agent_id}/remember
  • POST /api/v2/agents/{agent_id}/batch-remember
  • PATCH /api/v2/agents/{agent_id}/memories/{memory_id}
  • POST /api/v2/agents/{agent_id}/remember/extract
  • POST /api/v2/agents/{agent_id}/upload-file
  • DELETE /api/v2/agents/{agent_id}/memories/{memory_id}
  • POST /api/v2/agents/{agent_id}/recall
  • POST /api/v2/agents/{agent_id}/recall/as-of
  • POST /api/v2/agents/{agent_id}/recall/changed-since
  • POST /api/v2/agents/{agent_id}/recall/recent
  • POST /api/v2/agents/{agent_id}/answer
  • POST /api/v2/agents/{agent_id}/daily-summary
  • POST /api/v2/agents/{agent_id}/conflicts/generate
  • GET /api/v2/agents/{agent_id}/conflicts
  • POST /api/v2/agents/{agent_id}/conflicts/resolve
  • POST /api/v2/agents/{agent_id}/deactivate
The session must match agent_id in the path; otherwise the request is rejected. As an alternative to the X-Session-Token header, Activate Agent also sets an HttpOnly, SameSite=Strict cookie named memanto_session_token. get_current_session accepts either the header or the cookie — browser clients (like the built-in Web UI) never need to read the token out of JavaScript.
  • The cookie is set on POST /api/v2/agents/{agent_id}/activate and cleared on POST /api/v2/agents/{agent_id}/deactivate.
  • The cookie’s Secure attribute is set dynamically from the actual request scheme (Secure when the request arrived over HTTPS, omitted over plain HTTP). Memanto binds 0.0.0.0 with no built-in TLS by default, so a hardcoded Secure flag would silently stop browsers from ever sending the cookie back in that default deployment — put Memanto behind an HTTPS-terminating proxy in production to get Secure cookies.
  • If a near-expiry session is auto-renewed mid-request, the server transparently re-sets the cookie with the new token so cookie-authenticated clients don’t go stale.
  • API clients that use the X-Session-Token header (CLI, SDKs, direct API integrations) are unaffected — the cookie is purely additive for browser-based callers.

Management Endpoint Authentication (Agent Lifecycle)

Agent-lifecycle endpoints don’t take a session token (there’s no session yet), but as of v0.2.7 they do require authorization — either a management credential or a loopback client:
  • POST /api/v2/agents — Create agent
  • GET /api/v2/agents — List agents
  • GET /api/v2/agents/{agent_id} — Get agent details
  • DELETE /api/v2/agents/{agent_id} — Delete agent
  • POST /api/v2/agents/{agent_id}/activate — Activate (returns the token)
  • POST /api/v2/agents/{agent_id}/deactivate — Deactivate (also checked here, in addition to the session token above)
  • GET /api/v2/status — Inspect the active session
Prior to v0.2.7, these endpoints only checked that the server had a configured MOORCHEH_API_KEY — not that the caller was authorized. Combined with the default HOST=0.0.0.0 bind, any network peer could create agents, activate sessions, and obtain session tokens. Upgrade if you’re running an older version and Memanto is reachable from outside localhost.
Access is granted when either of these is true:
  1. The caller presents the management credential, matched with a constant-time comparison against the configured server credential:
    or
    The expected credential is MOORCHEH_API_KEY on the cloud backend, or MEMANTO_SECRET_KEY on the on-prem backend (see Session cookie hardening for how that same secret is generated when unset).
  2. The request originates from the loopback interface (127.0.0.1 / ::1, including IPv4-mapped IPv6) — so the local desktop CLI and Web UI keep working without attaching a key on every call.
Requests that satisfy neither condition get:
401 - Unauthorized (Management Auth Required)
Endpoints that remain fully open (no management credential, no loopback requirement):

Getting a Session Token

  1. Activate an agent (from localhost, no management credential needed):
From a non-loopback host, attach the management credential:
  1. Response contains a session token:
  1. Use the token in subsequent requests:

Example Request with Session Token

In Python

Session Token Details

Token Format

Session tokens are JWT (JSON Web Tokens):

Token Expiration

  • Duration: configured by the server via SESSION_DEFAULT_DURATION_HOURS (typically 6 hours).
  • Auto-renewal: Memanto auto-renews sessions that are near expiry on the next memory request.
  • Renewal: activate a new session with POST /api/v2/agents/{agent_id}/activate.

Decode Token (Python)

Common Errors

Missing Session Token

Fix: Activate the agent and include the returned token in X-Session-Token.

Invalid Session Token

Fix: Re-activate the agent and use the freshly returned token.

Session Expired

Fix: Activate a new session with POST /api/v2/agents/{agent_id}/activate.

Management Auth Required

Fix: Attach Authorization: Bearer <key> or X-Api-Key: <key> (the cloud MOORCHEH_API_KEY or the on-prem MEMANTO_SECRET_KEY), or call from a loopback client. See Management Endpoint Authentication.

Session / Agent Mismatch

If the session token was issued for a different agent than the one in the URL path, the server returns 500 with:
Fix: Activate the correct agent or call the endpoint with the matching agent_id.

Best Practices

DO

  • Store MOORCHEH_API_KEY as a server-side secret (env var, Secrets Manager, etc.)
  • Keep session tokens in memory on the client (don’t persist long-term)
  • Rotate the Moorcheh key periodically
  • Treat session tokens as sensitive — they grant memory access for an agent
  • If Memanto is reachable from outside localhost, attach Authorization: Bearer <key> or X-Api-Key on agent-lifecycle calls — don’t rely on network placement alone

DON’T

  • Commit MOORCHEH_API_KEY to source control
  • Reuse a session token across different agents
  • Log session tokens (or the management credential) to files or telemetry
  • Bind Memanto to 0.0.0.0 on an untrusted network without also setting a real MOORCHEH_API_KEY / MEMANTO_SECRET_KEY — that credential is what gates agent-lifecycle access for non-loopback callers

Security

API Key Management

Development:
Production (AWS Secrets Manager):
Production (Environment):

Session Token Security

  • Tokens are JWT — treat as sensitive
  • Don’t log tokens
  • Don’t expose in client-side code that ships to end users
  • Short-lived (configurable, default ~6 hours)
  • Unique per activation

Next Steps