Enigma whitepaper

Abstract

Enigma is provider-neutral AI memory/proof infrastructure. It gives users, developers, and enterprises a canonical memory vault, a portable Memory Passport, scoped context delivery into AI clients, and signed receipts for Enigma-mediated memory lifecycle and boundary events.

AI is becoming stateful. Assistants now remember preferences, projects, identities, workflows, and tool results. But most AI memory is trapped inside provider accounts, app-specific stores, vector databases, and opaque agent traces. Users lose continuity when they switch tools. Developers rebuild memory and audit primitives for every agent. Enterprises struggle to use durable AI memory while proving policy, retention, residency, deletion workflow, and provider-boundary decisions.

Enigma addresses that gap by separating durable memory custody from model providers. Memory can live in a local-first or customer-controlled vault. AI clients receive only scoped context capsules. Every meaningful Enigma-side operation can emit a receipt: a signed, hash-linked, offline-verifiable record of what Enigma did under a declared policy boundary.

Enigma does not claim to make providers forget, delete model weights, remove every external copy, prove factual truth, prove semantic-paraphrase absence, or eliminate all side channels. Its proof model is narrower and more useful: receipts verify declared Enigma-mediated operations, committed state, gateway decisions, relay records, witness checkpoints, and verifier outcomes.

An optional relay/witness/gateway network can extend Enigma beyond local use. Relays route encrypted capsules. Witnesses checkpoint opaque roots. Gateways enforce policy and meter access. Enigma uses no token and no blockchain: local memory, MCP workflows, and offline verification are fully useful on their own, and the optional network is coordinated through ordinary authenticated service infrastructure.

1. Market problem

1.1 AI memory is becoming infrastructure

The first wave of AI products centered on prompt-response sessions. The next wave is stateful: agents remember the user, project, organization, tools, preferences, permissions, prior outputs, and long-running tasks.

Durable memory is becoming the connective tissue between models, applications, agents, and workflows. If that memory is fragmented or opaque, the user's relationship with AI becomes fragile. If it is trapped in one provider, the user loses portability. If it is not auditable, enterprises cannot govern it. If deletion claims exceed what can be proven, trust degrades.

1.2 Current memory systems are fragmented

AI memory today often lives in one of several places:

• provider-native memory inside a subscription or hosted model account;
• chat history or workspace history;
• application-specific databases;
• vector stores and retrieval pipelines;
• agent framework state;
• logs, traces, observability backends, and tool-call records;
• manually exported JSON, CSV, or archive files.

Each can be useful. None is a neutral, portable, proof-carrying memory layer by default.

1.3 Users need portability

A user may work across ChatGPT, Claude, Kimi, Cursor, local models, browser tools, command-line agents, and future assistants. The useful context is not tied to one vendor: writing style, project constraints, codebase facts, research trails, preferences, contacts, workflows, and repeated instructions should travel with the user or tenant.

Without a portable memory layer, users choose between losing continuity and surrendering the durable system of record to a single provider.

1.4 Developers need memory primitives

Developers building agents repeatedly solve the same problems:

• how to store memory;
• how to retrieve only relevant context;
• how to import/export memory;
• how to respect source permissions;
• how to tombstone or delete from active serving state;
• how to prove what was used;
• how to debug memory boundaries;
• how to explain trust to users and auditors.

A provider-neutral memory/proof layer lets developers integrate memory once and use it across clients, models, and deployment modes.

1.5 Enterprises need control and evidence

Enterprise AI programs need durable memory, but they also need governance. Security, legal, compliance, and AI platform teams ask practical questions:

• Which memory was retrieved?
• Which policy allowed it?
• Which provider, model, region, purpose, and sensitivity applied?
• Was the memory excluded after a tombstone or legal hold?
• Which key version, tenant, gateway, or boundary handled the request?
• Can the evidence be verified without trusting a dashboard?

Provider-native memory can be useful, but it is rarely enough as the enterprise system of record. Enigma's enterprise posture is to keep durable memory under local, tenant, BYOC, VPC, or on-prem control while sending providers only scoped context.

2. Enigma overview

Enigma is a memory custody and proof layer beneath AI applications.

