A scorecard, not a sales pitch
The Ten Golden Rules of Credential Management
These are the rules a credential system should be built on — technical, testable, pass/fail. Hold any tool against them, including ours, and count how many it keeps. Most of the industry keeps fewer than half, because the way secrets have been stored for twenty years was designed for humans who had to read and remember them. Remove that assumption and the bar moves. Here is where it should sit.
Ten rules. Each one Clavitor keeps.
Every rule is a universal principle of good credential management. Underneath each, in plain terms, is exactly how Clavitor holds to it.
01 — Random key
The key is random, and no human ever sees it.
A secret a person can read can be phished, guessed, reused, or coerced out of them. The key should be random material the machine generates — never displayed, never typed, never recoverable from anything a human knows.
02 — No master password
There is no master password. A hardware key is the only key.
A master password is a door, and a door can be picked. A recovery phrase for the owner is a recovery phrase for the attacker. The root of trust should be a physical key that must be present.
03 — Operator blind
The operator cannot decrypt the data it stores.
If the company running the servers can read your secrets, so can a rogue employee, a subpoena, or whoever breaches that company. Confidentiality should rest on math, not on the operator's good behavior.
04 — Never where code runs
Secrets never live where code runs.
A credential in a .env file, an environment variable, or a local cache is waiting for whatever runs next to grab it. Code should get the use of a secret, never custody of it.
05 — No enumeration
An agent cannot enumerate. It reaches only what it was named.
If an actor can list, search, or browse the store, a single compromise becomes a map of everything you own. The inability to enumerate is stronger than any limit placed on enumeration.
06 — Machine-bound
A credential is bound to the machine it was issued to.
Assume a credential will eventually be stolen. What matters is whether it is worth anything off the machine it belongs to. A key that works from anywhere works from the attacker's laptop.
07 — No mass drain
No single actor can drain the vault.
Normal use touches a handful of secrets. A theft tries to take everything, fast. The system should tell those two apart and stop the second one without the owner having to watch.
08 — Logged and attributed
Every action is logged and attributed.
Shared accounts and silent reads destroy accountability. When something goes wrong you need to know exactly who, or what, did it, and every credential it touched. A record with gaps is not a record.
09 — Nothing at rest on the client
No credential lingers on the client. Not on disk, not in memory, not even encrypted.
An encrypted local copy is still a copy, and the key to it is on the same machine. Anything that rests on the device is something an attacker can come back for. A credential should exist only for the instant it is used.
10 — Validated crypto
The cryptography is validated, not invented.
Home-grown crypto is how smart teams lose. The primitives protecting a secret should be ones independent reviewers have already validated, and the build should make it impossible to ship without them. Boring and audited beats clever.
Run the list.
Run your current tool down the ten. Then run ours. We wrote these down because most of the industry quietly fails several — and we built Clavitor to fail none.