Launched this week
keychains.dev
Give AI access to 6754+ APIs with zero credentials exposed
437 followers
Give AI access to 6754+ APIs with zero credentials exposed
437 followers
Keychains.dev is a secure credential proxy for AI agents. Use "keychains curl" as a drop-in for curl — just replace hard-coded credentials with template variables like {{GITHUB_TOKEN}}. Keychains injects real credentials server-side. Your agent never sees raw secrets — immune to prompt injection by design. Users approve each permission with one click and can revoke access anytime. Full audit trail. Works with 11,000+ API providers (OAuth, API keys, basic auth).
Huge congrats on launch! Love the secure proxy model and zero‑secret agent design.
keychains.dev
Thanks @elior_1 !
Sketchfab
@albn Hi Alban, this tackles one of the biggest blockers for agent adoption. Giving agents raw API keys has always felt like crossing a line.
Injecting credentials server side while keeping them out of the agent’s context is a smart trust layer. This makes real world agent workflows much more viable.
I’m building Ahsk app , a macOS AI assistant focused on secure, in flow AI use. Would love to connect and exchange feedback.
Product Hunt
keychains.dev
@curiouskitty That's a great question. Got the same feedback from a few users past Wednesday. What I did for now is that I split the credentials pipeline from the data pipeline and open sourced the proxy so you can deploy your own proxy as a user. I called it "Satellite proxy" --> you host your own copy of our proxy on Vercel, it's the only one seeing request bodies and response data, and it calls keychains.dev only to resolve credentials.
I imagine I could do the same kind of trick to let you store your own API keys (except OAuth) so they never touch our servers.
If you have better ideas on this I'd love to implement them!
@curiouskitty @severin__ Vault and Secrets Manager assume trusted consumers. Agents run tool calls shaped by prompts, so protection has to happen at use-time. Server-side curl injection that keeps secrets out of the context window solves the right problem.
Here's the design split that matters... credential resolution on keychains.dev, request bodies on your own Vercel. Data sovereignty without losing managed auth. One edge: if the Satellite handles OAuth refresh locally, it re-introduces credential-at-rest. Routing that refresh through keychains.dev while keeping payloads local keeps the boundary clean.
Tugan.ai
good luck with your launch ! @severin__
keychains.dev
Thank you @baptiste1 !
Buildrs
Nice product ! Keep building
keychains.dev
@dagher_jade Thanks!
This is a great idea. Have you thought about expanding it to also support traditional website passwords, so agents couldn’t access those either? Curious whether you see this eventually replacing tools like 1Password, or staying focused purely on developer/API secrets.
keychains.dev
@bricohen I'd love to do websites passwords. A bit more tricky though.
IMHO the next step could be to offer website owners a SDK as simple to use as Clerk (and if possible, compatible) to offer safe agent-oriented login in browser --> would love to work on that!
keychains.dev
Thanks @albn !
I've made keychains.dev to be able to use the limitless power of AI agents like OpenClaw, without having afterthoughts about if it's properly keeping my passwords and credentials safe.
Feels more safer now.
@community I'd love your feedback on it. Let's make agents safe!