The 0nVault Container System: Secure AI Brain Transfer Explained

Selling a business used to mean handing over a filing cabinet, a Rolodex, and a set of keys. Somewhere in the last decade, it became handing over a LastPass export, a Notion workspace invite, and seventeen separate login credentials over Slack DMs.

Neither method is secure. Neither is auditable. Neither preserves the operational intelligence — the automations, the AI configurations, the institutional knowledge — that actually makes a modern business run.

We built the 0nVault Container System to fix this. Patent Pending US #63/990,046.

The Problem: Business Operations Are Scattered and Insecure

A modern AI-native business has its operational intelligence spread across:

• API keys and credentials in .env files on someone's laptop
• Workflow automations in a CRM that can't be exported
• AI system prompts in a Notion doc
• MCP configurations in claude_desktop_config.json on the founder's machine
• Custom training data in a shared Google Drive folder
• Site profiles, OAuth tokens, and integration configs across 15 different dashboards

When this business is acquired, transferred to a new operator, or handed off to a team — the operational reality is a months-long process of manually reconstructing everything from memory. Critical context gets lost. Automations break. The new operator starts over.

0nVault Containers solve this by packaging everything into a single encrypted, integrity-verified, transferable file.

The Seven Semantic Layers

Every 0nVault container is organized into seven semantic layers. Each layer holds a specific category of operational data, and each layer can be independently encrypted with its own access permissions.

Layer 1: workflows

SWITCH files, automation definitions, and process logic. Every .0n workflow the business runs, serialized and encrypted. This is the operational brain — the automations that make the business run.

Layer 2: credentials

API keys, OAuth tokens, database connection strings, and service passwords. This is the most sensitive layer. It uses a separate encryption pass via Argon2id before being sealed with the container's master key.

Argon2id is the winner of the Password Hashing Competition. It's memory-hard (resistant to GPU/ASIC attacks), combines the side-channel resistance of Argon2i with the GPU attack resistance of Argon2d, and is the current OWASP recommendation for credential storage.

Double-encrypting credentials means that even if someone derives the container master key, the credential layer requires a second factor to unlock.

Layer 3: env_vars

Environment variables, feature flags, and runtime configuration. The non-secret but operationally critical configuration that services need to run correctly.

Layer 4: mcp_configs

MCP server configurations for every AI platform: Claude Desktop, Cursor, Windsurf, Gemini, Continue, Cline, OpenAI. Packaged as ready-to-deploy JSON that the recipient can drop directly into their AI toolchain.

Layer 5: site_profiles

Website configurations, DNS settings, deployment targets, Vercel/Netlify/Railway project references, domain registrar credentials. Everything needed to operate the business's digital presence.

Layer 6: ai_brain

System prompts, persona definitions, fine-tuning datasets, RAG document stores, knowledge base summaries. The AI-specific operational intelligence that took months to develop.

Layer 7: audit_trail

Complete chain of custody. Every transfer event, every access attempt, every seal verification. Immutable once written. This layer answers "who had this, when, and what did they do with it?"

The Cryptographic Architecture

Master Encryption: AES-256-GCM

The container master key uses AES-256-GCM — the same cipher used by the US National Security Agency for Top Secret classification. GCM (Galois/Counter Mode) provides both confidentiality and authentication: tampering with the ciphertext is detectable.

Key Derivation: PBKDF2-SHA512

The master key is derived from a passphrase using PBKDF2 with SHA-512 and 100,000 iterations. This means an attacker who obtains the container file still needs to brute-force the passphrase — at 100K iterations per attempt, a modern GPU can try approximately 10,000-100,000 passphrases per second instead of billions.

Credential Layer: Argon2id

As mentioned, credentials get a second pass with Argon2id before entering the master AES-256-GCM envelope. The Argon2id parameters are set to require significant memory (256MB minimum) and time (3 iterations), making parallel brute-force attacks economically infeasible.

Digital Signatures: Ed25519

Every container is signed with an Ed25519 key pair. Ed25519 uses the Edwards-curve Digital Signature Algorithm on Curve25519 — it's fast, small (64-byte signatures), and immune to the timing attacks that plague older DSA and RSA implementations.

The signature covers the entire container content hash. Any modification to any layer after signing invalidates the signature.

The Seal of Truth: SHA3-256

The Seal of Truth is our content-addressed integrity verification mechanism. It computes:

Seal = SHA3-256(transferId || timestamp || pubkey || SHA3-256(concat(ciphertexts)))

This seal binds the container's integrity to:

• A unique transfer ID (prevents replay attacks)
• The timestamp (establishes temporal context)
• The recipient's public key (ties the seal to a specific intended recipient)
• The hash of all layer ciphertexts (any tampered content breaks the seal)

SHA3-256 (Keccak) was selected because it's structurally different from SHA-2. SHA-3 uses a sponge construction rather than Merkle-Damgård, meaning length extension attacks that affect SHA-2 do not apply.

Multi-Party Escrow: X25519 ECDH

For high-stakes transfers, you don't want one person holding the decryption key. The 0nVault escrow system supports up to 8 parties.

