Keyclasp lets local agents access encrypted tokens without embedding secrets in prompts

I kept running into the same problem: either I’d have the agent give me the command, run it myself with the credentials, and copy-paste the output back, or I’d let the agent run it and keep finding secrets in its output. I looked into alternatives and asked friends, but the only workable approach I found for my workflow was writing custom wrappers around CLIs to handle authentication. I got tired of the back-and-forth, rotating leaked tokens, and maintaining wrappers, so I built Keyclasp. Keyclasp stores credentials in a local encrypted vault. The agent works with secret names and selects what a command needs: keyclasp run --project myapp --environment dev --env API_KEY -- npm test The child process receives the requested token through its environment. The agent can discover available secret names without retrieving their values. I also include a skill that explains the workflow. You can require operator authorization or explicitly allow selected secrets to run unattended. Everything is local and open source. The command still needs to be trusted: it receives the real credential and can write it to disk or send it over the network. Keyclasp doesn’t sandbox commands or isolate secrets from other processes running as your OS user. An output guard scans stdout and stderr for exact injected values of at least eight characters. If it detects one, it redacts the match, stops forwarding output, and attempts to terminate the process group. Shorter values, encoded values, and fragments are outside that protection. Keyclasp hasn’t had a professional third-party security audit. You can install it with: npm install -g keyclasp@beta The README has a walkthrough using a dummy credential in a temporary vault, so you can try it without touching real keys. It currently supports Apple Silicon Macs and glibc Linux on arm64/x64, with Node 24 or 26. It’s MIT licensed and began as a fork of Keyblind, created by Mohammed Aarif Shaikh. How are you handling credentials for local coding agents today? I’d be interested in approaches I missed and places where this workflow falls short.

Hi HN, I kept running into the same problem: either I’d have the agent give me the command, run it myself with the credentials, and copy-paste the output back, or I’d let the agent run it and keep finding secrets in its output.I looked into alternatives and asked friends, but the only workable approach I found for my workflow was writing custom wrappers around CLIs to handle authentication. I got tired of the back-and-forth, rotating leaked tokens, and maintaining wrappers, so I built Keyclasp. I've been using it for two months now and I don't see how could do without.Keyclasp stores credentials in a local encrypted vault. The agent works with secret names and selects what a command needs: keyclasp run --project myapp --environment dev --env API_KEY -- npm test The child process receives the requested token through its environment. The agent can list available secret names, but cannot retrieve the values. I also include a skill that explains the workflow. You can optionally require operator authorization when passing secrets. Everything is local and open source.The command still needs to be trusted: it receives the real credential and can write it to disk or send it over the network. Keyclasp doesn’t sandbox commands or isolate secrets from other processes running as your OS user.An output guard scans stdout and stderr for exact injected values of at least eight characters. If it detects one, it redacts the match, stops forwarding output, and attempts to terminate the process group. Shorter values, encoded values, and fragments are outside that protection. Keyclasp was built by me and didn't have a professional third-party security audit.You can install it with:npm install -g keyclasp@betaThe README has a walkthrough using a dummy credential in a temporary vault, so you can try it without touching real keys. It currently supports Apple Silicon Macs and glibc Linux on arm64/x64, with Node 24 or 26.It’s MIT licensed and began as a fork of https://keyblind.dev/, created by Mohammed Aarif Shaikh.How are you handling credentials for local coding agents today? I’d be interested in approaches I missed and places where this workflow falls short. Comments URL: https://news.ycombinator.com/item?id=49603278 Points: 1 # Comments: 0