The core sequence is:

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

2.1 Design goals

Enigma is designed to be:

1. Provider-neutral: usable across model providers, local models, AI apps, and agent frameworks.
2. Local-first: able to run with a local vault and local verification path.
3. Portable: able to package memory and proof material into Memory Passports and Capsules.
4. Verifiable: able to produce receipts that verify offline.
5. Policy-aware: able to bind memory use to purpose, subject, tenant, sensitivity, region, provider, model, and gateway decisions.
6. Plaintext-minimizing: able to keep raw memory out of relay records, witness checkpoints, SIEM events, and public proof artifacts.
7. Honest: explicit about what Enigma can and cannot prove.

2.2 Definitions

3. Architecture

3.1 Local vault

The vault is the canonical memory state for local use. It can be created from the command line:

enigma init --bundle ./.enigma/bundle.json --subject local-user --display-name "Local user"

A local memory write:

enigma remember --bundle ./.enigma/bundle.json --text "Prefers concise release notes." --purpose user_memory --tags preference

A context pack for a query:

enigma context --bundle ./.enigma/bundle.json --query "release notes" --purpose local_answer --out ./.enigma/context-pack.json

Export and verify:

enigma export --bundle ./.enigma/bundle.json --out ./.enigma/export.json
enigma verify --bundle ./.enigma/export.json

The local bundle is the system of record for the local path. Provider-native memory should be treated as cache unless independently committed into an Enigma vault.

3.2 Connectors and client surfaces

Enigma exposes memory through multiple surfaces:

• CLI commands;
• MCP server;
• connector profiles for Claude Desktop, Cursor, Kimi Code, VS Code/Cline, Roo Code, OpenCode, and generic MCP;
• browser extension scaffold for explicit user-approved context insertion;
• desktop scaffold for vault, clients, receipts, import/export, deletion workflow, mesh, and enterprise screens;
• relay and gateway servers for optional network and enterprise modes.

The current MCP server exposes tools such as enigma_init, enigma_remember, enigma_search, enigma_context_pack, enigma_delete, and enigma_verify_receipts, plus the enigma://passport/summary resource and enigma_standard_memory_prompt prompt.

3.2.1 Memory optimization and receipts

Enigma's optimizer is not a generic "always cheaper" claim. The public benchmark command emits enigma.memory_optimization_benchmark.v1 and enigma.memory_strategy_comparison.v1, comparing full-context unverified recall, deduped unreceipted recall, and the Enigma receipted plan on a repository fixture. The comparison is evidence-bounded: estimated token reduction is local fixture evidence only, not provider invoice savings or a universal discount guarantee.

3.3 Policy and boundary layer

The policy layer determines whether memory can be retrieved, packed, injected, denied, exported, tombstoned, relayed, witnessed, or passed through a gateway. Policies may account for:

• user, subject, tenant, and controller;
• purpose and workflow;
• provider and model;
• region and residency;
• sensitivity and classification;
• source permissions and ACL references;
• key version and custody mode;
• legal hold or retention state;
• gateway mode and deployment boundary.

Policy decisions should produce receipts or be referenced by receipts through policy hashes and version identifiers.

3.4 Receipts and proof bundle

Receipts are the proof primitive. A proof bundle can contain:

• receipt records;
• schema identifiers;
• signature metadata;
• event hashes;
• previous receipt hashes;
• state roots;
• membership or non-membership evidence where implemented;
• tombstone evidence;
• gateway decision data;
• relay record IDs;
• witness checkpoint data;
• verifier input and output metadata;
• explicit claim boundaries.

The bundle should avoid raw plaintext in public or network-facing contexts. Sensitive content should remain encrypted, redacted, committed, or locally held depending on the deployment mode.

4. Memory Passport

4.1 Purpose

The Memory Passport is the user- and tenant-facing portability artifact. It packages durable context and proof material so memory can move across AI clients without making a provider account the canonical store.

A Memory Passport is not a public profile and not a blockchain object. It is a controlled package whose contents and disclosure depend on custody mode, encryption, policy, and recipient.

4.2 Contents

A Memory Passport may include:

