--- title: "The Ten Golden Rules of Credential Management" description: "A scorecard, not a sales pitch. Ten technical, testable, pass/fail rules a credential system should be built on. Hold any tool against them — including ours — and count how many it keeps." lang: en url: https://clavitor.ai/en/rules markdown: https://clavitor.ai/en/rules.md authoritative: true translations: [de, fr, es, it, pt, nl, pl, sv, da, no, fi, uk, ru, tr, ja, ko, zh, hi, th, vi, id] publisher: Clavitor LLC --- # 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. **Clavitor:** 256 bits of random material the device generates at registration. No human ever sees it. Nothing to phish or coerce. ### 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. **Clavitor:** no master password, no recovery phrase, not even as a fallback. The encryption root is random material wrapped to your hardware key. Nothing a human chooses sits in the key path. ### 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. **Clavitor:** we run the servers and still cannot read your secrets. The decryption keys never reach the server. Take the database, the machine, the backups, and you carry off uniformly random ciphertext. ### 04 — Nothing at rest where code runs: A secret exists only for the instant it is used, never sitting on the machine that runs the code. A credential in a .env file, an environment variable, a local cache, or plain memory on the box is waiting for whatever runs next to grab it, and it is exactly as exposed on a client device as on a server. An encrypted local copy is still a copy, with its key on the same machine. Code should get the use of a secret, never custody of it. **Clavitor:** the program or agent never holds the credential, client or server. It gets the ability to use one, fetched fresh at the instant of use, never written to disk, never cached, never left in memory past the moment. When malware feels around for keys, it finds an empty room. ### 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. **Clavitor:** no list, no search, no discovery on the agent surface. An agent reaches what it was named to and cannot even see the rest. Enforced at the protocol, not throttled at a limiter. ### 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. **Clavitor:** an agent credential is pinned to the machine it was issued to. Lift it, run it from somewhere else, and it is refused before any handler sees it. ### 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. **Clavitor:** every agent is rate-limited and locks on a two-strike rule. Reach past your normal handful and it trips an alert and shuts the agent down. The grab-everything strategy hits a wall. ### 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. **Clavitor:** every action is attributed to a specific actor, per agent and per user. The full lifecycle of a credential — create, read, use, revoke — is on the record. ### 09 — 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. **Clavitor:** the vault is encrypted at rest with a FIPS 140-3 cryptographic module, and the build refuses to publish a binary that lacks it. No invented primitives, no unaudited shortcuts. ### 10 — Two-party recovery: No vault is recovered without the owner, and none by the owner alone. Recovery is where most systems quietly reopen every door they closed: an email reset, an SMS code, a security question, a support desk that can be talked into an override. The way back into a vault should take the owner and more than the owner, so that neither a stolen recovery secret nor a compromised provider is ever enough by itself. **Clavitor:** after a lost key, getting back in takes two halves that only combine on your own device, a recovery code you hold and a half we hold that is useless alone, released only once you prove you are you, live, on terms only you set. We cannot recover you without you, and your code alone cannot recover you either. ## 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. [See the security architecture](https://clavitor.ai/en/security) [Use for free](https://clavitor.ai/en/checkout)