Show HN: Kontext CLI – Credential broker for AI coding agents in Go | AI Paper Digest

TL;DR Highlight

This open-source CLI tool securely injects short-lived tokens into AI coding agents when accessing external services like GitHub, Stripe, and databases, avoiding the exposure of long-term API keys. It's gaining attention as a replacement for the risky practice of copy-pasting keys into .env files.

Who Should Read

Developers or team leads who have deployed AI coding agents like Claude or Copilot but are concerned about API key management. Specifically, backend/DevOps engineers who need to grant agents access to external services and want to reduce security risks.

Core Mechanics

AI coding agents need access to external services like GitHub, Stripe, and databases, but most teams currently copy and paste long-term API keys into .env files. This approach carries a high risk of key leakage and lacks governance.
Kontext CLI solves this problem by acting as a 'Credential Broker'. Agents don't directly hold keys; instead, they receive short-lived tokens at session start, which automatically expire at the end of the session.
By declaring the credentials a project needs in a `.env.kontext` file, the CLI replaces placeholders with actual short-lived tokens using the RFC 8693 Token Exchange standard when the `kontext start` command is executed, then runs the agent.
Every Tool Call made by the agent is streamed to the Kontext dashboard and recorded for audit and governance purposes. You can track which agent accessed which service and when.
For static API keys (services that don't support OIDC), the backend directly injects the keys into the agent's runtime environment. However, it was noted that the keys could still be readable within the agent's environment.
Installation is simple with `brew install kontext-security/tap/kontext`, and direct binary installation is also supported from GitHub Releases. It's an open-source project written in Go.
The OSS CLI appears to function as a client for a paid backend service. There have been many questions from the community about the credential storage model and the boundary between OSS and paid features, but an official answer remains unclear.

Evidence

Questions were raised about whether the OSS CLI is a client of a paid service and whether credentials are stored on the Kontext server. Concerns were expressed about the lack of transparency in the custody model (where my keys are stored), and opinions were shared that a clear trust model is necessary for a security tool.
In response to the explanation that static API keys are directly injected into the agent's runtime environment by the backend, a counterargument was made: 'Then what prevents the agent from reading and storing or leaking the key from the environment variable?' A deeper security concern was also raised that if the agent process runs with the same user privileges, the key could be extracted from the kontext process memory.
Comments compared it to projects with similar approaches, such as Tailscale Aperture and OneCLI. Questions were asked about the differentiators, indicating that competition in this area has begun.
An alternative idea using eBPF was suggested. By monitoring network I/O and intercepting requests, tokens and signatures could be injected at runtime, allowing agents to only be given placeholder tokens and eliminating the need for additional abstraction layers.
The context-based authorization feature – 'issuing credentials only when the intention of the agent's reasoning trace matches what the user has authorized' – received attention. This feature was evaluated as a key differentiator from existing solutions.

How to Apply

If you need to give an AI coding agent like Claude or Cursor access to the GitHub API or Stripe keys, declare the necessary credentials in a `.env.kontext` file and run the agent with `kontext start` to operate with session-limited tokens without exposing long-term keys.
If you're using AI agents as a team and need audit logs of who accessed which services, leverage Kontext's dashboard streaming feature to record all Tool Calls and establish a governance system.
If you need to allow agent access to legacy services (internal APIs, older SaaS, etc.) that don't support OIDC, use Kontext's static key injection method, but additionally review sandboxing to prevent the agent from directly reading environment variables.
If you're interested in an eBPF-based approach, refer to the riptides.io case mentioned in the comments to explore the option of replacing tokens at the network layer without modifying the agent code.

Code Example

snippet

# Installation
brew install kontext-security/tap/kontext

# Or direct binary installation (macOS ARM)
tmpdir="$(mktemp -d)" \
  && gh release download --repo kontext-security/kontext-cli \
     --pattern 'kontext_*_darwin_arm64.tar.gz' \
     --dir "$tmpdir"

# Declare necessary credentials in .env.kontext file and run agent
kontext start

Terminology

Credential BrokerA component that acts as an authentication intermediary between the agent and external services. The agent does not directly possess keys but requests temporary access from the broker.

RFC 8693 Token ExchangeAn OAuth 2.0 extension standard that defines how to exchange existing tokens for different types of tokens (e.g., short-lived tokens, scope-limited tokens). Here, it's used to replace placeholders with actual short-lived credentials.

OIDCShort for OpenID Connect. An authentication protocol built on top of OAuth 2.0 that standardizes how to prove 'who this person/service is'. Services that support it can issue short-lived tokens instead of long-term API keys.

Tool CallAn action taken by an AI agent to perform an external function (reading a file, calling an API, executing code, etc.). It's any action the agent takes beyond simple text generation.

eBPFA technology that allows you to write programs that run safely in the Linux kernel. It can be used to intercept or modify network packets, enabling low-level operations without modifying kernel code. Here, it's presented as an idea for injecting tokens without changing the agent code.

Reasoning TraceA record of the internal reasoning process an AI agent goes through before performing a task. Kontext uses this reasoning to determine whether the agent's intention aligns with the user's authorization before issuing credentials.

Show HN: Kontext CLI – Credential broker for AI coding agents in Go