Alexander Tibbets

Latchkey - Credential layer for local AI agents

Getting your agent authenticated with third-party services shouldn't require a custom connector for each one. Add Latchkey once and agents prepend latchkey to standard curl calls. Credentials are detected and injected automatically. They're stored encrypted on your machine, and never show up in logs or chat transcripts. 25+ services supported out of the box. Register any HTTP API at runtime. Works with Claude Code, OpenCode, Codex, and more. Open source software by Imbue.

Add a comment

Replies

Best
Alexander Tibbets
Imbue's engineers have been thinking about a problem that didn't have a clean solution yet: How do local AI agents authenticate with third-party services? Without making it painful for the developer, the end user, or anyone's privacy? MCP servers work, but you need one for every service. Centralized connectors work, but now a third party sits between your agent and your data. Manual token management works, until you hand the tool to someone non-technical. Latchkey was built to cut through that.
Rohan Chaubey

@mrtibbets Congrats on getting this out! How Latchkey handles rate limiting when multiple agents are hitting the same service with shared auth?

Hynek Urban

@rohanrecommends Latchkey is a transparent credentials layer; as such, it passes raw responses back to the requester without attempting to handle app-specific errors. Depending on the situation, it may sometimes make sense to share auth across many agents, while other times you may want to use isolated Latchkey instances to keep auth separate. There's an environment variable (LATCHKEY_DIRECTORY) that can be overridden to completely isolate Latchkey instances if desired (thus letting you use different tokens with different agents).

Gabriel P.

sent this to a couple of engineers i know who are building local agent setups. they've been duct-taping credential management together for months, this is right up their alley.

Alexander Tibbets

@gabrielpineda amazing. This is just the type of feedback we love to hear and it's why we build the way we do. Thank you for paying it forward!

Hynek Urban

@gabrielpineda That is indeed great to hear. We'd love to help with any pain points if they come up (it would be a great learning opportunity for us, too).

Mykola Kondratiuk

The credentials never showing up in logs or chat transcripts detail is the actually important thing here. I've seen agent setups where the auth storage is secure but the credential ends up in tool call output anyway - solved the wrong problem. Does token rotation work automatically? If a service refreshes the token mid-session does latchkey pick that up, or does the agent need to restart?

Hynek Urban

@mykola_kondratiuk Really glad that resonates :) The credentials lifecycle is not connected to the agent lifecycle so you wouldn't need to restart agents. Supported services that work with the standard access token + refresh token pair should "just work".

Mykola Kondratiuk

@hynek_urban That's the key detail - decoupled credential lifecycle means the agent can keep running across token refreshes. Makes Latchkey much more practical for long-running workflows.

Ben Gendler

I use Claude Code and Cursor daily and I've learned that you can't just trust the output blindly - agents will tell you they implemented something and you'll find out later it was half done or the tests were never actually run. How does Vet handle cases where the agent made a reasonable interpretation of an ambiguous request? Does it flag those as potential issues or only catch clear deviations?

Alexander Tibbets

@ben_gend hey hey I think you may have intended to post your question and comment on Vet's page, here: https://www.producthunt.com/products/imbue-7/launches/vet-2 😊