Privacy Policy

Last updated: October 14, 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, the Mnemoverse console at https://console.mnemoverse.com, our Memory API at https://core.mnemoverse.com and the SDKs that call it, any MCP connector (Claude, ChatGPT, Cursor, VS Code, or other MCP-compatible client) that connects to that API, and Sigma, our pull-request reviewer in closed beta (together, the "Services"). Sections 1–10 apply to all of them. Section 11 below covers the connector- and API-specific data flow in detail, and section 12 covers Sigma.

Mnemoverse is operated by UINSIDE Inc., a Delaware corporation. Its registered office in Delaware is at 251 Little Falls Drive, Wilmington, DE 19808, USA, with Corporation Service Company as its registered agent.

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:

• Account and sign-in data: when you create or sign in to an account, your name, email address, username, profile picture, the optional "About you" text in your profile, account and organisation identifiers, a password hash if you sign in with email and password, and the IP address and user agent of each sign-in session. If you sign in with Google or GitHub, we also receive the details that provider shares (section 11.6). For each app you connect we keep its client identifier, the scopes you granted, the user identifier issued to it, and your consent and grant records (section 11.3).
• Credentials: the OAuth tokens and Mnemoverse API keys that authenticate your requests. We store API keys only as hashes, and no tool returns a token or key value.
• Personal information you send us: messages, your email address, attachments, and anything else you include when you contact us, ask for support, or exercise a privacy right.
• Billing data: your plan, billing status, and the transaction and subscription identifiers of your payments. Stripe collects card details on its own pages; we do not receive or store full card numbers or card security codes.
• Usage Data, including IP address, browser type, pages visited, and page performance on our website, collected through Cloudflare Web Analytics, a cookie-free beacon described in the Cookies Policy. We do not use it to build advertising profiles.
• Technical and security data: when you use the console, the Memory API, or a connector, the IP address and the approximate country derived from it, user agent, requested route and host, timestamps, rate-limit counters, request identifiers, response status and duration, the outcome of authentication, and which client made the request (for example ChatGPT, Claude, Cursor, or the API). Our application logs do not intentionally record memory text, search text, raw tool responses, access tokens, or API keys. Our infrastructure providers may keep their own network and security logs.
• 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:

• Authenticate you, keep you signed in, and enforce permissions.
• Store, search, return, organise, rate, and delete memories at your direction, and return to ChatGPT, Claude, or another connected client the result of the tool you invoked.
• Secure the Services, prevent abuse, keep each account's data isolated, investigate failures, and keep the Services reliable.
• Provide support, billing, and service notices, and meet our legal obligations.
• 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, use memory content for advertising, or use private memory content to train public or general-purpose AI models.

3. Legal Basis for Processing (GDPR)

Where the GDPR, the UK GDPR, or a similar law applies to you, 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. On the same basis we may send you short service emails that help you start using what you signed up for, for example when an API key you created has not made a call yet. They are about that service, not marketing of other products. You can object to them at any time, and we then stop sending them: each one says how to unsubscribe, and you can also reply to it or write to support@mnemoverse.com.
• Consent — optional cookies, analytics, communications, 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: encryption in transit, access controls, isolation between accounts (section 11.7), short-lived OAuth credentials, rate limits, redaction of secrets from logs, and monitoring. No system is completely secure.

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. We may need to verify that you control the account a request concerns. The controls you can use yourself (deleting memories and domains, disconnecting a connected app, revoking an API key) are described in sections 11.3 and 11.5.

6. Who Receives Your Data

We disclose personal data only as needed, and only to these recipients:

• Our sub-processors, listed with what each does for us and where in section 11.6, and for Sigma in section 12.2. Cloudflare also runs the website's cookie-free analytics (section 1). They process data on our behalf, and we do not permit them to use memory data for their own advertising.
• Third parties you choose, such as the AI client you connect (ChatGPT, Claude, Cursor), which receives the results of the tools it calls, and Google or GitHub if you sign in with them (section 11.6). Each processes data under its own terms and privacy policy; OpenAI, for example, decides how it processes your ChatGPT conversations.
• Professional advisers and authorities, where reasonably necessary for legal advice, compliance, fraud prevention, protecting rights, or answering a valid legal request.
• A buyer, investor, or successor in a merger, financing, reorganisation, or sale, subject to confidentiality and applicable law.

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. Section 11.4 states how long the Memory API keeps memories, tokens, logs, and backups, and section 12.3 where Sigma's retention is published. When you ask us to delete your account, we delete the account record and the data section 11.5 lists within 30 days of verifying the request.

