Privacy Policy

Last updated: August 2026

This Privacy Policy explains how Mnemoverse ("we", "us", or "our") collects, uses, and protects information when you use our website at https://mnemoverse.com, our Memory API at https://core.mnemoverse.com, and any MCP connector (Claude, ChatGPT, Cursor, VS Code, or other MCP-compatible client) that connects to that API. Section 11 below covers the connector- and API-specific data flow in detail; sections 1–10 cover the website.

Mnemoverse is operated by UINSIDE Inc., a Delaware corporation with its principal address at 3418 NE 210th Ln, Miami, FL 33180, USA. UINSIDE Inc. is the data controller for the account, billing, and operational data described in this policy — the data we decide to collect to run the service. For the memory content you choose to store through the API, you (or the organisation on whose behalf you act) decide what is stored and for what purpose, and UINSIDE Inc. stores and processes that content on your behalf, on your instructions, as a data processor. Business customers who require a data-processing agreement (DPA) can request one at support@mnemoverse.com.

1. Information We Collect

We may collect the following types of data:

• Personal Information you voluntarily provide, such as your email address when you contact us.
• Usage Data, including IP address, browser type, pages visited, and time spent on our site, collected via analytics tools and cookies.
• Signup Attribution Data: when you create an account, we record how you found us — the referring page (scheme, host, and path only; no query strings or fragments), any campaign tags (UTM parameters) on the link you followed, the page you first landed on, and the time — linked to your account. We process this under our legitimate interests to understand which channels and content bring users to Mnemoverse; it is never sold or shared, and it is deleted together with your account.

2. How We Use Your Information

We use the collected data to:

• Respond to inquiries or requests.
• Improve our website and user experience.
• Analyze traffic and usage patterns (via anonymized data, and — for signup attribution only — the account-linked data described in Section 1).

We do not sell or rent your personal data to third parties.

3. Legal Basis for Processing (GDPR)

If you are in the European Economic Area (EEA), we rely on a legal basis for each processing purpose rather than treating one basis as covering everything:

• Performance of a contract or steps you request before entering one — creating and operating your account; providing the Memory API, MCP connectors, Shared Rooms, support, and billing; and processing the content and instructions you submit so those services work.
• Legitimate interests — securing the service, preventing abuse, diagnosing failures, and improving reliability, where those interests are not overridden by your rights and reasonable expectations.
• Consent — optional cookies or similar processing where consent is required. You may withdraw consent without affecting processing that was lawful before withdrawal.
• Legal obligations — records or disclosures we must retain or make under applicable law.

Accepting a room invitation is a product action that requests access to a shared service. It is not presented as consent to unrelated processing or marketing. Where content a member stores into a room includes another person's personal data, we process it to provide the requested shared service (a legitimate interest, balanced against that person's rights); the member is responsible for having a lawful basis to share it.

4. Data Storage and Security

We take appropriate technical and organizational measures to protect your personal data against loss, misuse, and unauthorized access.

5. Your Rights

Depending on your location, you may have the following rights:

• Access the data we hold about you
• Request correction or deletion
• Object to or restrict data processing
• Receive data you provided in a portable format where the right to portability applies
• Withdraw consent at any time
• Lodge a complaint with the data-protection authority responsible for your place of residence, work, or the alleged infringement

To exercise your rights, contact us at support@mnemoverse.com.

6. Third-Party Services

We may use third-party services (e.g., analytics tools) that process data on our behalf. These services are carefully selected and comply with data protection laws.

7. Data Retention

We retain personal data only for as long as necessary to fulfill the purposes for which it was collected, unless a longer retention is required by law.

8. Children’s Privacy

Our website and the Memory API service are not directed at children. We do not knowingly collect personal data from children below the age of digital consent that applies to them (13 in the United States; in the EEA, 16 — or the lower age, down to 13, that a member state has set). If you believe a child has provided us personal data, contact us at support@mnemoverse.com and we will delete it.

9. Changes to This Policy

We may update this Privacy Policy from time to time. Any changes will be posted on this page with an updated revision date.

10. Contact Us

If you have any questions, contact us at support@mnemoverse.com.

11. Memory API & MCP Connectors

This section governs data processed by the Mnemoverse Memory API and by any MCP (Model Context Protocol) connector you authorise to use it — including the Mnemoverse connectors in Claude, ChatGPT, Cursor, VS Code, and any other MCP-compatible client. If you only browse our website, sections 1–10 apply and section 11 does not.

