keychains.dev
Give AI access to 6754+ APIs with zero credentials exposed
Start new thread
alban

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

by
Sketchfab
•
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.

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
Maker

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

Piroune Balachandran

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

Severin Marcombes
Maker
@piroune_balachandran yep! Refresh done on keychains on first 401
Elior

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

Severin Marcombes
Maker

Thanks @elior_1 !

Baptiste

good luck with your launch ! @severin__

Severin Marcombes
Maker

Thank you @baptiste1 !

Jade D

Nice product ! Keep building

Severin Marcombes
Maker

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

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

Austin GTM | Get your next 50k users!

Congrats on launching, @severin__. The secure approach to managing credentials is impressive. How do you plan to drive initial ?

Severin Marcombes
Maker
@austinelvis dunno yet let’s talk!
Severin Marcombes
Maker

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!