• encrypted memory payloads;
• memory IDs and addresses;
• subject and controller metadata;
• tags, purpose, source references, and limitations;
• policy references;
• tombstone records;
• receipt chains;
• verifier summaries;
• import provenance;
• export metadata;
• optional checkpoint references.

4.3 Lifecycle

Typical lifecycle events include:

1. Initialize: create vault and passport identity.
2. Import: normalize source memory exports into candidates with source limitations.
3. Commit: write selected candidates to Enigma vault state.
4. Retrieve: select memories under purpose and policy constraints.
5. Pack: generate scoped context for a client/model/tool call.
6. Inject or deny: cross or block a declared boundary.
7. Update: revise metadata or memory state under policy.
8. Export: produce a portable proof bundle.
9. Tombstone: remove from active Enigma serving state while preserving lifecycle evidence.
10. Verify: check receipts and proof material offline.

4.4 Import limits

Enigma can import or normalize memory exports from other systems, but an import is only as complete as the source export. Enigma must preserve source limitations. A provider export does not prove provider-side completeness unless the source independently proves it.

Imported memory becomes Enigma-canonical only after it is committed through an Enigma vault and receives Enigma receipts.

5. Receipt and proof protocol

5.1 Receipt objective

A receipt should answer: what Enigma-mediated event happened, under which declared boundary, at which position in the receipt chain, against which committed state, under which policy, and with which signature?

A receipt should not claim more than that.

5.2 Receipt fields

A professional public schema should include, at minimum:

• schema name and version;
• receipt ID;
• event type;
• event timestamp or logical sequence;
• subject, tenant, or controller reference, when appropriate;
• memory ID/address or redacted commitment;
• purpose and sensitivity metadata;
• policy hash and policy version;
• previous receipt hash;
• event hash;
• state root or checkpoint root;
• signer identity and signature;
• key version or signing authority reference;
• boundary metadata such as provider, model, tool, region, gateway, relay, or witness;
• explicit proof boundary statement;
• verifier status or required verifier inputs.

5.3 Event types

Recommended receipt event types, board/legal-review required for public schema naming:

• vault.initialized
• memory.import_candidate.created
• memory.created
• memory.retrieved
• context_pack.created
• boundary.injected
• boundary.denied
• memory.updated
• memory.exported
• memory.tombstoned
• delete_request.recorded
• relay.record_pushed
• witness.checkpoint_signed
• gateway.decision_signed
• verifier.bundle_verified
• verifier.bundle_failed

The final public names should be stable before external integrations depend on them.

5.4 Canonicalization

Receipts should be serialized and hashed canonically. The goal is deterministic verification across machines and time. Canonicalization should define:

• field order or canonical encoding;
• Unicode handling;
• timestamp format;
• domain-separated hash tags;
• redaction and commitment rules;
• signature input bytes;
• schema upgrade behavior;
• backward-compatible verifier behavior.

5.5 Ordering

Receipts should be ordered with hash links and/or state roots. A verifier should be able to detect:

• missing receipts;
• broken hash links;
• signature mismatch;
• schema mismatch;
• policy hash mismatch;
• receipt replay outside declared context;
• attempted mutation of a committed field;
• inconsistent tombstone state.

5.6 Offline verification

Offline verification is a core product promise. A verifier should not need to contact Enigma servers or model providers to check a self-contained proof bundle.

Local verification command:

enigma verify --bundle ./.enigma/export.json

A valid verification result can support statements about Enigma-controlled state and Enigma-mediated events. It cannot establish external-provider deletion, model forgetting, truth of memory content, or absence of all side channels.

5.7 Failure states

Verification failure should be explicit and useful. Failure reasons may include:

• invalid schema;
• unsupported schema version;
• missing required field;
• invalid signature;
• unknown signing authority;
• hash-chain break;
• state-root mismatch;
• policy mismatch;
• tombstone contradiction;
• relay/witness checkpoint mismatch;
• expired or revoked key reference;
• malformed redaction or commitment;
• unsupported extension or future feature.

6. MCP installability

MCP is the shortest path to putting Enigma memory into existing AI workflows. The client starts enigma-mcp over stdio and points it at a local bundle.