11.1 What the Memory API stores and retrieves

The MCP surface covered here includes six core memory tools and three Shared Rooms tools. A particular connector may expose only a subset. Each operation has a defined effect on the data we store on your behalf:

Tool	What it does	What we store as a result
memory_read	Search the memory bucket addressed by the request and return a ranked list.	The query is not persisted as a memory atom. The service updates access timestamps and counts for the retrieved atoms, and applies a weak update to the co-activation weights used for ranking (memory_feedback applies a stronger one). Query embeddings may be retained transiently for cache and abuse-detection purposes (see 11.6).
memory_stats	Return counts and aggregates over your stored memories (totals, domains, average quality scores).	Nothing new.
memory_write	Create a new memory atom from the content and optional metadata (concepts, domain) you supply.	The atom: content, concepts, domain, timestamp, and the user/project identifiers that scope it. A write that targets a room additionally records authorship provenance — which member (and agent/environment) created the atom — which other room members can see and filter on. May be filtered by our importance gate and reported back as not stored (stored: false) if below threshold, rather than silently dropped; never overwrites or deletes an existing atom.
memory_feedback	Adjust the quality scores (valence / importance) of one or more existing atoms you can access — your own atoms, or atoms in a room where you hold read-write membership.	The updated score values on the targeted atoms, and the derived co-activation and ranking weights those scores feed.
memory_delete	Permanently delete a single atom by its identifier.	The atom is removed from primary storage.
memory_delete_domain	Permanently delete all atoms in a given domain.	Every atom in that domain is removed from primary storage. Guarded by an explicit confirm: true flag in the tool input.
memory_create_room	Create an empty shared-memory room.	A room record and the creator's owner membership.
memory_invite_to_room	Create a room share code with a scope, expiry, and use limit.	A hashed invite record, its scope, expiry, use limit, and redemption count. The plaintext code is returned when created and is not stored in plaintext.
memory_join_room	Redeem a valid room share code for the signed-in account.	A room-membership record and updated invite redemption state.

Tool descriptions match the intended server effects. A read does not create, overwrite, or delete memory content, but it does update the access timestamps, counts, and co-activation weights disclosed above.

11.2 What we do NOT collect through the Memory API

• We do not read the contents of conversations in your MCP client (e.g. your Claude or ChatGPT chats). The client decides what to send us via the operations above; everything outside those calls stays in the client.
• We do not infer or attach additional identifiers (such as device fingerprints) to the atoms you write.
• We do not sell, rent, or otherwise transfer your memory atoms to third parties for marketing or advertising purposes.

11.3 The OAuth connect flow

When you connect a Mnemoverse MCP connector to a client (e.g. Claude "Add connector" or ChatGPT App Directory), your client takes you through an OAuth 2.1 authorization-code flow with PKCE on our authorization server at https://auth.mnemoverse.com. During that flow:

• You log in (or sign up) with the credentials your Mnemoverse account uses (email + password, or an OIDC identity provider if one is enabled on your account).
• You see a consent screen listing the scopes the client is requesting (openid, profile, email, memory:read, memory:write, and offline_access for long-lived sessions). You can approve the listed scope set or deny the authorization request. An approved token is limited to the scopes shown on that screen.
• Your client receives an access token bound to your account and to the Memory API as the audience. The client stores its copy; we do not access the client's local token store. Our authorization server also stores the token and grant records required by the current OAuth implementation for validation, expiry, audit, and revocation.

The OAuth flow is documented for developers at /api/agent-setup. You can revoke a connector at any time from your Mnemoverse console under Settings → Connected apps; revocation invalidates the client's tokens immediately.

11.4 Retention

• Private memory atoms are retained until you delete them (via memory_delete / memory_delete_domain, the console UI, or an account-deletion request — see 11.5). We do not auto-expire private atoms based on age.
• Shared-room content is retained until the room bucket or the relevant content is deleted through an available control or a verified support process. Archiving a room disables ordinary access but does not erase its memory bucket, and archived room content does not currently auto-expire merely because it was archived. See 11.8 for shared-content requests and the effect of membership revocation.
• OAuth tokens use shorter-lived access tokens and longer-lived refresh tokens, with expiry controlled by the authorization-server configuration. Refresh tokens are revoked when you revoke the connector or delete the account.
• Operational logs (request timestamps, tool name, success/failure, byte counts — not the contents of atoms or query text) are held by our monitoring and log providers under their retention settings, and are used only for operations and security.
• Backups of the primary memory store are kept on the rolling schedule of our database provider. A delete via memory_delete / memory_delete_domain removes the atom from primary storage immediately; until the backup window rolls past it, a copy may still exist in a backup we cannot selectively edit.

