Kontext
Apply local policy to risky AI-agent actions before they execute.
Per-dimension scores and reasoning
The materials clearly describe local policy decisions, synchronous pre-action enforcement, observe and enforce modes, the authorization ledger, managed export, and an uninstall path. CI uses read-only permissions, pins third-party actions to commits, and performs module verification, dependency review, and vulnerability scanning. Deductions apply because setup installs hooks, starts a daemon, and connects an organization without showing finer-grained installation authorization or per-action human confirmation; redaction is asserted without rules, failure behavior, or implementation evidence; rollback covers only mode changes and self-serve uninstall; and publisher identity is unknown while copyright attribution is only to generic “Kontext contributors.”
The README, module manifest, security policy, and CI workflow are internally consistent. CI specifies builds, vetting, race-enabled tests, a smoke test, local end-to-end testing, and vulnerability checks. Deductions apply because static evidence cannot establish availability or offline degradation for the dashboard, Homebrew tap, module sources, or organization service. Doctor reports unhealthy installations through a nonzero exit, but concrete diagnostic messages, recovery categories, and common failure examples are absent.
The repository identifies developers, security and platform teams, auditors, and incident investigators, with concrete scenarios for each. It carefully separates observe from enforce behavior, event receipt from blocking capability, and semantic policy from kernel sandboxing. The support table specifies agents, events, and synchronous hook boundaries. The deduction is for environment fit: self-serve setup is macOS-only, while Cowork, managed, and cloud lifecycle, storage, and hook integration are described only at a high level.
The README has strong organization across quickstart, modes, data boundaries, support coverage, diagnostics, development, and community resources. Product and command naming are stable, limitations are unusually explicit, and the full MIT license is present. Deductions apply because dashboard-token and Codex-hook prerequisites lack fuller configuration examples and troubleshooting FAQs; release badges and a latest-version support statement are present but no changelog or migration guidance is supplied; and support, security, and contact routes exist without a named maintainer roster, response commitment, or verified publishing responsibility.
Authorization-ledger records, allow/would-deny/deny outcomes, installation health checks, and organization-level review of redacted evidence are directly usable outputs. The distinction from ordinary logs and process sandboxes demonstrates meaningful marginal value. The cost-benefit score is reduced because latency, storage, maintenance burden, false-positive rates, deployment complexity, and commercial cost are not quantified.
Claims are tied to named documentation areas, commands, and CI workflows, and the text carefully separates supported facts from non-claims: it disclaims kernel isolation, model-reasoning capture, and universal blocking. Deductions apply because the central interception, redaction, and ledger-security claims are primarily stated in the README; the supplied evidence does not include their implementation code, test bodies, or the referenced coverage and guard documents, limiting traceability and independent cross-source corroboration.
- This assessment uses only the supplied static files; no build, test, installation, policy interception, or vulnerability scan was executed.
- The key implementations for sensitive-value redaction, ledger protection, and enforcement are not included in the evidence and should be reviewed with their tests before production adoption.
- Observe mode does not stop actions that policy would deny; actual blocking coverage for each agent and event surface should be validated before enabling enforcement.
- Self-serve setup installs agent hooks, starts a local daemon, and connects to a managed organization; verify token scope, retention, export destinations, and residual state after uninstall.
- Kontext is not kernel-level isolation, so filesystem, credential, and network threat models still require an independent sandbox or operating-system controls.
What does this agent do, and when should you use it?
Kontext is a Go-based runtime authorization and audit system for Claude Code, Claude Cowork, and Codex. Once installed, it receives supported session and tool events through agent hooks and evaluates deterministic policy in a local Kontext runtime before consequential actions proceed. Teams can begin in observe mode, which records decisions without interruption, and move supported synchronous boundaries into enforce mode when policies are ready. The local authorization ledger can associate an agent and session with its requested action, applicable policy, decision, and available outcome, while sensitive values are redacted before storage or managed export. Self-service setup currently targets macOS, while managed deployments add centralized policy distribution, identity controls, redacted evidence export, retention, and deployment-health monitoring.
Running kontext setup stores an installation token in the macOS login keychain, installs hooks for supported agents, starts the local Kontext daemon, and connects the installation to a Kontext organization. When Claude Code, Claude Cowork, or Codex emits a supported session, prompt, or tool event, the hook sends it to the local runtime, which evaluates the tool name, available input, and relevant policy. The result is allow, would deny, or deny: observe mode records a would-deny decision while letting the action continue, whereas enforce mode can return a denial at a supported synchronous pre-tool-use boundary. Kontext records available event, policy, decision, attribution, and outcome evidence in its authorization ledger and redacts sensitive values before local storage or managed export. The kontext doctor command checks installed hooks, daemon health and version, managed-export health, and the pending export backlog, returning a nonzero status for an unhealthy configured installation.
- A security team introducing coding agents can run observe mode first to inventory tool calls, sensitive-file access, and policies that would disrupt legitimate development.
- A platform team granting Codex or Claude Code access to production systems can deny destructive commands, credential access, or production operations at supported pre-action hooks.
- An incident responder can use ledger evidence to connect a specific agent and session with the requested action, matching policy, authorization decision, and available result.
- A compliance team that needs organization-wide authorization evidence can use managed policy rollout, redacted record export, and audit retention.
- A development team that wants to keep its existing Claude Code or Codex workflow can install Kontext once and continue launching the agent normally without a wrapper command.
What are this agent's strengths and limitations?
- Policy evaluation and the synchronous decision path remain local to the agent environment; a hosted service does not need to answer every tool call.
- Separate observe and enforce modes support a measured rollout before policies begin interrupting developers.
- The ledger links requested actions, policy decisions, and available outcomes, providing more explicit authorization evidence than post-event tool logs alone.
- Claude Code and Codex can continue to be used normally after installation without a per-launch wrapper command.
- The documented model distinguishes event visibility from actual blocking coverage and explicitly avoids claiming kernel-level isolation.
- Self-service setup currently supports only macOS and depends on Homebrew, the macOS login keychain, and a dashboard-issued installation token.
- Real blocking is limited to supported synchronous pre-action events where the agent waits for Kontext; receiving an event does not make every action enforceable.
- Codex users must trust the installed hooks, while Claude Cowork requires hook configuration inside the Cowork environment.
- Kontext is not a process, filesystem, or network sandbox, so stronger containment requirements need a separate sandbox.
- It does not capture model reasoning or reconstruct complete conversation history, limiting investigations to tool activity, decision evidence, and available outcomes.
How do you install or deploy this agent?
Self-service installation requires macOS, Homebrew, and an install token created in the Kontext dashboard.
- Install the CLI:
brew install kontext-security/tap/kontext - Create an install token at
https://app.kontext.security. - Run
kontext setupto store the token, install agent hooks, start the local daemon, and connect the installation to the organization. - Verify it with
kontext doctor. - For Codex, trust the installed hooks inside Codex.
Managed and cloud environments may run the same local runtime if they provide a supported hook contract, storage, and daemon lifecycle. Source development uses Go 1.25 and can be built with go build -o bin/kontext ./cmd/kontext.
How do you use this agent?
After kontext setup, launch and use Claude Code or Codex normally; there is no separate Kontext wrapper command. Start with observe mode so actions continue while the ledger reveals which policies would deny them, which repositories or systems are involved, and where enforcement would interrupt valid work. Move a boundary into enforce mode only after validating the policy and confirming that the corresponding event surface supports synchronous blocking. Run kontext doctor for routine health checks and kontext doctor --fix when a self-service daemon is stale. Run setup again to rotate the installation token, or use kontext setup --uninstall to remove the self-service installation. Enforcement and event coverage differ by agent and should be checked against the agent support matrix.
How does this agent compare with similar options?
A process sandbox controls which files, network destinations, credentials, and operating-system resources a process can physically access. Kontext instead decides whether an identified agent action is authorized under policy and records attributable evidence at supported hooks; the two controls are complementary. Compared with agent log collection alone, Kontext can make an authorization decision before a supported consequential action executes and link that decision to the available outcome rather than merely reporting a tool call afterward.
FAQ
Can Kontext block every action an agent takes?
Do I need to change how I launch Claude Code or Codex?
kontext setup installs the hooks and starts the daemon, the agents can be used normally without a wrapper command. Codex requires the hooks to be trusted.What information does Kontext retain?
What happens when an installation becomes unhealthy?
kontext doctor to inspect hooks, daemon health and version, managed-export health, and pending backlog. It exits nonzero for an unhealthy configured installation, and kontext doctor --fix can repair a stale self-service daemon.