Two kinds of records outside the Memory API have their own maximums:

• Billing records (plan, invoices, payment status and the identifiers Stripe returns) are kept for as long as tax and accounting law requires, up to 7 years after the transaction.
• Support conversations (messages, replies and attachments sent to our support and contact addresses) are kept for up to 24 months after the last message, unless you ask us to delete them sooner.

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. Users above that age but under 18 should use the Services only with any consent their local law requires, and should not store sensitive personal information in them.

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, and we will give additional notice where the law requires it.

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, except the sub-processor list in 11.6, which also covers the chat on our documentation site.

In ChatGPT, Mnemoverse is either a developer-mode app that uses our remote MCP connector, or a Custom GPT whose Actions call our REST API with your Mnemoverse API key. Either way this section applies to what reaches us. Which tools each host gets is listed on Where each tool works.

11.1 What the Memory API stores and retrieves

The MCP surface covered here includes six core memory tools, four Shared Rooms tools, and one Vault tool. 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 (items). Each result carries its memory_id (the identifier used to rate or manage that memory), content, domain, created_at (when it was created, where known) and, where recorded, author (the identity of the agent that wrote it, never the human account holder).	The query is not persisted as a memory atom. The service keeps usage statistics for the memories a search considers, which it uses to improve ranking. The query text and its embedding may be kept briefly while the service runs; they are not written to storage.
memory_list_recent	List the newest memories first, no search query; optionally filtered by domain and a since/until time window, paged with a cursor. Each entry (items) carries the same fields as a memory_read result, and next_cursor is the cursor for the next (older) page.	Nothing new. A read-only listing query — unlike memory_read, it does not update usage statistics.
memory_stats	Return counts and aggregates over your stored memories: memory_count (the number of saved memories), domains (your memory domains), episodes (the number of individual memories), prototypes (the number of summary memories), hebbian_edges (the number of concept-to-concept associations), avg_valence (the average valence of stored memories, from -1 to 1) and avg_importance (their average importance, from 0 to 1).	Nothing new.
memory_graph	Return the associations the memory has formed around the concepts you name. Each concept in the result (nodes) carries its name (concept) and degree (the number of returned associations that touch it); each association (edges) carries the two concepts it links (source, target), its weight (its strength), valence (its outcome polarity, from -1 to 1), count (a co-activation count) and updated_at (when the association was last updated). truncated says whether a server cap or limit cut the result short, and min_weight_applied gives the weight floor actually used.	Nothing new. A read-only query.
memory_write	Create a new memory atom from the content and optional metadata (concepts, domain) you supply. Returns stored (whether the memory was stored), memory_id (the stored memory's identifier, or null when it was not stored) and, where the service sends them, importance (an approximate novelty score for the write, from 0 to 1) and reason (the service's own explanation of the outcome, such as why a memory was not stored).	The atom: content, concepts, domain, timestamp, and the user/project identifiers that scope it. Every write also records authorship provenance: which account, and which agent or environment, created the atom. In a room, other members can see and filter on it. May be filtered by our write gate (novelty check) and reported back as not stored (stored: false) if below threshold, rather than silently dropped; never overwrites or deletes an existing atom.
memory_feedback	Record whether one or more existing atoms you can access were helpful — your own atoms, or atoms in a room where you hold read-write membership. Returns updated_count (the number of memories the service reports the rating applied to), avg_valence (the average valence of the rated memories after the update) and coactivation_edges (the number of concept associations the rating changed); when the service processes a rating later, these values are its acknowledgement, not the final result.	The updated rating (valence) of the targeted atoms and a count of ratings received, and the ranking data those ratings feed.
memory_create_room	Create an empty shared-memory room. Returns its room_id, its address (xroom:<id>, used as domain on other calls) and its name.	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. Returns the code, its scope and expires_at, the room's room_address, and join_url and share_message — an invite link and a ready-to-send message, both carrying the invite code; the message also names the room.	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. Returns the room's room_id, address and name, your scope in it, already_member (true if you were already a member) and next_steps (how to use the room now).	A room-membership record, updated invite redemption state, and a short notice in the room, visible to its members, that a new participant joined.
memory_list_rooms	List the rooms you own or have joined. Each entry (rooms) carries the room's room_id, name and address (for use as domain on other calls), your role (owner or member) and scope (read or read-write), and whether it is archived.	Nothing new. A read-only listing query.
vault_list	List the secrets in your Mnemoverse Vault. Each entry (secrets) carries the secret's alias, its context (its purpose) and its concepts (concept tags).	Nothing new. A read-only listing query; the secret's stored value is never returned by this tool or any other on this server.