What we do not yet automate, stated plainly. We do not currently run our own scheduled job that expires logs or backups on a fixed clock, and account deletion is carried out by our team on a verified request rather than by a self-service button. We are building both:

Commitment	Target
Scheduled retention enforcement — logs and backups expired automatically on a stated clock, and the clock published here	31 December 2026
Self-service account deletion from the console, without contacting support	31 December 2026

Until those ship, deletion happens the way section 11.5 describes: the per-atom and per-domain controls act immediately and by yourself, and account-level erasure is handled by our team on request. We would rather publish this gap than publish a retention clock we cannot yet enforce.

11.5 Deletion and your control

You have several ways to remove data, in increasing order of scope:

• Per-atom deletion — call memory_delete from your client, or use the atom-level delete control in your console. Irreversible.
• Domain-level deletion — call memory_delete_domain (with the required confirm: true flag) or use the domain delete control in your console. Removes every atom tagged with that private domain. It does not act on shared room (xroom:) domains — room-content deletion is support-assisted (see 11.8). Irreversible.
• Connector revocation — revokes the OAuth tokens for one client without touching your atoms. From console.mnemoverse.com → Settings → Connected apps.
• Account deletion — email support@mnemoverse.com from the address on the account. We delete the account record, your private account-owned atoms, OAuth state, and corresponding stored embeddings within 30 days of verifying the request. Copies inside backups disappear as the provider's backup window rolls past them, as described in 11.4.

Subject-access requests (your right to a copy of the data we hold, or to restriction/objection under GDPR) follow the same channel.

Account deletion does not automatically erase content previously shared into a room, because that content is stored in a shared bucket and may form part of other members' records. You may include room content in an access, correction, restriction, or erasure request. We will verify the request, assess the affected content and the rights of other people, and delete, de-identify, or restrict it where required. Where applicable, we also notify recipients to whom the personal data was disclosed.

11.6 Sub-processors

We use a small set of sub-processors to operate the Memory API. We assess their security and data-protection posture before use and when material processing changes.

Provider category	Purpose	Data exposed
Railway — infrastructure and database hosting for the memory engine	Compute, network, and managed PostgreSQL (with pgvector) for the Memory API's memory store.	Memory atoms, shared-room buckets, and operational logs.
Neon — managed PostgreSQL for accounts and authorization	Stores your account and identity records, sessions, and the OAuth token and grant records issued by the authorization server.	Email address, account identifiers, session records, and OAuth token/grant records.
Prisma Data Platform (Accelerate) — database connection proxy	Edge connection pooling and query routing in front of the accounts database.	The account and authorization data above, in transit to Neon.
Cloudflare — edge runtime and network	Runs the authorization server at auth.mnemoverse.com and provides edge routing and CDN for our sites and APIs.	Request metadata and IP address.
NVIDIA — hosted embedding API (when configured)	Generating semantic embeddings of memory content and search-query text (model nv-embedqa-e5-v5). Depending on configuration, embeddings run on either a local model or this hosted API; where the hosted API is used, that content is sent to NVIDIA.	Memory atom content and search-query text (sent as the embedding input). We do not include account identifiers in the embedding request.
Resend — transactional email	Account and subscription-lifecycle notifications (e.g. suspension and usage-limit notices).	Account/billing contact email address, message content.
Sentry / Axiom — error monitoring and log aggregation	Capturing errors, request-level performance metrics, and operational logs from the Memory API and the authorization server.	Error stack traces and request metadata (path, status, latency). Memory-atom and query content is not intentionally included.

The MCP client provider you choose is also a recipient of the tool calls and results handled in that client. For example, when you authorise the Claude or ChatGPT connector, Anthropic or OpenAI respectively processes those payloads under its own terms and privacy policy. These client-side paths are not sub-processors we appoint to operate the Memory API. If you do not connect through such a client, no data flows through that path.

A current list of the sub-processors we use is available on request at support@mnemoverse.com.

