Keyward

The credential manager that's as polished as 1Password, as open as Bitwarden, and as private as you want it — because you decide where your vault lives.

Keyward is an open-source, B2C credential manager. Today it stores passwords, TOTP, secure notes, cards, and identities; passkeys and email aliases are on the roadmap, not yet implemented (the data model reserves a passkey field, but there is no WebAuthn create/use path). It is built to close the two gaps the market leaves open:

• The best UX (1Password) is proprietary, has no free tier, and just got more expensive.
• The best open option (Bitwarden) has a degraded browser extension and weak connectivity.

Keyward refuses that trade-off, and adds three things no competitor offers together:

• 🔐 Choosable & migratable trust model — keep your vault on-device only, in our managed cloud, on your own self-hosted server, or in your own storage (iCloud/Dropbox/WebDAV) — and migrate between them seamlessly, with no destructive re-encryption.
• 👨‍👩‍👧 Family-first sharing — private + shared vaults, guest sharing, account recovery, mixed-skill onboarding.
• 🤖 AI credential broker — an MCP server + CLI that lets your agents use credentials (fill a login, run an authenticated command) without the plaintext ever entering the model context, chat, or history. Give your agents hands, not your secrets.

Built open-core: fully open-source clients + server, self-host free forever; revenue from managed cloud, family/premium features, and the broker.

Documentation

• 📊 Market & Feature Research — market sizing, competitive teardown, feature matrix, pain points, trends, and the opening.
• 📐 Product Specification (PRD) — vision, personas, differentiation, architecture, the AI credential broker, feature set, pricing, roadmap, and GTM.
• 🏛️ ADR-0001 — Broker security model — the design the prototype implements.
• 🧭 ADR-0002 — Scaling credential use across providers — why "N providers" doesn't get huge: vault-read + standard-protocol minters + one generic injector + a profile registry.
• 🛡️ Threat Model & Security Posture — STRIDE by component, trust boundaries, residual risks, and the reviewer checklist (frames an external review; not a substitute for one).

v1.0.0 — the Phase B wedge, complete end-to-end

A runnable Rust workspace: a real encrypted vault, the credential-broker security model, minting and vault-read, secretless read/write execution, interactive step-up approval, propose-not-commit, a persistent audit log, and a kill switch — all driveable from Claude Code over MCP, all tested.

crates/
  crypto/   keyward-crypto  shared cryptographic kernel (Argon2id KDF + XChaCha20-Poly1305
                            AEAD + CSPRNG) — used by both vault contexts
  vault/    keyward-vault   encrypted vault (on the shared kernel), file-backed — PROTOTYPE
  broker/   keyward-broker  the security model: capabilities, origin-binding,
                            propose-not-commit, risk-tiered policy, hash-chained audit
  mint/     keyward-mint    mint short-lived scoped tokens + secretless execution
                            (MockMinter/MockExecutor + real GitHub App minter & executor)
  profiles/ keyward-profiles external, pluggable provider profiles (TOML) — add a
                            provider by dropping a file; no recompile
  passbook/ keyward-passbook consumer credential manager (Phase A): rich item model,
                            TOTP (RFC 6238), Secret Key (2SKD), Watchtower,
                            family sharing (X25519 sealed-box), password generator +
                            HIBP k-anonymity breach check — PROTOTYPE
  passbook-cli/ passbook    manage the consumer vault from the terminal
                            (init/add-login/list/show/totp/watchtower/emergency-kit)
                            + `passbook bridge` — the browser native-messaging host
  passbook-wasm/ passbook-wasm  wasm-bindgen surface so the vault crypto/TOTP/Watchtower
                            runs client-side in the browser
  mcp/      keyward-mcp     the broker+vault+minting+execution as an MCP server (stdio) via rmcp
  cli/      keyward         manage the vault (init/add/list) + list profiles + demo
  sync/     keyward-sync    zero-knowledge sync domain: versioned push/pull of an
                            opaque sealed blob (SyncStore port + Memory/File adapters)
  sync-server/ keyward-sync-server  tiny HTTP server for E2E sync — accounts +
                            per-device tokens (stored as SHA-256 hashes) with
                            device list/revoke + CORS; stores only ciphertext

The web vault (app/) can turn on cloud sync (register an account, add devices, auto-push on every change with conflict handling) and also runs as a native desktop app via a Tauri v2 shell (app/src-tauri/, npm run tauri dev) that reuses the exact same Vue frontend.

The consumer product (Phase A, the 1Password equivalent) also ships:

