# Security policy

## Reporting a vulnerability

If you find a security issue in memo, please **do not open a public issue**.
Instead, email <fernandoferrari@gmail.com> with:

- A description of the vulnerability
- Steps to reproduce (or a minimal proof-of-concept)
- The affected version (`memo --version`)
- The impact you observed

I aim to acknowledge reports within 7 days and ship a fix or mitigation
within 30 days for confirmed issues.

## Threat model

memo runs **entirely on your local machine**. On Apple Silicon, embeddings,
reranking, and chat happen in-process via MLX; on Linux/Intel macOS the CPU
backend supports save/search/recall without cloud calls. The data plane is plain
Markdown on disk plus local sqlite files. Concretely:

- **No cloud memory service.** The normal CLI/MCP path uses stdio, local files,
  and optional local Unix sockets for the recall/embedder daemons. `memo http-api`
  and HTTP MCP transport are opt-in localhost surfaces, not hosted services.
- **No telemetry.** memo emits no usage data.
- **No credentials.** memo does not request, store, or transmit API keys.

Reasonable threats memo aims to mitigate:

- A malicious `.md` file in the vault should not be able to execute code
  during indexing. (memo only parses YAML frontmatter and embeds plain
  text.)
- A malicious MCP client should not be able to escape the configured
  `MEMO_DATA_DIR` via path traversal.
- A malicious `memo://memory/{id}` resource URI should not return data
  outside the vault.

Out of scope:

- Whoever has write access to your `MEMO_DATA_DIR` can read and modify
  your memories. That is by design — the Markdown vault is the storage
  of record.
- Whoever can execute as your user can register an MCP client that talks
  to memo over stdio. memo trusts the caller.

## Supported versions

Only the latest minor release (currently the `2.12.x` line) receives security
fixes. Older releases will not be backported.
