Isolation
Accounts, projects and workspaces are isolated. Inside an organization, visibility rules are enforced in SQL.
On this page you will learn:
- how MMW keeps your memory apart from everyone else’s;
- how keys are stored and what protects records from secrets;
- what goes into logs and backups.
In short
Section titled “In short”Keys are hashes only
A key is shown once; the server stores a PBKDF2 hash and an index.
Memory Guard
Secrets are removed before storage; dangerous records are rejected.
Logs without content
The MCP log and the organization audit log never contain record text.
Data isolation
Section titled “Data isolation”Every request to MMW runs on behalf of a key, and a key belongs to one space — personal or an organization — and, if bound, one project. The server searches and writes only within that space and project.
Inside an organization, visibility rules apply as well: the access condition is built into the SQL query itself on every read path — search, validation, deletion, graph relations, the account and the archivist. A record you are not allowed to see appears neither in results nor in counts.
The server is stateless: every request is checked on its own, from scratch.
Keys and sign-in
Section titled “Keys and sign-in”- An
mmw_…key is shown once. The server keeps only a PBKDF2 hash and a lookup index; the key cannot be recovered from the hash. - Revoking a key takes effect immediately.
- The key travels in the
Authorizationheader, never in the request URL. - claude.ai and ChatGPT connect over OAuth and get their own 30-day token — your key is not shared with them. See API keys and OAuth.
- In an organization, the admin sees and revokes members’ keys but can never reveal or reissue them.
Memory Guard
Section titled “Memory Guard”Memory Guard checks every record before it is stored:
- API keys, tokens and passwords are removed from the record;
- a record that looks like an attempt to plant instructions in the agent’s memory (“memory poisoning”) is rejected with
Memory rejected by Security Guard: ….
Session history, if you turned it on, is cleaned of secrets twice: on your computer before upload and again on the server. Model reasoning, system prompts, file snapshots and paths are not sent.
Data in transit and processing
Section titled “Data in transit and processing”All MMW addresses — the account and the memory server https://mcp.mmwhub.tech/mcp — use HTTPS.
Every new record is analyzed by the archivist: a language model provider links it to related records and marks outdated ones. The model receives the record text after secrets are removed. Do not store personal data of other people in memory if you do not want it processed this way.
Messages to the MMW Telegram bot pass through a relay server that only forwards them and neither stores nor logs their text. Whatever you ask the bot to save is stored in your MMW memory like any other record.
| Log | Contains | Does not contain |
|---|---|---|
| MCP operations | Time, tool, call outcome | Record text |
Integration calls (gateway_call) | Time, tool, outcome, latency | Arguments and integration responses |
| Organization audit log | Offboarding, reads of handed-over knowledge, visibility and term changes | Record text |
| Account actions | IP address, browser, time and type of request, email at sign-up and sign-in; kept 3 years | Passwords, keys, memory content |
| Web server logs | Requests to the site; kept 1 year | Passwords, keys, memory content |
Backups
Section titled “Backups”| Details | |
|---|---|
| Schedule | Nightly, compressed |
| Retention | The last 7 copies plus an off-server copy |
| System data: account, payments, keys, projects | Every plan |
| Content: records and sessions | Paid plans — Starter, Pro, Enterprise — and organizations |
What you can do yourself
Section titled “What you can do yourself”- Keep your key in a password manager, not in chats, tickets, Git or screenshots.
- In an organization, issue a separate key per device (for example “work laptop”) so a leaked key can be revoked without stopping the others.
- Bind keys to projects so an agent sees only the memory it needs.
- In an organization, give every person their own key: a shared key breaks record authorship and knowledge handover.
Next steps
Section titled “Next steps” Memory Guard What exactly is removed or rejected.
Data and deletion What is stored, for how long, and how to delete it.
API keys and OAuth Revealing, rotating and revoking keys.
Visibility in organizations Access rules inside a company.