Security

Tenant Isolation

Every API key is bound to a unique organization_id. All database queries are scoped to your organization. There is no way to access another tenant's private data. The one deliberate exception is Rooms (Beta): an opt-in, membership-checked shared bucket — an atom written to a room belongs to the room, not to any member's account, and joining a room exposes nothing from your private memory.

Your API key → organization_id → all queries filtered by org_id

Atoms, Hebbian edges, and usage metrics are all isolated per tenant. Consolidation is off on the hosted service, so no consolidation runs happen there (see the API reference).

Rooms & Cross-Account Sharing (Beta)

Rooms are the one deliberate crossing of the account boundary — an opt-in shared memory pool addressed as domain: "xroom:<room_id>" on the same write/read calls:

• Membership is checked on every request. Reads and writes against a room only succeed for active members; writes additionally require read_write scope.
• A room is its own bucket. Room atoms live in the room, not in any member's account — your private memory is never exposed by joining, and room content never appears in your normal (non-room) searches.
• Usage is billed to the authenticated caller, never the room owner.
• Invite codes default to one redemption (mnvr_...). Both MCP servers and the REST API can request a higher use limit with max_uses (up to 1000). Revocation is forward-only — future access stops, but content a member already read or wrote is not recalled.

API Key Security

• API keys are hashed (SHA-256) before storage. We never store plaintext keys.
• Key comparison uses constant-time comparison (secrets.compare_digest) to prevent timing attacks.
• Keys are shown exactly once at creation. If lost, revoke and create a new one.
• Key prefix (mk_live_...) is stored for identification without exposing the full key.

Data Privacy

• We do not train on your data. Your memories are used solely to serve your queries.
• No cross-tenant learning. Hebbian associations and valence updates are per-tenant. Inside an opt-in room (Beta) they are per-room — members' feedback intentionally updates the room's shared ranking; private accounts never learn from each other.

Transport Security

All API traffic uses HTTPS.

Rate Limiting

Per-organization rate limiting (all API keys in an organization share the same limits) prevents abuse, enforced independently at three layers:

Plan	Requests/min	Daily queries	Stored atoms
Free	60	1,000	10,000
Pro	600	50,000	500,000
Team	3,000	500,000	5,000,000
Enterprise	Custom	Custom	Custom

• Per-minute rate limit: HTTP 429 with Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers; retryable.
• Daily quota (reads, writes and feedback combined): HTTP 429 with X-DailyLimit-Limit, X-DailyLimit-Used, X-DailyLimit-Remaining headers; not retryable until the next day.
• Subscription / atom limit: HTTP 429 blocking writes (reads always work) when the subscription is suspended, past due, or over its atom limit, or when an administrator has stopped the organization (organization_banned), in which case memory deletions are refused too; not retryable. See Subscription / atom limit.

All three return code: RATE_LIMITED in the JSON body. See the Rate Limits section of the API Reference for full response shapes.

Infrastructure

• Database: PostgreSQL 18 with pgvector extension
• Memory API and its database: Railway, EU region (Netherlands)

The providers that process your data are listed under Sub-processors in the privacy policy.

Reporting Security Issues

Report vulnerabilities to security@mnemoverse.com.