Skip to content

Tool Pick | KRU — Let Your Agent Use a Password Without Ever Seeing It

Sep 5, 20261 min
TL;DRKRU is a local-first MCP credential manager that lets agents like Codex, Claude Code, and Cursor log in, connect, and call APIs using saved passwords, API keys, SSH keys, and TOTP codes — without the plaintext secret coming back into the conversation. Install: download the portable build from GitHub Releases. It addresses the problem of an agent stalling on a login page or SSH password prompt, leaving you to either take over manually or paste the secret straight into the chat.

Look up & save

Loading dictionary…

🌏 中文版

Tool Info

FieldValue
NameKRU
TypeLocal MCP server + credential vault (desktop app)
GitHubomaekumiko2-create/kru
Stars126
LanguageRust (Tauri)
LicenseMIT
InstallDownload the portable build for your platform from GitHub Releases

What Problem It Solves

Have you had an agent running a deploy or scraping task, only to have it stall halfway through on a login page, an SSH password prompt, or an API call that needs a key? At that point you usually have two options: take over and type the password yourself, breaking your flow, or paste the plaintext password into the conversation so the agent can keep going — which means a real secret now sits in model context, and if you're using a third-party client or model endpoint, that plaintext may well end up in someone else's logs or training pool.

KRU is a local stdio MCP server that first stores your passwords, API keys, SSH private keys, and TOTP seeds in a locally encrypted vault (XChaCha20-Poly1305), then lets the agent operate by item name instead of by the secret itself. The agent calls a tool like credential_fill and says "log in using the Production Server item," and KRU fills the browser field, runs the SSH command, or assembles the authenticated HTTP request locally — the value itself defaults to "Hidden," meaning the tool can use it but it never appears in what gets returned to the model. Visibility is a per-field switch (username, password, key, TOTP, custom field), not an all-or-nothing toggle on the whole item.

Good fit for: deploy scripts that need to SSH into production, agents calling a service that requires an API key, browser automation that hits a login form, or any repetitive authentication step where you don't want plaintext secrets going into the conversation history.

Quick Start

Install

# Download the portable build (recommended)
# Windows / macOS / Linux → .zip / .app / .tar.gz respectively
# https://github.com/omaekumiko2-create/kru/releases/latest

# Or build from source (requires Rust 1.88+, Node.js 22+, Tauri 2 prerequisites)
git clone https://github.com/omaekumiko2-create/kru
cd kru
npm install
npm run build
npm run portable

Basic Usage

Open the KRU desktop app, go to Settings → Agent connection and pick your client (Codex, Claude Code, Cursor, OpenCode, and OpenClaw can be auto-detected and configured), save an item (say, named "Production Server"), then just tell your agent:

Use "Production Server" in KRU MCP to deploy the current build and verify the service.

The MCP tools the agent actually calls underneath:

items_search(query?)   → find usable items, their fields, and available actions
credential_fill        → fill one field's value into the currently focused input
ssh_run / ssh_upload / ssh_download → run commands or transfer files using a saved password/key
http_send              → send an authenticated HTTP request using saved credentials
terminal_run           → run a one-shot local command, with {{kru:field name}} for hidden values

Advanced Usage

// Manual stdio MCP config if your client isn't auto-detected
{
  "mcpServers": {
    "kru": {
      "command": "/absolute/path/to/kru",
      "args": ["mcp", "stdio"]
    }
  }
}

Or print a ready-made config:

kru config stdio-json
kru config stdio-toml

Comparison with Existing Tools

KRUPasting the password into chatSystem/browser password manager (e.g. 1Password CLI)Environment variables / .env
Plaintext never enters model context✅❌Partial (op run still injects the value into process env)✅
Agent decides which credential to use, autonomously✅ (matched by item name and action)✅❌ (you inject it manually first)❌ (you inject it manually first)
Supports SSH / SFTP / HTTP auth as distinct actions✅—Partial❌
Requires a cloud account or subscription❌—Depends on plan❌
Per-field (not per-item) visibility control✅❌❌❌

Things to Watch Out For

  • Not a sandbox: the README is explicit — KRU doesn't judge whether an agent's command is safe, and it doesn't defend against a malicious agent or an already-compromised machine or browser. It only guarantees the plaintext doesn't come back into the conversation, not that whatever the agent does with it is what you wanted.
  • SSH host fingerprints aren't verified: KRU supports password and private-key auth, but doesn't pin or compare SSH host fingerprints — you need to handle man-in-the-middle risk separately.
  • The Visible switch really does leak plaintext: fields default to Hidden, but you can flip one to Visible so its value returns to the model — once flipped, it's no different from pasting the password directly; it's just a switch you have to remember to turn back off.
  • Still a very young project: created on 2026-08-24, at 126 stars and 6 forks, and the author says in the launch post they've only been using it themselves for a week or two — the interface and MCP tool surface may still change.

Today's Takeaway

The default instinct for "agents shouldn't touch passwords" is to cut the whole line — never let the agent near any credential, keep every step manual. KRU's approach instead splits "can it be used" from "can the plaintext be seen" into two independent switches: the agent can trigger a real login, SSH session, or API call, but the plaintext exists only briefly, locally, inside KRU itself — from the model's perspective the whole thing reads as "this got done for me," not "here is the password." That per-field visibility design fits how authentication actually needs to work day to day — "let it be used, but don't let it be seen" — better than a plain all-or-nothing credential access model does.

References