Kavrix: A Zero-Knowledge Credential Vault for the Terminal

Keep credentials out of shell history, limit what local tools can access, and put explicit controls between AI coding agents and your secrets.

A secret usually stops being secret in a very ordinary way.

Someone pastes an API token into a command. A database password lands in shell history. A credential gets copied into a temporary file and stays there. An AI coding agent inherits an environment full of keys even though it only needs one of them for one command.

These are not exotic attack scenarios. They are normal workflow problems.

Kavrix approaches them as a local boundary problem. It is a zero-knowledge credential vault for the terminal. Plaintext values and key derivation remain inside the local Kavrix process. The datastore receives authenticated ciphertext instead of readable credentials.

That distinction matters because storing a secret securely is only part of the job. You also need a controlled way to use it.

Keep secrets out of the command itself

The safest command is often the one that never contains the secret.

Kavrix accepts sensitive input through masked prompts, protected files, or documented stdin flows. It does not expect passwords, recovery material, or portable keys to be placed in ordinary command arguments, environment variables used to unlock the vault, or its non-secret settings file.

A simple credential can be stored like this:

kavrix put github/token --profile work --vault <vault-id>

Kavrix then prompts for the value without echoing it to the terminal.

Reading that record does not reveal the value by default:

kavrix get github/token --profile work --vault <vault-id>

Plaintext requires a separate and explicit decision:

kavrix get github/token --reveal --profile work --vault <vault-id>

There is no ambient unlocked session that quietly remains open. Each reveal is deliberate.

For everyday work, commands such as list, view, search, and stats can answer questions about what exists and when it changed without printing credential values.

Give a process what it needs, not everything you have

Developers often need a secret because another program needs it. Copying the value into the terminal is unnecessary exposure.

kavrix run unlocks only the credentials selected for one child process and injects them into that process environment. The value does not appear in the child arguments or in the command being typed.

For example:

kavrix run --profile work --vault <vault-id>   --secret DATABASE_URL=production/database   -- node server.js

This is process scoping, not a sandbox. An authorized program can read its own environment and can send the value elsewhere. Kavrix controls whether the program may start with that credential. It cannot control everything the program does afterward.

That limitation is important. A credential tool should make trust boundaries clearer, not pretend they do not exist.

Put AI coding agents behind a credential firewall

AI coding agents create a sharper version of the same problem. An agent may need to run gh, deploy a service, or access a development API. Giving the entire agent session a reusable token creates a much wider boundary than the task requires.

Kavrix can start an agent process without vault credentials or unlock keys. The agent requests a specific operation through a local broker, and Kavrix checks that request against stored policies.

A policy can restrict:

• Which credential may be used
• Which executable may receive it
• The executable’s SHA-256 hash
• The working directory
• Maximum runtime
• Whether a person must confirm
• How many times a temporary grant may be used

Temporary grants can expire, run out of permitted uses, or be revoked. Kavrix also records policy, grant, authorization, confirmation, and completion events without including credential plaintext.

This does not make an AI agent safe by itself. It creates a smaller, inspectable route for credential use. The agent starts without the credential, and each requested operation must pass the configured rules.

Choose where the ciphertext lives

Kavrix supports a local encrypted database file as its first-class datastore. MongoDB is optional for users who already control a suitable deployment.

No Kavrix API server, sync daemon, or hosted account is required. The local process performs the cryptography, then sends an opaque encrypted document to the selected datastore.

The datastore can still observe operational metadata. This includes vault identifiers, document revisions, timestamps, ciphertext size, update timing, and access patterns. It does not receive credential names, credential values, passphrases, recovery keys, or the unwrapped vault root key.

Zero knowledge here means the datastore does not receive the material needed to read the vault. It does not mean the database becomes invisible.

Recovery is part of the design

Kavrix separates encrypted data from the material used to unlock it. Backing up only one side is not enough.

A recovery kit adds a separately passphrase-protected recovery path. It can be created, verified, inspected, and revoked. The documentation recommends keeping recovery material separately from the owner key and datastore backup.

If every key file and every recovery kit is lost, the vault cannot be recovered. There is no vendor reset or escrow path.

Start with the honest version

Kavrix is an experimental release and has not been independently audited. It should not be described as production-ready or treated as a guarantee of safety.

It also cannot protect an already-compromised machine from malware, keyloggers, memory inspection, terminal capture, or an administrator. It does not currently provide team invitations, reader and editor roles, ownership transfer, or fine-grained vault sharing.

Those limits are documented, and they should be part of any evaluation.

If the model fits a problem you have, start by reading the Kavrix security model and automation documentation. Then try it with non-production credentials and verify the boundary for yourself.