The Kvendra CLI
The CLI is where Kvendra meets your machine. It is a single, statically linked binary that does two jobs at once: it keeps your secrets in a local zero-knowledge vault, and it acts as a capability broker that performs sensitive operations on behalf of a tool or agent — without ever exposing the underlying credentials to that caller.
The Kvendra CLI is the foundational piece of Kvendra: a Rust (edition 2024, MSRV 1.85+) binary (kvendra, Apache-2.0).
The kvendra CLI is a Rust binary that is the foundational piece of the product: a zero-knowledge local vault (Level 2) plus an MCP capability broker, an HMAC-signed audit log, a detection layer and a TUI.
The open-core primitives
The broker exposes 7 open-core primitives. Each primitive receives an injected secret resolved by the vault — the model issuing the call never sees the raw value.
| Primitive | Operations | Notes |
|---|---|---|
kvendra.git | clone, push, pull, commit, tag | SSH-only authentication by threat model — no inline tokens. |
kvendra.github | read_repo, read_issue, update_issue, update_repo, release, add_topics, create_issue, list_issues | Read ops are auth-light; create_issue is destructive and body-sanitized. |
kvendra.npm | publish, deprecate, read_metadata | Package registry operations. |
kvendra.pypi | upload, read_metadata | Python package registry operations. |
kvendra.http | request | A single generic outbound HTTP request primitive. |
kvendra.shell | exec | Run an allowlisted shell command. |
Beyond these, an audit-marked escape hatch exists: kvendra.unsafe.raw_token — an audit-marked escape hatch, always flagged unsafe in the audit log.
Introspection
kvendra capabilities (and —pretty) emits a canonical JSON manifest of the broker’s primitive surface: broker_version, schema_version, and each primitive with its ops, destructive ops and vault profile pattern. Auth-less, read-only, no vault unlock required.
The vault
The vault lives in a per-user home directory and holds: a config file (HMAC sidecar), a SQLite audit database (WAL, HMAC-chained), Argon2id-hashed recovery codes, a sentinel blob, AES-256-GCM secret blobs per profile, and HMAC-signed allowlist YAMLs per profile.
Cryptography: Argon2id KDF, AES-256-GCM AEAD, an HMAC chain over the audit log, a sentinel blob and recovery codes.
Modes of operation: Local (default): zero-knowledge vault, secrets resolved locally. A remote-broker resolver mode exists for hosted deployments via OIDC PKCE login.
How a brokered call works
When a skill needs to push to a git remote or invoke an HTTP endpoint, it does not get the token. Instead it asks the broker to run the operation. The broker resolves the secret from the vault, checks the request against an HMAC-signed allowlist for the active profile, runs the operation, and writes a signed entry to the audit log. The caller sees only the result.
# Inspect the broker's primitive surface — no vault unlock required
kvendra capabilities --pretty
# The output is a canonical JSON manifest: broker_version, schema_version,
# and every primitive with its operations and which of them are destructive.Why a broker at all
The design goal is a hard separation between the thing that decides what to do (a model or a script) and the thing that holds the keys (the vault). The allowlist makes that separation enforceable rather than advisory: an operation that is not on the signed allowlist for the active profile simply does not run.