• app/ — the web vault: a Vue 3 + Vite + TypeScript + Pinia app backed by passbook-wasm. Unlock, browse, reveal/copy, live RFC-6238 2FA, and a Watchtower security dashboard — the vault is stored as a single encrypted blob in the browser and all crypto runs in WebAssembly. Sealed with a device Secret Key (2SKD) + master password, with a one-time Emergency Kit and an add-a-device flow. Import from Bitwarden (JSON) or LastPass/1Password/CSV and export (Keyward/Bitwarden JSON, CSV) — no lock-in. cd app && npm install && npm run build:wasm && npm run dev.
• extension/ — a Manifest V3 browser extension for autofill, wired to the real vault over Chrome native messaging (passbook bridge) with a demo fallback. The list reply carries no secrets; passwords cross only at fill time, origin-bound. See extension/native-host/.

The vault crypto core (keyward-passbook) compiles to WebAssembly so the same tested Rust runs in the CLI, the MCP server, and the browser.

Architecture follows Domain-Driven Design + hexagonal (ports & adapters): two bounded contexts (Passbook, Broker) over one shared crypto kernel, a pure domain core, and I/O behind ports. See context map, ubiquitous language, and ADR-0003.

New providers are external config, not code. Drop a <id>.toml into $KEYWARD_PROFILES (see profiles/) and keyward profiles picks it up — GitLab, Azure, Cloudflare, whatever arises. See ADR-0002.

cargo test --workspace              # 37 tests: origin-binding, step-up, propose-not-commit exec, secretless no-leak, audit chain…
cargo run -p keyward-cli -- demo    # watch the model block a confused-deputy attack, etc.

Quickstart — dogfood it in Claude Code

# 1. Build & create a vault
cargo install --path crates/cli --path crates/mcp
export KEYWARD_VAULT=~/.keyward/vault.json KEYWARD_MASTER='your master secret'
mkdir -p ~/.keyward && keyward init
# vault-read (default): store the token; Keyward reads and uses it directly
keyward add itm_github "GitHub token" github.com "$(cat token.txt)"
# or minting: store an App key and pass mintable=true
# keyward add itm_ghapp "GitHub App" github.com "$(cat app.pem)" true apikey

# 2. Register the MCP server (it reads the same env)
claude mcp add keyward -- keyward-mcp

# 3. (optional) real GitHub App minting instead of the mock:
#    export KEYWARD_GH_APP_ID=... KEYWARD_GH_INSTALLATION_ID=...

The server exposes list_credentials, use_credential, audit_log. On an allowed read, the broker performs the action itself and returns only the sanitized result — the credential never reaches the model (secretless execution). How it gets the credential is per-item, set by the mintable flag:

• mintable = false → the broker reads the token you stored in the vault and uses it directly (nothing fetched or created) — source: "vault".
• mintable = true → the vault holds an App key; the broker mints a fresh, short-lived, narrowly-scoped token, then performs — source: "minted".

Either way the token is used inside the broker and never returned. Ask your agent to ship to prod unattended and it's downgraded to a pull request; ask it to open that PR and the broker performs it as a draft (review required, not merged) — the runtime half of propose-not-commit. Use a credential against the wrong origin and it's refused outright.

Security note: this is a prototype. The vault, minting, broker, and secretless read execution are real and tested, but a formal security review is required before any real use.

Status

v1.0.0 — the wedge is complete end-to-end. In one flow the broker: refuses a confused-deputy origin, prompts for human approval on a step-up (via MCP elicitation), downgrades an unattended ShipToProduction to a reviewable draft PR, performs reads/writes secretlessly (vault-read or mint), persists a tamper-evident audit log, and offers a kill switch — never exposing a credential to the model. 37 passing tests across 5 crates.

Deferred (post-wedge): OAuth Token Exchange / cloud STS minters, more executable operations, unattended out-of-band alerts, sync/self-host surfaces. See the CHANGELOG and the PRD roadmap.

A formal security review is required before any real use. GitHub network paths are real code, exercised offline via injected mocks.

License

AGPL-3.0-or-later, for the whole workspace — see LICENSE. This is what Cargo.toml has declared all along; the file backing it was missing until now, which meant the "open-source" claim above had nothing behind it (absent a license, default copyright reserves all rights).

Open-core in practice: the tool is public and AGPL. The managed cloud deployment — cluster topology, ingress, RollOps config, ops runbooks — is a separate private repository. The server code is not private, and self-hosting needs no permission: keyward-sync-server runs file-backed with no Postgres and no Stripe configured, which is the free self-host path.

AGPL rather than GPL on the clients too, one consequence worth stating plainly: the crates (keyward-crypto, keyward-passbook, …) cannot be embedded in proprietary software. For a credential manager that is intended. If any of them should be reusable by others, that crate wants a permissive licence instead, and that is a per-crate decision this file does not foreclose.