Your Data, Your Key

How the HUMΛN Vault protects personal data — and why HUMΛN never sees it

The Promise

HUMΛN never sees your data. Here's what that means in practice: your health records, certifications, and identity documents are encrypted with keys you hold. The server stores ciphertext. When you share with your doctor or employer, you grant access to specific documents — HUMΛN cannot read them, subpoena them, or use them for anything.

The MRI Story

Alice gets an MRI. The radiologist's system uploads the scan to her HUMΛN Vault. Alice holds the key — the radiologist's system never had it. Six months later her GP needs to see it. Alice opens the sharing dialog, selects the scan, and grants read access to her GP's Passport. The GP's app receives the encrypted scan and the GP's wrapped document key. Neither HUMΛN nor the radiologist can access the file. When Alice changes insurance providers, her vault migrates to a new provider. The vault:// URI in her Passport still resolves correctly. The MRI is still hers.

What Is a Vault?

A vault is your personal encrypted store. You hold the key. HUMΛN stores ciphertext. Contrast this with services that claim to "encrypt" data but hold the keys themselves — iCloud without Advanced Data Protection, Google Drive, most cloud storage. In those systems, the provider can decrypt your data. In HUMΛN's vault, they cannot.

Vault vs. Traditional Cloud Storage

Aspect	HUMΛN Vault	Traditional Cloud
Who holds the key?	You	Provider
Can provider read your data?	No	Yes
Subpoena to provider?	Returns ciphertext only	Returns plaintext

The MRI Walkthrough

Step-by-step: the radiologist's system calls vaultClient.storeBinary(). A per-document DEK is generated client-side. The scan is encrypted with AES-256-GCM. Only ciphertext and a 12-byte IV are POSTed to /v1/vault/.... HUMΛN's database stores:

typescript

// What HUMΛN's database actually contains
{
  doc_id: "scan-2026.dcm",
  ciphertext: "[base64-encoded encrypted bytes]",
  iv: "[12-byte initialization vector]",
  metadata: { content_type: "application/dicom" }
}
// No plaintext. No decryption key. Ever.

Sharing Without Surrendering

The selective disclosure model: Alice's client fetches the document DEK, wraps it for her GP's public key, and posts to the share endpoint. The GP retrieves both ciphertext and their wrapped DEK. Neither HUMΛN nor the radiologist ever had the GP's key. Code example:

typescript

// Alice shares her MRI with her GP (selective disclosure)
// 1. Alice's client has the document DEK (decrypted locally)
// 2. Fetch GP's public key from their Passport
// 3. Wrap the DEK for the GP's key
// 4. POST to /v1/vault/:entityDid/share

await vaultClient.shareDocument(
  'vault://did:human:alice/health/mri/scan-2026.dcm',
  'did:human:gp-dr-smith'
);

// GP's app: retrieve ciphertext + wrapped DEK, decrypt locally
// HUMΛN never sees plaintext.

Note: The share endpoint is part of the migration protocol (WS-9.16). The architecture above describes the canonical design.

Vault URIs Are Portable

vault://did:human:alice/health/mri/scan-2026.dcm is a contract. The endpoint is resolved at runtime from Alice's Passport record. She can migrate providers; the URI stays valid. The vault-resolver looks up passports.vault_endpoint and dispatches to the correct backend.

typescript

// Resolve a vault URI — works regardless of where the data lives
const content = await vaultClient.resolveUri(
  'vault://did:human:alice/health/mri/scan-2026.dcm'
);
// Returns decrypted content (JSON or binary) based on metadata.content_type

What HUMΛN Cannot Do

This is architectural — not a privacy policy. HUMΛN:

✗Cannot produce plaintext — we don't have the keys
✗Cannot be compelled to share Alice's MRI — we have nothing to share
✗Cannot read her health data for ads, analytics, or AI training

The invariants: vault_documents.ciphertext is AES-256-GCM encrypted before it reaches the API; the vault DEK is derived from the user's passkey PRF output or passphrase and never transmitted to the server.

Quick Start Code

Unlock, store, retrieve, and resolve:

1. Unlock (after WebAuthn login with PRF)

typescript

import { VaultClient } from '@human/passport/vault';

const vault = new VaultClient({
  apiBaseUrl: '/api/proxy',
  sessionToken: '',
  passportDid: 'did:human:alice',
});

await vault.unlockWithPRF(prfOutput); // from WebAuthn prf.results

2. Store

typescript

const docId = await vault.store(
  'did:human:alice',
  'health',
  'mri',
  { scanData: '...' },
  { content_type: 'application/json' }
);

3. Store Binary

typescript

const docId = await vault.storeBinary(
  'did:human:alice',
  'health',
  'mri',
  mriFileArrayBuffer,
  { content_type: 'application/dicom' }
);

4. Retrieve

typescript

const data = await vault.retrieve(
  'did:human:alice',
  'health',
  'mri',
  docId
);

5. Resolve URI

typescript

const content = await vault.resolveUri(
  'vault://did:human:alice/health/mri/scan-2026.dcm'
);

Next Steps

Your org's SharePoint documents work differently — delegated access, not sovereign encryption. See Connected Storage for the full picture.

Working with Your Organization's Files