alban

keychains.dev - Give AI access to 6754+ APIs with zero credentials exposed

by
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).

Add a comment

Replies

Best
alban
Hunter
📌
Hey Product Hunt! Happy to be hunting Keychains.dev today. **Clawbot** and **OpenClaw** are incredible tools for giving AI agents real-world capabilities. But they both share the same concern: **"Wait, the agent has my raw API keys?"** Prompt injection, leaked context windows, malicious plugins — once your credentials are in an agent's memory, you've lost control. A lot of people hold back from adopting agentic workflows because of this. **Keychains.dev** solves exactly this problem with an elegant approach: Your agent uses `keychains curl` instead of `curl`. Instead of hard-coding secrets, you use template variables like `{{GITHUB_TOKEN}}`. Keychains injects the real credentials **server-side** — the agent never sees them. If you've been building with AI agents but felt uneasy about the security side, this is the missing piece. It's the kind of trust layer that makes the whole agentic ecosystem viable. Give it a try — would love to hear what you think!
Mahesh Yadav

@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.

Elior

Huge congrats on launch! Love the secure proxy model and zero‑secret agent design.

Severin Marcombes

Thanks @elior_1 !

Curious Kitty
How do you think about trust and privacy tradeoffs in the proxy layer—what data must you see to inject auth and provide an audit trail, and what design choices let teams keep request/response bodies out of your infrastructure?
Severin Marcombes

@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!

Severin Marcombes
@piroune_balachandran yep! Refresh done on keychains on first 401
Ian Rothfuss

Great tool! Though we could use some more guidance on how to setup for Shopify App OAUTH now that Shopify has deprecated static admin API keys in favor of temporary keys based on Client ID and Client Secret. Spent quite a long time playing around with it and best we can figure out we are either doing something wrong or Keychains is hardwired to use the old Shopify API key auth method. We ended up building a workaround wrapper for our worker to use, but would be nicer to have this work directly in Keychains! Appreciate any help you could provide and happy to provide more details on the Shopify use case if you need it. https://shopify.dev/docs/apps/build/authentication-authorization/client-secrets

Severin Marcombes

Hey @ian_rothfuss ,
Thanks for the feedback. Will look into it asap

Baptiste

good luck with your launch ! @severin__

Severin Marcombes

Thank you @baptiste1 !

Jade D

Nice product ! Keep building

Severin Marcombes

@dagher_jade Thanks!

Mykola Kondratiuk

Credential handling in AI agents is one of those things that looks fine in demos but breaks fast in prod. I've seen raw API keys just float through context windows more times than I'd like to admit. The prompt injection immunity part is what I find most interesting here - you can't inject what the model never had access to. Curious how you handle OAuth token refresh mid-task though? If a token expires while an agent is running a long job, does it just get a 401 or is there auto-refresh built in?

Severin Marcombes
@mykola_kondratiuk Thanks Mykola. Token refresh is done server side by the proxy. It attempts a refresh upon receiving a 401. If that fails the connection is disconnected and the agent gets a reconnect url to send you
Brian Cohen

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.

Severin Marcombes

@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!

Severin Marcombes

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!