Enigma
Executive brief

Executive brief

Category, problem, product, and proof boundary.

Enigma · 2026 · open source · enigmamemory.com

Category

Enigma is provider-neutral AI memory/proof infrastructure.

The plain-language frame is simple: Enigma is the memory card for AI. It lets people and organizations carry context across AI clients without making one model provider, subscription app, or agent framework the durable system of record.

The technical category is Verifiable AI Memory Infrastructure: local-first or customer-controlled memory custody, portable Memory Passports, scoped context delivery, and signed receipts for Enigma-mediated memory lifecycle and boundary events.

The enterprise category is an auditable AI memory control plane: durable memory stays under user or tenant control; providers receive scoped context; admins and auditors receive verifiable evidence about the Enigma-side operations that occurred.

Problem

AI is moving from stateless prompts to long-running relationships with users, teams, tools, and agents. Those relationships require memory. Today that memory is fragmented and difficult to govern:

  • Provider lock-in: AI memory often lives inside one model provider, subscription app, IDE, vector store, or agent runtime.
  • Portability gap: Users and teams cannot reliably carry preferences, project context, working history, and durable instructions between AI tools.
  • Audit gap: Dashboards and logs describe events, but they are not usually portable, offline-verifiable evidence.
  • Deletion ambiguity: Removing a memory from one system does not prove provider-side deletion, model forgetting, derived-copy deletion, or absence from external logs.
  • Policy drift: Permissions, residency requirements, legal holds, and project scopes can change after memory was created.
  • Developer tax: Every agent stack must rebuild memory, retrieval, import/export, policy, receipts, and audit primitives.
  • Enterprise tension: Teams want durable AI memory and low-retention provider calls. That is hard when memory itself is stored inside provider accounts.

The market needs a neutral memory layer that sits beneath models and agents: portable for users, boring for developers, controllable for enterprises, and honest about what can and cannot be proven.

Product

Enigma gives users, developers, and enterprises a canonical memory vault plus proof layer.

Core product objects:

  • Vault: The local-first or customer-controlled canonical store for Enigma memory state.
  • Memory Passport: A portable, encrypted package of AI context and associated proof material that can move across clients and deployment modes.
  • Memory Capsule: A scoped, encrypted context package prepared for a defined workflow, subject, purpose, policy, or recipient.
  • Receipt: A signed, hash-linked, offline-verifiable record of an Enigma-mediated event such as create, import, retrieve, context-pack, inject, deny, update, export, tombstone, or delete request.
  • Verifier: Local tooling that checks proof bundles without requiring trust in an Enigma hosted service or AI provider dashboard.
  • Gateway: A policy enforcement layer for provider/model/tool/region/purpose decisions.
  • Relay: Optional infrastructure for storing or routing opaque encrypted records.
  • Witness: Optional infrastructure for checkpointing opaque roots and receipt/proof events without receiving raw memory.

The Enigma flow:

vault -> passport -> policy -> scoped retrieval -> context capsule -> model/tool boundary -> receipt -> verifier -> optional witness checkpoint

Enigma is not a foundation model, chatbot, vector database replacement, blockchain data store, or compliance guarantee. It can wrap, import from, export to, or sit beside existing memory engines and AI clients.

Market wedge

The wedge is MCP-installable local Memory Passport plus offline receipt verification.

A user or developer should be able to:

  1. install Enigma locally,
  2. create a vault,
  3. connect an MCP-capable client,
  4. write and retrieve memory,
  5. export a proof bundle, and
  6. verify receipts offline.

That sequence demonstrates the category in one loop: memory is portable, provider-neutral, locally controlled, and evidence-carrying.

Primary early audiences:

  • AI power users and creators: want continuity across ChatGPT, Claude, Kimi, Cursor, local models, and future AI workspaces.
  • Agent developers: want durable memory, scoped retrieval, and receipts without building a governance layer from scratch.
  • Enterprise AI teams: want controlled memory custody, provider-boundary evidence, policy replay, SIEM/eDiscovery support, and deployment options.
  • Memory engines and model gateways: can add proof-carrying portability instead of rebuilding receipt infrastructure.
  • Network operators and community: can support optional relay/witness/gateway infrastructure once public network rules are ready.

Go-to-market

Launch leads with product proof.

Recommended sequence:

  1. Category reveal: explain why AI memory needs portability and proof.
  2. Developer proof: show local install, MCP connection, receipt generation, and offline verification.
  3. Enterprise credibility: translate receipts into policy, audit, deletion workflow, residency, and boundary evidence.
  4. Network education: introduce optional relay/witness/gateway roles and utility/governance/access mechanics after the product proof loop is clear.

Primary CTAs:

  • Install Enigma locally.
  • Connect an MCP-capable AI client.
  • Create a first verifiable memory.
  • Export and verify a receipt offline.
  • Request an enterprise architecture review or pilot.
  • Learn network roles only after understanding product boundaries.

Current installability

Current status is local-first and repository-installable. Hosted cloud operation is not activated by installing the package; hosted relay/gateway operation requires deployment credentials, domain, TLS, durable storage, KMS/secrets, monitoring, backups, and operator policy.

From the repository:

cd enigma
npm install -g .
enigma --help

Local no-network vault path after the package or checkout is present:

enigma init --bundle ./.enigma/bundle.json --subject local-user --display-name "Local user"
enigma remember --bundle ./.enigma/bundle.json --text "Prefers concise release notes." --purpose user_memory --tags preference
enigma context --bundle ./.enigma/bundle.json --query "release notes" --purpose local_answer --out ./.enigma/context-pack.json
enigma export --bundle ./.enigma/bundle.json --out ./.enigma/export.json
enigma verify --bundle ./.enigma/export.json

MCP server:

ENIGMA_BUNDLE="$HOME/.enigma/bundle.json" enigma-mcp

CLI equivalent:

ENIGMA_BUNDLE="$HOME/.enigma/bundle.json" enigma mcp serve

Generic MCP configuration:

{
  "mcpServers": {
    "enigma": {
      "command": "enigma-mcp",
      "args": [],
      "env": {
        "ENIGMA_BUNDLE": "/absolute/path/to/.enigma/bundle.json"
      }
    }
  }
}

Supported connector profiles include Claude Desktop, Cursor, Kimi Code, VS Code/Cline, Roo Code, OpenCode, and generic MCP.

Proof boundary

Enigma's proof model is intentionally bounded.

Receipts can prove that declared Enigma-mediated operations were signed, ordered, and committed under stated policy and software boundaries. They can support evidence about Enigma vault state, memory lifecycle events, context-pack generation, gateway decisions, relay records, witness checkpoints, and verifier outcomes.

Receipts do not prove factual truth, model intent, internal provider behavior, complete side-channel absence, semantic-paraphrase absence, deletion from external systems, model-weight forgetting, provider-native memory deletion, or compliance outcomes by themselves.

That boundary is not a weakness; it is the source of trust. Enigma should be judged on precise, verifiable claims rather than broad promises that no AI memory system can honestly make.