Where the table names a field a tool returns, it uses the name that field has in the tool's structured result.

Besides the tools, the server offers one read-only resource, memory://item/{memory_id}. It opens one memory in your own store by its memory_id and returns only that memory's memory_id, content and domain. It stores nothing new.

To rank and manage memories, the service derives values from what you store: embeddings, concepts, similarity and relevance scores, importance and rating signals, and associations between concepts. Some tools return part of them, such as the aggregates memory_stats returns and the concept associations memory_graph returns; the table above lists what each tool returns. Section 11.4 says when they are deleted.

Tool descriptions match the intended server effects. A read does not create, overwrite, or delete memory content; it updates the usage statistics 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), and we do not request your chat history, your files, or the client's own memory. The client decides what to send us via the operations above; beyond sign-in and the technical data in section 1, we receive only the arguments of the tool calls it makes, and 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.

Memory content may contain personal data you choose to provide. The Memory API does not need, and you should not store as memory content or send as a search query, passwords, API keys, payment-card data, MFA codes, government identifiers, health information, or other highly sensitive data. Secrets you keep in the Vault (11.1) are the exception.

11.3 The OAuth connect flow

When you connect a Mnemoverse MCP connector to a client (e.g. Claude "Add connector" or a developer-mode app in ChatGPT), 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. Tokens issued to a connector expire on our side at a fixed time: an authorization code ten minutes after it is issued, an access token one hour after it is issued, and a refresh token 30 days after it is issued (each refresh issues a new one, so the 30 days count from the client's last refresh). A browser sign-in session on our authorization server ends 30 days after it was last renewed; using it renews it at most once a day.

To disconnect one connector, remove it in the client's connector settings; the tokens already issued to it then expire as described above. The Mnemoverse console has no control that revokes a single connector today.

To disconnect every connected app at once, reset your password through the console and tick Also disconnect all connected apps on the reset page. The refresh tokens issued to your connected apps are then deleted, so no app can obtain a new access token, and each app loses access when its current access token expires, within an hour. The page tells you whether the disconnect succeeded. You reconnect the apps you still use from their own settings. A password reset without that choice does not disconnect connected apps. Neither choice revokes API keys, including the key an editor extension receives when you connect it through the console; revoke those on the console's API Keys page.

11.4 Retention

• Private memory atoms are retained until you delete them (via the REST API delete endpoints or an account-deletion request — see 11.5). We do not auto-expire private atoms based on age.
• What belongs to the account as a whole is retained until the account is deleted. Deleting a memory or a domain removes those atoms with their embeddings and their own ranking signals, but not the associations learned between concepts or the log of ratings (memory_feedback), and neither delete endpoint removes Vault secrets. Account deletion removes all three (11.5).
• 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 the lifetimes given in 11.3. After you disconnect a connector in the client, the tokens issued to it expire as described there. Refresh tokens are deleted before they expire when you reset your password and choose to disconnect connected apps (11.3), and your OAuth state is deleted as part of an account-deletion request (11.5).
• Operational logs record request metadata and internal identifiers, not memory content or query text. They are held by our hosting 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 the REST API 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: you delete atoms and domains yourself through the REST API, with immediate effect, 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. There is no delete control in the console today: memories and domains are deleted through the REST API, and the whole account by a request to support.

• Per-atom deletion — available via the REST API (DELETE /memory/atoms/{id}) as an administrative operation. It is not exposed as an MCP tool call from your client. If a stored fact is simply wrong rather than something you want forgotten outright, writing a corrected memory is the better fix — see the API reference for the delete endpoint's exact behavior. Deletion itself is irreversible.
• Domain-level deletion — available via the REST API (DELETE /memory/domain/{domain}) as an administrative operation. It is not exposed as an MCP tool call from your client. Removes every atom tagged with that private domain except Vault secrets, which it skips and reports as skipped. It does not act on shared room (xroom:) domains — room-content deletion is support-assisted (see 11.8). Irreversible.
• Disconnecting a connector — affects client access and leaves your atoms untouched. To disconnect one client, remove the connector in the client's connector settings; the tokens already issued to it expire on our side as described in 11.3. To disconnect every connected app at once, choose that option when you reset your password through the console (11.3).
• Account deletion — email support@mnemoverse.com from the address on the account. We delete the account record, your private account-owned atoms (Vault secrets included), the account's concept associations and rating log, 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, the remote MCP server, your account, billing, the email we exchange with you, and the chat on our documentation site. We assess their security and data-protection posture before use and when material processing changes.

Provider	What it does for us	Location
Railway	Hosts the Memory API, its database, and the remote MCP server	Netherlands (EU)
Neon	Database for accounts, authorization and the chat on our documentation site	United States
Prisma Data Platform	Connection proxy for the accounts database	United States
Cloudflare	Network edge, sign-in and the console	United States (global network); console database and files in Western Europe
OpenAI or NVIDIA	Computes embeddings; receives the text of memories and search queries. We use one of the two at a time. OpenAI also verifies review findings in Sigma (section 12) and receives source and review context for that.	United States
Anthropic	Answers questions in the chat on our documentation site; receives what you type there. Also produces review findings in Sigma (section 12) and receives source and review context for that.	United States
Scaleway	Hosts the Sigma review server (section 12)	European Union
GitHub	Sigma reads pull requests from, and posts reviews and checks to, the repositories a team connects (section 12)	United States
Stripe	Payments	United States
Resend	Transactional and service email (section 3), and the contact list for service emails	United States
Fastmail and Apple	Email hosting for the messages you send us	Netherlands and United States
Axiom	Logs and error monitoring	United States

Third parties you choose. These are not sub-processors we appoint. Each processes data under its own terms and privacy policy, and only when you use it.

• Your AI client. The MCP client you connect, such as Claude (Anthropic), ChatGPT (OpenAI), or Cursor, sends us your tool calls and receives their results.
• Google or GitHub sign-in. If you sign in with Google or GitHub, that provider confirms your identity and shares your name, email address, and profile picture with us.
• Digital wallets. If you pay with a digital wallet at Stripe checkout, the wallet provider handles that payment with Stripe.

OpenAI and Anthropic can each appear in both places: in the table above, and as the provider of ChatGPT or Claude if you connect it.

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. The table above gives each provider's location; the safeguard that applies to each transfer 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. The invite link (join_url) and ready-to-send message (share_message) returned with a share code both carry that code, and the message also names the room, so anyone who receives either can use the code to join, with the scope it grants, until it expires or reaches its use limit. 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 Aggregate structural analytics

To operate, secure, and improve the service, we compute aggregate, content-free structural statistics over the data the Memory API stores on your behalf — for example, counts of memory atoms and concept-graph edges, degree and edge-weight distributions, and usage aggregates by tenant class. These analyses read structure, never content: they never read or quote the text of your memories.

We may publish such statistics in technical reports or research publications. Anything published is limited to class-level aggregates or structure-only statistics under pseudonymous tenant identifiers — never memory content, never plaintext account identifiers, and never calendar dates of an individual tenant's activity.

11.10 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.

12. Sigma (closed beta)

Sigma is our pull-request reviewer for GitHub, in closed beta at sigma.mnemoverse.com. This section applies when you request beta access, accept an invitation, or connect a repository. If you do neither, section 12 does not apply to you.

12.1 What Sigma processes

• Beta request form: the email address, GitHub login, project description and website you enter. We use them to answer your request and to issue an invitation. A request does not grant access by itself.
• Sign-in and installation: the GitHub account id of the person who signs in with an invitation, and the installation id of the GitHub App on the accounts the invitation names.
• Repositories you connect: for each pull request Sigma reviews, the exact head and base commits fetched by SHA, the pull request's title, description and the comments addressed to Sigma, and the GitHub identities of the people who write them. Sigma never pushes to, merges or edits your code.
• Run records: findings, stages, scope notes, token-derived cost records and the snapshot and dependency artifacts of each review. What a run keeps and what leaves the host is described in the Sigma documentation, What Sigma does with your code.

12.2 Where it runs and who receives data

Reviews run inside disposable containers on a server we rent from Scaleway in the European Union. Model requests carrying source and review context go to Anthropic and OpenAI, whose API terms do not use those inputs to train their models by default. Reviews and checks are posted back to GitHub. The beta request form is received by our console, whose database is in Western Europe (section 11.6).

12.3 Retention and deletion

The Sigma documentation states what is kept and for how long, on the page linked in 12.1; that page is the single source for the Sigma retention period, and it changes before anything in this policy would. To stop reviews, set a repository's reviewers to Off or disconnect it; to remove Sigma from an account, uninstall the GitHub App in that account's settings. To have your Sigma data deleted, write to us through the contact in section 10: we confirm the request and the deletion in writing.

Related

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