← All products

Data at rest and in use

Directory Lock

Available now

Your data stays ciphertext on disk, ciphertext in memory, and readable only in the instant an operation needs it — after a person has physically proved they are there.

Shipping today. Ask for access and we will get you a build.

What it does

Ciphertext at rest, with no second copy

The directory lives as a single AES-256 sealed blob. There is no plaintext version sitting on disk to be imaged, indexed, swept into a backup, or handed to a process that asked politely.

The key will not release without a person

The encryption key is held as a user-presence secret: releasing it requires a live biometric or device-password response from someone at the machine. An automated process running with entirely valid credentials still cannot open the directory, because presence is not a credential anything can hold on your behalf.

Plaintext exists only in memory

Unlocking mounts a RAM disk and the working copy lives there. It never touches persistent storage, and it does not survive a power loss — so the exposure window is bounded by physics as well as by policy.

Secrets stay encrypted in memory as well

Private material is not merely encrypted on disk and then left sitting in RAM as plaintext. Each secret is held sealed under AES-256-GCM with its own nonce and opened only for the single operation that needs it. Read the process memory outside that instant and you get ciphertext.

The key is wiped, including when things go wrong

The key-encryption key is zeroed the moment a session locks — and on every error path, not just the successful one. Ownership of the key is explicit in the implementation, so a caller cannot drop it and leave it resident for the life of the process.

No single person can recover it

The key-encryption key is wrapped pairwise under three custodian passphrases, so any two can recover it and any one cannot. There is no single holder to compromise, coerce, or impersonate.

A fixed window, not a sliding one

The session expires on a hard one-hour cap regardless of activity. This is deliberately not an idle timeout: staying busy does not hold the door open, which is exactly the behaviour an automated workload would otherwise exploit.

One session, detected rather than duplicated

The working volume carries a stable name instead of a timestamped one, so a second unlock attempt is detected instead of quietly creating a second plaintext copy nobody is tracking.

Over-permissive files are refused

Private material is written under a fixed permission mode, and any file carrying a group or world bit is rejected rather than silently trusted. A widened permission becomes an error instead of an exposure.

Request Access

The lock in specifics

Enforced by the implementation, not by policy documents.

Cipher
AES-256
At rest
Single sealed blob
Key release
User presence required
Working copy
RAM disk only
In memory
Sealed, opened per operation
On lock and on error
Key zeroed
Session cap
1 hour, fixed
Vault recovery
2 of 3 custodians

How a session runs

Each step is a checkpoint you sign off before the next begins.

  1. 01

    Sealed

    At rest the directory is one encrypted blob. Nothing readable exists on disk, including for anything running as you.

  2. 02

    Unlock

    A person answers the presence prompt. Only then is the key released and a RAM disk mounted with the working copy.

  3. 03

    Work

    Operations run against the in-memory copy while a guardian process holds the session and its expiry. Individual secrets stay sealed between operations rather than sitting open for the length of the session.

  4. 04

    Re-lock

    At the one-hour cap the guardian re-seals the directory and tears down the volume, whether or not anyone is still working.

Works alongside

Nothing here needs the rest of the line to be useful — but they are built to fit together.