Mycelium2

A self-hosted memory, book, and skills server for AI agents, written in Rust and exposed over the Model Context Protocol (MCP).

Mycelium2 is built on two assumptions:

1. The database is untrusted at rest. A leaked database must not yield plaintext, a usable session, an API key, or a second-factor secret.
2. The model is untrusted. The LLM proposes changes to memory; code decides what is allowed, where it lands, and whether it worked.

It is a ground-up rewrite of Mycelium that keeps the Open Knowledge Format (OKF) memory model and adds per-user encrypted stores, user authentication, shared bookshelves, and a skills store.

Status

In active development. The crypto, storage, authentication, MCP, and librarian layers are implemented and covered by 250+ tests. The web interface works and is being improved; expect it to change.

What it does

• Agent memory. Agents store and query knowledge as markdown concepts with YAML frontmatter, cross-linked into a graph. Each user has a private, encrypted bundle.
• Bookshelves. An administrator uploads books; a librarian catalogs them into chapters and sections that agents can search and read by passage.
• Skills store. Agents fetch skills (SKILL.md-style markdown) by name: private skills per user and administrator-managed global skills, with installable bundles (zip download / CLI export).
• MCP server. Seven tools over Streamable HTTP at /mcp, authenticated per user.
• Web interface. Bundle browser, concept editor, search, graph view, chat, and an admin portal.

Security model

Encryption

Every concept file and every search index entry is encrypted. Nothing a user stores is written in plaintext.

password ──Argon2id──▶ KEK ──unseals──▶ master key ──HKDF-SHA256──▶ per-file DEK ──AES-256-GCM──▶ file

• Per-file keys. Each file is encrypted under its own key, derived from the user’s master key and bound to the file it protects.
• Two-layer envelopes. The outer layer is bound to the stored filename, so a file swapped under a known name fails to decrypt. The inner layer carries the true path, checked on read, so a file copied to another name fails too.
• No path leakage. Files are stored under flat, opaque HMAC filenames, so concept names and paths are not visible on disk.
• Encrypted search. Index terms are HMAC-SHA256 tokens under a per-scope key, and document payloads are AEAD envelopes. Search terms never reach the database in plaintext.
• Cheap password changes. Changing a password re-wraps the master key. File ciphertext is untouched.
• Recovery key. Generated at account creation and shown once. It unseals the master key if the password is lost.
• Key types that can’t be mixed. MasterKey, Kek, Dek, RecoveryKey, and ServiceKey are distinct types, so using one in place of another is a compile error. Their debug output is redacted.