Very cool project. Providing credentials agents and standardizing that whole process seems like valuable work. Question though on the OSS/paid boundary... is the OSS cli the client for the paid service? What is the custody model? Does this service store all my credentials?
From another comment:
> Kontext holds secrets server-side and mints short-lived tokens per session.
That probably makes this thing DOA for most people (certainly for me and everyone I know).
Thanks. Yes, I would have to put myself in that category. Typical play here is to offer the self-hosted option. Not sure if that is in the pipeline for the creators of this. Then you are into that trust/operational overhead tradeoff conversation.
[flagged]
What do you anticipate to be the hardest part of supporting a self-hosted solution? I've worked a fair bit on converting SAAS -> self-hosted and always interested to hear others' pain points.
I imagine a lot of the organizations that would find this most valuable, and would be willing to pay a lot, would be the same ones that would require something like this.
[flagged]
Currently we can use Bitwarden either hosted or self-hosted, which solves most of these problems (plus my own extra rig I built to generate OAuth tokens, for people which support that).
Could you elaborate on what challenges you face that can't be solved by the Bitwarden approach?
[flagged]
> for static API keys, the backend injects the credential directly into the agent's runtime environment.
What prevents the agent from presisering or leaking the API key - or reading it from the environment?
[flagged]
Congrats on the launch! What are the key advantages of this compared to OneCLI[1]?
[flagged]
Does this work with any tool calls that make an HTTP request? e.g. calling `curl` directly vs writing a script to make the request, then calling it
[flagged]
What if kontext runs under the same user as Claude? Could it in principle inspect the kontext process and extract the key from memory?
If they use the system keyring, it depends on the OS and other details - MacOS, Linux, and Windows all have different implementation tradeoffs.
This is how keychains should be designed. Never return the secret, but mint a new token, or sign a request.
We need this also for normal usage like development environments. Or when invoking a command on a remote server.
Are you going to add support for services that don't support OIDC or this going to be a known limitation?
[flagged]
Sounds awfully similar to Tailscale Aperture[1]
[flagged]
Finally a solution which focuses on contextual authorization - evaluating the agent's reasoning trace when it requests a credential, only issuing it if the intent matches what the user authorized.. developer-focused and self-serve.Happy Launch day!!
Really cool and much needed!
I was actually just about to get started writing this but in Rust....
[flagged]
Yup I needed this bad for my NanoClaw
Nice work
[flagged]
It should be possible to do this w/ eBPF. Monitor network i/o & rewrite the request on the fly to include the proper tokens & signatures. The agent can just be given placeholder tokens. That way all the usual libraries work as expected & the secrets/signatures are handled w/o worrying about another abstraction layer. Here is some prior art: https://riptides.io/blog/when-ebpf-isnt-enough-why-we-went-w...
[flagged]
Can I integrate this with my coding agents?
[flagged]
[flagged]
[flagged]
[flagged]