# Security

> How MMW isolates data, stores keys, protects memory from secrets and poisoning, what goes into logs and what goes into backups.

On this page you will learn:

1. how MMW keeps your memory apart from everyone else's;
2. how keys are stored and what protects records from secrets;
3. what goes into logs and backups.

## In short

  
    Accounts, projects and workspaces are isolated. Inside an organization, visibility rules are enforced in SQL.
  
  
    A key is shown once; the server stores a PBKDF2 hash and an index.
  
  
    Secrets are removed before storage; dangerous records are rejected.
  
  
    The MCP log and the organization audit log never contain record text.
  

## 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](/organizations/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

- 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 `Authorization` header, 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](/account/api-keys-and-oauth/).
- In an organization, the admin sees and revokes members' keys but can never reveal or reissue them.

## Memory Guard

[Memory Guard](/memory/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

All MMW addresses — the account and the memory server `https://mcp.mmwhub.tech/mcp` — use HTTPS.

Every new record is analyzed by the [archivist](/memory/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.

## Logs

| 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](/organizations/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

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

On the Free plan, memory content is not included in backups. If your records matter, move to a paid plan.

## 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