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...
Workflow: OneCLI runs as a self-hosted Docker gateway — you route agent traffic through localhost:10255. Kontext doesn't change how you use Claude Code at all, just kontext start --agent claude.
Visibility layer: OneCLI intercepts outbound HTTP requests. Kontext hooks into Claude's PreToolUse/PostToolUse events, so you see bash commands, file ops, and API calls and not just network traffic.
Trust model tradeoff worth naming: OneCLI is fully self-hosted. Kontext holds secrets server-side and mints short-lived tokens per session. We do this via token exchange, RFC 8693, and natively build upon Oauth to support only handing over short-lived tokens - you don't need to capture refresh tokens for external tool calls at all.
Yes, with one important distinction: our visibility is at the agent tool boundary, not the raw network layer.
So if Claude Code invokes Bash and runs curl ..., we see that tool invocation. If it invokes Bash and runs python script.py, and that script makes HTTP requests internally, we still see the Bash invocation.
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!!
Thanks for flagging - wasn't aware of Aperture! It's a little different to what the Kontext CLI does though.
Aperture solves “make multiple coding agents talk to the right LLM backend through an Aperture proxy.” We solve “launch a governed agent session with identity, short-lived third-party credentials, and tool-level auditability.” They overlap at the launcher layer, but the security goals are different.
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?
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...
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
Great question. Two main differences:
Workflow: OneCLI runs as a self-hosted Docker gateway — you route agent traffic through localhost:10255. Kontext doesn't change how you use Claude Code at all, just kontext start --agent claude.
Visibility layer: OneCLI intercepts outbound HTTP requests. Kontext hooks into Claude's PreToolUse/PostToolUse events, so you see bash commands, file ops, and API calls and not just network traffic.
Trust model tradeoff worth naming: OneCLI is fully self-hosted. Kontext holds secrets server-side and mints short-lived tokens per session. We do this via token exchange, RFC 8693, and natively build upon Oauth to support only handing over short-lived tokens - you don't need to capture refresh tokens for external tool calls at all.
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
Yes, with one important distinction: our visibility is at the agent tool boundary, not the raw network layer.
So if Claude Code invokes Bash and runs curl ..., we see that tool invocation. If it invokes Bash and runs python script.py, and that script makes HTTP requests internally, we still see the Bash invocation.
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....
Nice! I'd love to hear what you think about our approach, and what features you'd like to see first.
Sounds awfully similar to Tailscale Aperture[1]
[1] https://tailscale.com/blog/aperture-self-serve
Thanks for flagging - wasn't aware of Aperture! It's a little different to what the Kontext CLI does though.
Aperture solves “make multiple coding agents talk to the right LLM backend through an Aperture proxy.” We solve “launch a governed agent session with identity, short-lived third-party credentials, and tool-level auditability.” They overlap at the launcher layer, but the security goals are different.
Yup I needed this bad for my NanoClaw
Nice work
Can I integrate this with my coding agents?