The Ten Rules of Credential Management

Most credential tools break at least one of these. That is not an accusation, it is arithmetic.

The way secrets have been stored for the last twenty years was designed for humans who had to read and remember them. Master passwords. Recovery phrases. A vault you unlock and a vault that, once unlocked, hands everything to whatever asks. Remove the assumption that a person reads the secret, and the rules change.

Below are ten rules a credential system should be built on. They are technical, testable, and pass/fail. Hold any tool against them, including ours, and count how many it keeps. Then keep reading, because under each rule is exactly how Clavitor keeps it.

1. The key is random, and no human ever sees it.

A secret a person can read is a secret that can be phished, guessed, reused, or coerced out of them. The encryption key should be random material the machine generates, never displayed, never typed, never recoverable from anything a human knows.

Clavitor: the key is 256 bits of random material the device generates at registration. No human ever sees it. There is nothing to phish or coerce.

2. 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, not a string anyone can be made to type.

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.

3. The operator cannot decrypt the data it stores.

If the company running the servers can read your secrets, then 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.

4. Secrets never live where code runs.

A credential in a .env file, an environment variable, or a local cache is a credential waiting for whatever runs next to grab it. One bad install script should not be able to walk off with your keys. Code should get the use of a secret, never custody of it.

Clavitor: the program or agent never holds the credential. It gets the ability to use one, fetched fresh at the instant of use, never written to disk, never cached. When malware feels around for keys, it finds an empty room.

5. 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 a stronger control 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. This is enforced at the protocol, not throttled at a limiter.

6. 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 is a key that 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.

7. 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.

8. 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, with no ambiguity. A record with gaps is not a record.

Clavitor: every action is attributed to a specific actor, per agent and per user, and the full lifecycle of a credential, create, read, use, and revoke, is on the record.

9. 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.

Clavitor: every read is live and discarded on use. Nothing is cached or persisted on the client, encrypted or otherwise. The secret is in memory for the moment of use, then gone. Revoke it and it is gone on the next request.

10. 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.

Run the list

Ten rules. Run your current tool down the list and count. Then run ours.

We wrote these down because most of the industry quietly fails several, and we built Clavitor to fail none.

Clavitor. The credential vault built for AI agents, and against them.