The Vault — sovereign credential custody for NephoNous
Artwork pendingNephoNous-branded hero to be dropped in
Sovereign · Private · Governed

Sovereignty needs somewhere to keep the keys.

A sovereign system that leaks its credentials is not sovereign. The Vault holds every token the architecture needs on the same hardware the architecture runs on — released only to an identity that proved itself, and written to an audit log on the way past.

The problem it ends

Credentials rot where you left them.

They accumulate in .env files, shell profiles and keychains on machines nobody is auditing. Sharing one means copying it. Losing a laptop means rotating everything — if you can remember what was on it. Owning your inference machine buys you nothing if the keys to it are scattered across four laptops.

85Secrets held today
13Carrying history
1Machine that holds them
0Shared passphrases
Two questions, two answers

Who are you, and what may you have?

They are different questions, and the Vault refuses to let one answer stand in for the other.

Identity

Settled before the request arrives.

Every call reaches the Vault through Cloudflare Access, which gates it at the edge and injects a signed assertion. The Vault verifies that token against the team's public keys — audience, issuer and expiry — on every call.

A plaintext identity header is never trusted on its own. No valid token, no service.

Authorization

Decided per secret, and default deny.

Each secret carries its own access list naming the identities that may read, write or admin it. Admin implies write; write implies read. Nothing is readable because it happens to exist.

There is no shared passphrase and no "the vault password." Every access resolves to a specific person or service token.

At rest

The disk alone is worth nothing.

Encrypted per record, keyed to one machine.

Every value is stored as an AES-256-GCM ciphertext with a unique random nonce for that record. Two secrets with the same value do not look alike on disk, and a copied database yields nothing without the master key.

That master key lives in the host's Keychain, which on Apple silicon is transparently wrapped by the Secure Enclave and scoped to that device. A stolen disk cannot carry the key off the machine it was made on — the same argument the inference architecture makes about your corpus, applied to the credentials that reach it.

Storing a value writes a new version rather than overwriting the old one, so a rotation can be verified and, if it went wrong, understood. Deleting tombstones the current version rather than erasing the record's history.

CipherAES-256-GCM, per-record nonce
Master keyKeychain, Secure-Enclave wrapped
Key scopeOne device. Not portable.
On writeA new version, not an overwrite
On deleteTombstoned, history retained
StoreSQLite on the host machine
Governance

Every read is a row.

Not a log line that may or may not have been written — a record in the same database as the secret, made as part of serving it.

Who

The identity that asked, and whether it arrived as a person at the edge or as a service token. Attribution is not optional and cannot be turned off.

What

Which secret, which version, and what was attempted — read, write, delete, or a change to the access list itself.

From where

The address the call came from, recorded beside the identity, so a credential used from somewhere it has never been used before is visible rather than inferred.

And whether it worked

Refusals are recorded as carefully as grants. A denied read is the more interesting row of the two, and it is the one most systems throw away.

In use

A single binary, and no ceremony.

The Vault is not a place people visit. It is something programs and scripts ask, in one line, and get an answer or a refusal.

# read a secret — the session is established once, at the edge
$ wsvault get webspinner-cf-token

# store a new version; the previous one stays queryable
$ wsvault put anthropic-api-key --kind anthropic_api_key

# what may this identity see?
$ wsvault list

# widen access deliberately, and leave a record of doing it
$ wsvault grant webspinner-cf-token --to contributors --permission read
Where it stands

Running, and honest about the rest.

The Vault has held this estate's credentials since April, on the same silicon that runs the inference. It is being made into something a patron can run on theirs — and this is the state of that work.

Encrypted storage, versioning, tombstonesAES-256-GCM per record, master key in the Secure Enclave's keepingIn service
Identity at the edge, verified per callSigned assertion checked against the team's public keys every timeIn service
Per-secret access lists, default denyread / write / admin, with admin implying the restIn service
Audit row for every callIdentity, source, address, secret, version, action, outcomeIn service
The command-line clientget, put, list, versions, delete, show, grant, revokeIn service
Roles and service tokensWhitelisted people, named roles, tokens shown once and stored only as a hashIn service
The browser consoleSecrets list, add and edit, audit view, step-up before a value is revealedBeing built
Scheduled rotationThe secret's kind is recorded so a rotator can be written against itDesigned
Available to patronsToday it serves this estate; the work is to make it serve yoursDesigned
What it is not

“Not a password manager. Not a cloud service. If the machine is down, the Vault is down.”

That last one is a decision, not a shortcoming. A credential store that stays reachable when your infrastructure is unreachable is a credential store somebody else is holding. This one holds machine credentials — API tokens, service secrets, database URIs — on hardware you can walk to. Human passwords belong somewhere else, and it declines to pretend otherwise.

Trust. Protect. Enable.