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?
show comments
e12e
> 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?
show comments
zimbatm
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?
show comments
sjdv1982
What if kontext runs under the same user as Claude? Could it in principle inspect the kontext process and extract the key from memory?
show comments
amjd
Congrats on the launch! What are the key advantages of this compared to OneCLI[1]?
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!!
airstrike
Really cool and much needed!
I was actually just about to get started writing this but in Rust....
show comments
0xOsprey
Yup I needed this bad for my NanoClaw
Nice work
show comments
measurablefunc
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...
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?
> 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?
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?
What if kontext runs under the same user as Claude? Could it in principle inspect the kontext process and extract the key from memory?
Congrats on the launch! What are the key advantages of this compared to OneCLI[1]?
[1]: https://github.com/onecli/onecli
Sounds awfully similar to Tailscale Aperture[1]
[1] https://tailscale.com/blog/aperture-self-serve
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....
Yup I needed this bad for my NanoClaw
Nice work
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...
Can I integrate this with my coding agents?