The system uses X25519 ECDH (Diffie-Hellman on Curve25519) to generate per-party key shares. Each party gets an encrypted share of the container master key, encrypted to their public key. No single party can decrypt the container alone — a configurable threshold of parties must cooperate.

Each layer can have its own access matrix. You might configure:

• Credentials layer: requires 3 of 4 key holders
• Workflows layer: accessible by any 1 key holder
• AI brain layer: requires 2 of 4 key holders
• Audit trail: accessible by all parties, encrypted with a shared key

This is institutional-grade key management built into a command-line tool that runs on a laptop.

The Binary .0nv Container Format

Containers use a binary format, not JSON. This is intentional.

The .0nv format starts with magic bytes 0x304E5350 — the ASCII encoding of 0NSP (0n Sealed Package). Any tool reading a .0nv file can immediately identify it as a valid container and reject malformed inputs.

After the magic bytes: a version byte, flags, the Ed25519 public key, the Seal of Truth, the layer count, and then the concatenated encrypted layers. Each layer is length-prefixed so they can be read sequentially without loading the entire container into memory.

[Magic: 0x304E5350] [Version: 1 byte] [Flags: 2 bytes]
[Ed25519 PubKey: 32 bytes] [Seal: 32 bytes] [Layer Count: 2 bytes] [Layer 0: Length Prefix + Encrypted Payload] [Layer 1: Length Prefix + Encrypted Payload] ... [Layer 6: Length Prefix + Encrypted Payload] [Ed25519 Signature: 64 bytes] 

The signature at the end is over everything that precedes it.

Transfer Registry and Replay Prevention

Every transfer of a 0nVault container is recorded in a transfer registry. Each entry includes:

• Transfer ID (UUIDv4, generated at seal time)
• Sender's public key
• Recipient's public key
• Timestamp
• Layer access matrix
• Seal value

The transfer ID is embedded in the Seal of Truth. When a recipient attempts to open a container, the system checks whether the transfer ID has already been used. If it has — even with valid keys — the operation is rejected.

This prevents replay attacks: scenarios where an attacker intercepts a container transfer and tries to replay it to a different recipient or at a later time.

The Business Deed Transfer System

Building on 0nVault containers, the Business Deed Transfer System (v2.1.0) handles the complete lifecycle of transferring an entire business's digital operations.

The lifecycle: CREATE > PACKAGE > ESCROW > ACCEPT > IMPORT > FLIP

The Six Deed Tools

deed_create — Initializes a new business deed. Collects all transferable assets: workflows, credentials, env vars, MCP configs, site profiles, AI brain data. Auto-detects credentials from .env, JSON, and CSV files via the engine's credential mapper.

deed_open — Opens and decrypts an existing deed for inspection or continuation.

deed_inspect — Inspects a deed's metadata, layer summary, chain of custody, and seal status without decrypting the contents. Due diligence without exposure.

deed_verify — Verifies the Seal of Truth and Ed25519 signatures. Confirms the deed hasn't been tampered with since sealing.

deed_accept — Recipient accepts a transferred deed. The escrow key shares are combined, the master key is recovered, and the deed transitions from ESCROWED to ACCEPTED state.

deed_import — After acceptance, imports all operational data to the recipient's environment: writes .0n connection files, populates .env, deploys workflows, generates MCP configs, installs AI brain data.

The "FLIP" at the end of the lifecycle represents operational hand-off: the new operator's systems are running with the transferred operational intelligence. The previous owner's systems can be decommissioned.

CLI Commands

# Create a new vault container
0nmcp vault create

Open (decrypt) a container
0nmcp vault open business-handoff.0nv

Inspect without decrypting
0nmcp vault inspect business-handoff.0nv

Verify seal and signatures
0nmcp vault verify business-handoff.0nv

Create escrow keypairs for multi-party
0nmcp vault escrow create --parties 4 --threshold 3

Business deed lifecycle
0nmcp deed create 0nmcp deed inspect handoff.0nv 0nmcp deed verify handoff.0nv 0nmcp deed accept handoff.0nv 0nmcp deed import handoff.0nv 

Test Coverage

The vault container system ships with 48 passing tests (test-vault-container.mjs). The deed transfer system ships with 21 passing tests (test-deed.mjs). Every cryptographic primitive, every layer operation, every escrow flow, and every edge case is covered.

This is not marketing. This is verifiable:

npm run test:vault-container
48/48 tests pass

npm run test:deed
21/21 tests pass

The Patent

US Provisional Patent Application #63/990,046 was filed February 24, 2026. Inventor: Michael A Mento Jr. Assignee: RocketOpp LLC.

The prior provisional (#63/968,814, December 2025) covered the Seal of Truth mechanism specifically.

We're patenting this because the combination of semantic layering, multi-party escrow, per-layer access matrices, Seal of Truth content addressing, and the business deed transfer lifecycle represents a novel approach to operational data transfer that didn't exist before we built it.

The filing cabinet is dead. The LastPass export is a liability. This is how you transfer a business in 2026.

Read the security docs | Install 0nMCP | View the patent details