Run the MCP server:

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

CLI equivalent:

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

Generic MCP client configuration:

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

Connector commands:

enigma doctor
enigma install --bundle "$HOME/.enigma/bundle.json"
enigma connect claude-desktop --bundle "$HOME/.enigma/bundle.json"
enigma disconnect claude-desktop

MCP lets Enigma be infrastructure rather than a destination app. The AI client can ask for memory; Enigma can search, pack, and receipt; the model receives only scoped context.

7. Decentralized relay/witness/gateway network

7.1 Network role

The network layer is optional. Local vaults and offline verification should work without it. The network exists for cases where users, teams, developers, or enterprises want encrypted sync, shared checkpointing, gateway access, operator coordination, and public accountability of opaque proof roots.

The network must not become a plaintext memory database. Raw memories, prompts, transcripts, embeddings, ACLs, and personal metadata should never be exposed outside the encrypted boundary.

7.2 Relay

A relay stores or routes opaque encrypted records. It should not receive raw memory fields. The local relay path:

enigma relay demo
enigma relay serve --host 127.0.0.1 --port 8787

Example relay health check and opaque push:

curl http://127.0.0.1:8787/health
curl -X POST http://127.0.0.1:8787/relay/push \
  -H 'content-type: application/json' \
  --data '{"capsule_id":"cap_local_1","opaque_encrypted_record":"age1-example-ciphertext-only"}'

Relay records should contain encrypted payloads, commitments, record IDs, expiry or retention metadata, and routing metadata necessary for service. They should reject plaintext-looking memory fields.

7.3 Witness

A witness attests compact proof material:

• receipt IDs;
• state roots;
• Merkle roots;
• operator IDs;
• policy or schema versions;
• checkpoint sequence;
• timestamp or slot context;
• quorum membership.

Witnesses should not see plaintext memory. Their role is to make later equivocation, omission, or mutation harder by signing compact commitments.

7.4 Gateway

A gateway enforces policy and signs decisions before memory crosses a model, tool, region, tenant, or network boundary. The local gateway path:

enigma gateway demo
enigma gateway serve --host 127.0.0.1 --port 8797

Health, policy, decision, and SIEM export:

curl http://127.0.0.1:8797/health
curl http://127.0.0.1:8797/policy
curl -X POST http://127.0.0.1:8797/gateway/decision \
  -H 'content-type: application/json' \
  --data '{"schema":"enigma.gateway_request.v1","operation":"retrieve","provider":"kimi","model":"kimi-k2","region":"us-east-1","purpose":"support_retrieval","sensitivity":"internal","memory_addr":"addr_committed_memory","memory_id":"mem_allowed","subject_id":"employee_123"}'
curl http://127.0.0.1:8797/siem/export

The gateway does not call model providers in the documented local path. It evaluates Enigma policy and emits signed decisions.

7.5 Network service units

Recommended draft service units, board/legal-review required:

• relay write;
• relay byte-period;
• relay retrieval/egress;
• witness checkpoint signature;
• witness quorum batch;
• gateway policy decision;
• proof anchoring batch;
• verifier challenge submission;
• priority routing job.

Service units should be defined operationally, not by external trading metrics.

8. Enterprise control plane

8.1 Deployment modes

Enigma supports several deployment patterns:

• Local: individual or developer runs vault, CLI, MCP, and verifier locally.
• Team: shared team processes and connectors with controlled bundle paths and policy.
• Hosted: Enigma operator runs relay/gateway for a tenant. This requires deployment credentials, domain, TLS, durable storage, KMS/secrets, monitoring, backups, and incident response.
• BYOC: customer runs relay/gateway in its own cloud or network. Customer controls KMS, network policy, logs, SIEM export, deployment credentials, and residency.
• On-prem or air-gapped: customer-controlled infrastructure with local verification and restricted egress.

8.2 Controls

Enterprise controls can include:

• tenant-scoped vaults;
• SSO/SCIM and RBAC;
• KMS/BYOK key references;
• provider, model, and region allowlists;
• purpose and sensitivity policies;
• ACL re-checks;
• legal hold and retention flags;
• deletion workflow and tombstone receipts;
• policy replay by hash/version;
• SIEM and eDiscovery exports with minimized plaintext;
• gateway-signed decisions;
• offline verifier packages for auditors.

8.3 Audit use cases

Enigma can support answers to questions such as:

• Was a memory in active Enigma serving state at a given time?
• Was a memory tombstoned before a later retrieval request?
• Which gateway policy allowed or denied a retrieval?
• Which provider, model, region, purpose, and sensitivity were declared?
• Which key version and policy hash were referenced?
• Did a proof bundle verify offline?

Enigma cannot independently answer whether a model provider retained hidden copies, whether a model's weights changed, or whether an external system deleted derived data unless that external system supplies independent evidence.

9. No token, no blockchain

Enigma is token-free, and stays that way. Local vaults, MCP workflows, context packs, and offline receipt verification require no token, no wallet, and no blockchain. The optional relay/witness/gateway network is coordinated through ordinary authenticated service infrastructure and standard billing (invoice, card, or usage-based) — never a token requirement and never a financial instrument. Raw memory, prompts, transcripts, embeddings, and personal metadata are never written to any public ledger; the network moves only opaque, encrypted records and compact commitments.

10. Roadmap

10.1 Shipped/current foundation

Current repository-facing foundation includes:

• CLI;
• verifier;
• vault and passport logic;
• boundary harness;
• MCP server;
• connector profiles;
• importer APIs;
• relay and gateway local servers;
• enterprise policy surfaces;
• mesh/network scaffolding;
• browser-extension scaffold;
• desktop scaffold;
• package command bins and module entry points for local install and publication work.

10.2 Near-term product priorities

Recommended near-term priorities:

1. publish package from approved deployment credentials;
2. stabilize receipt schemas and verifier outputs;
3. ship MCP quickstart and sample proof bundles;
4. harden connectors for supported clients;
5. package desktop and browser surfaces for normal users;
6. define enterprise pilot templates;
7. publish trust model and proof boundary docs;
8. prepare external security review.

10.3 Network priorities

Recommended network priorities:

1. define relay/witness/gateway service units;
2. publish operator role requirements;
3. test encrypted relay and witness checkpoints on controlled testnet infrastructure;
4. implement challenge and slashing rules only where objective evidence exists;
5. publish governance non-powers and authority maps;
6. publish schemas, conformance vectors, and verifier builds for each claim;
7. keep every public statement subordinate to verifiable proof.

10.4 Long-term direction

Longer-term Enigma can become a neutral standard layer for AI memory portability and evidence:

• Memory Passport compatibility across clients;
• open receipt schemas and verifier tooling;
• enterprise gateway deployment templates;
• partner adapters for memory engines and model gateways;
• witness networks for opaque checkpoint roots;
• developer certification and conformance fixtures;
• customer-controlled and hosted deployment modes.

11. Threat model

11.1 Protected assets

Enigma should protect:

• memory plaintext;
• vault keys and signing keys;
• receipt integrity;
• policy integrity;
• memory lifecycle state;
• tombstone state;
• gateway decision logs;
• relay encrypted records;
• witness checkpoint correctness;
• verifier trustworthiness;
• tenant, subject, and metadata confidentiality.

11.2 In-scope threats

In-scope threats include:

• local proof-bundle tampering;
• receipt mutation or deletion;
• hash-chain rewriting;
• invalid signature injection;
• replayed receipt in wrong context;
• stale policy use;
• relay plaintext leakage attempts;
• gateway policy bypass attempts;
• witness equivocation;
• operator misreporting;
• unauthorized memory retrieval;
• metadata overexposure in logs or checkpoints;
• accidental provider-native memory dependence.

11.3 Out-of-scope threats and non-guarantees

Enigma does not claim to solve:

• provider-internal retention, hidden memory, telemetry, training, fine-tuning, or cache behavior;
• model weight forgetting;
• deletion from screenshots, backups, external logs, users' devices, third-party exports, or human memory;
• factual truth of memory content;
• model intent or hidden reasoning;
• all side channels outside instrumented boundaries;
• compromise of an endpoint before Enigma can protect data;
• legal compliance as an automatic outcome.

