v0.1 · macOS · MIT
a macOS secrets manager AI agents architecturally cannot leak from.
Stores keys in macOS Keychain. Ships with a Claude skill that lets agents put secrets into your files without ever seeing the value. Free, open source, single-binary install.
claude.ai/code
demo · 30 s · placeholder
the diff
the leak vs the fix
The leak isn't where the key is stored — it's where the agent can see it. Storage vaults like 1Password CLI / doppler / vault all make the value flow through the agent's context window the moment you ask for it. keys-keeper gives the agent a different verb.
pbpaste, wrote to keychain, then wrote into .env directly. The transcript holds only the operation. The value lives in macOS Keychain (Touch-ID protected) and in the file you wanted it in. Nowhere else.
the design
command surface, by design
The split is structural, not a convention. The shipped Claude skill markdown enumerates exactly which commands the agent may use. The one command that prints plaintext to stdout — keys reveal — refuses to run unless an explicit env-var is set, which the skill never sets and the agent has no path to set. The structural guard fires before any prose can override it.
keys add NAME --from-clipboard / --from-file / --stdin
keys list / info / audit
keys copy NAME
pbcopy; auto-clears in 30 s with SHA-256 check so it doesn't wipe unrelated content.keys inject NAME --file F --as ENV
ENV=value to the file. The CLI writes; the agent never sees.keys resolve PATH
__KEYS:name__ placeholders in-place. Works on .env.template, deploy scripts, anything text.keys ssh NAME
ssh -i <tempfile>, shreds the tempfile on exit.keys reveal NAME
KEYS_KEEPER_ALLOW_REVEAL=1 is in env. Most users never set it; agents have no path to set it. This is the structural guard that fires before any prose can override it.The shipped skill markdown tells Claude: "You MUST NOT runkeys reveal. You CAN usekeys copy / inject / resolve / ssh." The env-var gate makes that instruction structural. Even if the agent tried, the CLI itself refuses.
and a local admin
so you can browse 50+ keys without losing your mind
Run keys serve and a localhost-only admin opens at 127.0.0.1:7777. Token in the URL, stripped via history.replaceState, then a session cookie. No cloud, no account, no telemetry. Five screens, terminal-density.
/paste Bulk import
SOURCE
PREVIEW · 4 entries · 0 errors
top entries · last 7 d
daily activity · last 30 d
Settings
how it fits together
two-layer storage. one process. zero network.
Secrets live in the macOS Keychain — Touch-ID protected, tied to your login session. Metadata (names, tags, refs, audit log) lives in ~/.config/keys-keeper/ as boring JSON you can back up or diff. The CLI mediates both. The admin is the same process exposing localhost HTTP.
install in 5 minutes
five lines of bash. zero account.
Single binary on PATH after pipx. The skill install is a separate command so you can say no to it (e.g. you're trying it from the CLI before adding the Claude integration).
git clone https://github.com/kyzdes/keys-keeper.git cd keys-keeper pipx install . ./scripts/install_skill.sh
requires Python 3.10+ and macOS. Linux/Windows backends are on the roadmap below.
brew install pipx && pipx ensurepath — one line, restart your shell.
roadmap
open source · accepting PRs
Owner is one developer with a day job. The list below is what's planned but not yet shipped — pull-request bingo welcome.
- Linux backend via secret-tool (libsecret) — KeychainBackend interface already abstracted
- Windows backend via Credential Manager (with chunking for SSH keys; CredMan has a 2560-byte cap)
- Touch-ID-gated reveal in admin with auto-wipe from DOM after 10 s
- Cursor / Aider / Cline rule-file generators beyond the Claude skill format
- CSV export from /audit (already CLI-only via
keys audit > file.csv) - Bulk-paste parser extension for ssh_key / server / domain (currently clean only for api_key)
- Light theme polish — CSS tokens exist; not all surfaces tested
- Cmd+K action palette beyond navigation — "copy openrouter" as a one-shot
PRs welcome. Start at github.com/kyzdes/keys-keeper/issues — or just open one with the rough idea.
honest limitations
what v0.1 is not.
If any of these is a dealbreaker, that's fine — none of them are theoretically hard, they're just not done yet. Tracking on the roadmap above.
macOS only
Keychain backend is the only one shipped. Linux/Windows are on the roadmap.
single user
No team / multi-user / sharing. This is a personal tool.
no cloud sync
Use keys export + your encrypted-file sync route.
bulk paste = api_key
Other types via + New form in the admin for now.
caller_path is best-effort
From ps -o command=. Forensics-level, not court evidence.
threat model
what this defends against. and what it doesn't.
If you're considering keys-keeper, you should know the boundaries. Vague claims help no one — here's the explicit shape of the protection.
defends against
AI agents extracting plaintext into transcripts (the original motivation), accidental git add of .env files, plaintext clipboard residue past the auto-clear window, ad-hoc shell scripts that need a key without you retyping it.
does not defend against
A root-level adversary on your Mac, malware with full keychain access, screen-recording on a compromised host, or network attackers (the admin is localhost-only and never reachable from outside the loopback interface anyway).