Show HN: Kontext CLI – Credential broker for AI coding agents in Go(github.com)
github.com
Show HN: Kontext CLI – Credential broker for AI coding agents in Go
https://github.com/kontext-dev/kontext-cli
32 comments
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).
> 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.
mc-serious(1)
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...
> 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?
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?
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?
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!!
Congrats on the launch! What are the key advantages of this compared to OneCLI[1]?
[1]: https://github.com/onecli/onecli
[1]: https://github.com/onecli/onecli
mc-serious(1)
Sounds awfully similar to Tailscale Aperture[1]
[1] https://tailscale.com/blog/aperture-self-serve
[1] https://tailscale.com/blog/aperture-self-serve
Really cool and much needed!
I was actually just about to get started writing this but in Rust....
I was actually just about to get started writing this but in Rust....
The problem isn't just secret sprawl. It's that there's no lineage of access. You don't know which developer launched which agent, what it accessed, or whether it should have been allowed to. The moment you hand raw credentials to a process, you've lost the ability to enforce policy, audit access, or rotate without pain. The credential is the authorization, and that's fundamentally broken when autonomous agents are making hundreds of API calls per session.
Kontext takes a different approach. You declare what credentials a project needs in a .env.kontext file:
Then run `kontext start --agent claude`. The CLI authenticates you via OIDC, and for each placeholder: if the service supports OAuth, it exchanges the placeholder for a short-lived access token via RFC 8693 token exchange; for static API keys, the backend injects the credential directly into the agent's runtime environment. Either way, secrets exist only in memory during the session — never written to disk on your machine. Every tool call is streamed for audit as the agent runs.
The closest analogy is a Security Token Service (STS): you authenticate once, and the backend mints short-lived, scoped credentials on-the-fly — except unlike a classical STS, we hold the upstream secrets, so nothing long-lived ever reaches the agent. The backend holds your OAuth refresh tokens and API keys; the CLI never sees them. It gets back short-lived access tokens scoped to the session.
What the CLI captures for every tool call: what the agent tried to do, what happened, whether it was allowed, and who did it — attributed to a user, session, and org.
Install with one command: `brew install kontext-dev/tap/kontext`
The CLI is written in Go (~5ms hook overhead per tool call), uses ConnectRPC for backend communication, and stores auth in the system keyring. Works with Claude Code today, Codex support coming soon.
We're working on server-side policy enforcement next — the infrastructure for allow/deny decisions on every tool call is already wired, we just need to close the loop so tool calls can also be rejected.
We'd love feedback on the approach. Especially curious: how are teams handling credential management for AI agents today? Are you just pasting env vars into the agent chat, or have you found something better?
GitHub: https://github.com/kontext-dev/kontext-cli Site: https://kontext.security