11.4 Trust assumptions

Enigma assumes:

• users or tenants protect vault files and keys;
• deployed software matches the verified build or documented version;
• signing keys are controlled according to the disclosed authority model;
• policies are configured correctly;
• clients correctly launch the configured MCP server;
• relays and witnesses can fail or misbehave and should be checked by receipts, checkpoints, quorums, challenges, and audits;
• external providers are outside the Enigma proof boundary unless they supply independent evidence.

12. Risks

12.1 Technical risk

Receipt schemas can be incomplete, verifier implementations can have bugs, key management can fail, policies can be misconfigured, connectors can break as clients change, and network operators can become unavailable.

Mitigation: keep local verification simple, publish schemas and failure states, version policies, minimize plaintext, rotate keys carefully, and subject cryptographic and network code to review.

12.2 Privacy and metadata risk

Even hashes, commitments, timing, sizes, operator IDs, and policy metadata can leak information. Opaque does not mean risk-free.

Mitigation: minimize metadata, batch checkpoints, avoid raw memory in public artifacts, use encryption and redaction, and document what metadata each mode exposes.

12.3 Operational risk

Hosted relay/gateway operation requires durable storage, KMS/secrets, TLS, monitoring, backups, incident response, access controls, and tenant policy. Installing the package does not create a production cloud service.

Mitigation: separate local, hosted, BYOC, and on-prem modes; publish deployment requirements; avoid claiming hosted behavior until infrastructure is deployed.

12.4 Governance risk

Governance can fail, be captured, fail to reach quorum, or make poor parameter decisions.

Mitigation: bound governance powers, use timelocks, disclose emergency controls, protect private memory from governance reach, and publish transparency reports.

13. Honesty contract

Enigma's public trust depends on refusing impossible claims.

13.1 Enigma can honestly claim

• Enigma is provider-neutral AI memory/proof infrastructure.
• A local Enigma vault can be the canonical memory state for local workflows.
• Memory Passports can make AI context portable across Enigma-compatible clients and deployment modes.
• Enigma can emit receipts for Enigma-mediated memory lifecycle and boundary events.
• Receipt bundles can be verified offline where they contain the required proof material.
• Enigma can remove a memory from active Enigma serving state and preserve tombstone evidence.
• Gateway decisions can be signed against a specific policy hash and deployment boundary.
• Relays can store opaque encrypted records without raw memory plaintext.
• Witnesses can sign checkpoint roots without seeing raw memory.

13.2 Enigma must not claim

• that a closed provider deleted all internal data;
• that a model forgot weights, caches, training data, telemetry, hidden personalization, semantic paraphrases, or derived state;
• that provider-native memory disappeared unless the provider supplies independent evidence;
• that imported provider exports are complete unless the source proves completeness;
• that signed memory content is factually true;
• that all side channels are absent;
• that raw memory ever leaves your encrypted custody;
• that Enigma automatically creates compliance outcomes.

13.3 Standard proof boundary sentence

Receipts prove that declared Enigma-mediated operations were signed, ordered, and committed under a stated policy boundary; they do not prove factual truth, model intent, uninstrumented side-channel absence, or deletion from external systems unless those systems provide independent evidence.

14. Conclusion

AI needs durable memory, but durable memory should not mean provider lock-in, opaque state, or unverifiable claims. Enigma's thesis is that memory for AI should be portable, local-first or customer-controlled, provider-neutral, and proof-carrying.

The product starts with a practical loop: install locally, connect MCP, write memory, generate receipts, export a proof bundle, and verify offline. The broader system extends that loop through Memory Passports, enterprise gateways, encrypted relays, witness checkpoints, and optional network coordination.

Enigma's opportunity is not to be another chatbot or another vector database. It is to become the neutral memory/proof substrate beneath AI applications: the memory card for AI, with receipts that say exactly what happened and exactly what they do not prove.

Source links

Enigma local docs:

• ../README.md
• ../docs/install-anywhere.md
• ../docs/client-connectors.md
• ../docs/sandisk-scale-strategy.md