International transfers. Some of the sub-processors above may process personal data outside your country, including outside the European Economic Area (EEA) and the United Kingdom. Where we transfer personal data out of the EEA or UK, we rely on an appropriate safeguard — an adequacy decision where one applies, the European Commission's Standard Contractual Clauses (with the UK Addendum where applicable), or, where a provider is certified, the EU–US Data Privacy Framework. Our sub-processors are established primarily in the United States and the European Union; the current list, with each provider's location and transfer safeguard, is available on request at support@mnemoverse.com.

11.7 Security

The Memory API enforces multi-tenant isolation through database-level row-level security for your private memory: every read and write against your own account is scoped to the authenticated user and (where applicable) project, and a query that attempts to read another tenant's private data is rejected by the database engine itself, not by application logic alone. Access tokens have a short lifetime and use audience-binding so a token issued to one resource cannot be replayed against another.

The one deliberate exception to tenant isolation is Shared Rooms (Beta) — see 11.8. A room is an opt-in, membership-checked shared memory space that more than one account can use by design. Access to room data is authorized by an active room membership and its scope, which the API checks on every request and which a database row-level- security policy also enforces — a different boundary from the private-account isolation that scopes your own memory. Rooms do not weaken isolation of your private memory: content stays in the room bucket it was written to, and joining a room does not expose anything from your private account to other members.

Breach notification. If a personal-data breach affecting your information occurs, we assess it promptly and, where the law requires, notify the competent supervisory authority (in the EEA, within 72 hours of becoming aware) and inform affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms. Because a Shared Room's storage is used by more than one account, a breach affecting a room may affect several members at once, and we notify each affected member on that basis.

11.8 Shared Rooms (Beta)

Beyond your private memory, the Memory API supports an opt-in shared memory space called a room (/api/rooms). Providing and securing the room requested by its members is part of the service described in section 3. A room is its own memory bucket, separate from any member's private account. Private content is not moved into a room automatically: room sharing occurs when a request authenticated to a member's account targets the room address (domain: "xroom:<room_id>").

• Membership is required and checked on every call. You must be an active member of a room — added by the room's owner through a share code (single-use by default, with a configurable use limit) or the console — before access succeeds. Membership is either read-only or read-write, may expire, and may be revoked by the room owner. Support may also act on a verified legal or account-security request.
• Current and future active members are recipients of room content. Content that is successfully stored in a room can be retrieved by active members whose scope permits the operation. Someone invited later may therefore receive content stored before they joined. Read-only members cannot write, give feedback, or run other write-scoped operations. Room content is not made available through the room interface to people without active membership.
• Room usage is attributed and billed to the member who makes the call, not to the room's owner — a write or read against a room consumes the calling member's own account and quota, the same as a private-memory call.
• What you put into a room, you cannot take back yourself. A room is shared by design, so contributing to one is closer to saying something in front of others than to filing it in your own drawer. There is no control that lets a member retract their own past contributions from a room, and leaving or being removed does not withdraw them.
• Membership revocation is access control, not erasure. Removing a member stops future access immediately but cannot make them forget information they already received, and does not delete content they previously contributed. Re-inviting a removed member restores access under the new active scope.
• Shared-content rights remain available. Revocation does not limit anyone's applicable rights of access, correction, restriction, objection, portability, or erasure. A member, former member, room owner, or other data subject may send a verified request concerning personal data in room content to support@mnemoverse.com. We assess the request against the requester's identity, authorship or data- subject relationship, the room's shared context, and other members' rights.
• Room deletion is currently support-assisted. The console's archive action disables ordinary room access but does not erase the storage bucket. Deletion of a room bucket happens on a verified request, which we assess case by case — a room owner may ask, and so may anyone exercising a data-protection right over personal data the room holds. Archived content remains in primary storage until that process completes; archiving alone does not start an automatic expiry period. Deleted primary data then disappears from backups as the provider's window rolls past it (11.4), except where a legal obligation requires longer retention.

If you invite someone into a room, or accept an invitation to join one, content successfully stored there may be disclosed to the room's current and future active members under the scope and retention rules above. The join screen should be read together with this section before you accept.

11.9 Changes to this section

We will keep section 11 in step with the actual behaviour of the Memory API. If we add a tool, add a sub-processor, change retention, or change the OAuth scopes, we update this section and bump the "Last updated" date at the top of the page. We do not silently expand the scope of what the API does without a documentation change.

Related

• Agent setup — connecting MCP clients
• MCP server reference
• API security
• Terms of Service
• Cookies Policy