open·kritt: a self-hosted harness for running AI agents against a codebase
Open-source, self-hosted AI vulnerability research tool that orchestrates agents to find and validate security issues in code.
At a glance
- What is it?
- open·kritt splits vulnerability research into small prompt-driven tasks, runs them in parallel across Codex or Claude Code, and merges the output into de-duplicated findings. It is a research orchestration layer, not a push-button scanner, and its threat model assumes you trust the machine it runs on.
- Who is it for?
- Adopt open·kritt if you already write your own security prompts and want a self-hosted place to chain them, run them in parallel, and de-duplicate the results against a fixed finding schema. Skip it if you need an authenticated, multi-tenant service or a scanner that produces a clean report from a cold repository with no prompt design on your part.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode open·kritt was built around
The README states the premise directly: pointing a model at an entire repository and asking it to find vulnerabilities rarely works well. That is a claim about context dilution, and it matches what anyone who has tried the naive version has seen. A whole-repo prompt produces a long list of plausible-sounding observations, most of which collapse on inspection, and none of which are ranked against each other.
open·kritt's answer is decomposition. Research is broken into small, well-defined tasks, those tasks run across AI agents in parallel, and their output is combined into findings that can be validated and prioritized. The target user is named in the same section: security researchers and security-minded developers who want control over their prompts, workflows, model providers, and infrastructure. That last clause is the real product boundary. If you do not want to author prompts, the orchestration layer has nothing to orchestrate.
The project is presented as the open-source distillation of an internal tool built by a team that reports over $1,500,000 in bug-bounty payouts under the researcher name Blockian. That provenance explains the shape of the feature set. De-duplication, severity ranking, and export manifests are the concerns of people who submit findings to bug-bounty platforms, not the concerns of people running a compliance scan.
Workflows, scans, and where post-scripts fit
The unit of work is a workflow: a chain of focused prompts assembled into a reusable playbook. A scan applies a workflow to a target, which the README describes as a remote or local repository plus its dependencies. Execution happens through Codex or Claude Code, so the agent runtime is an external dependency rather than something open·kritt implements.
What comes back is normalized. The README lists a consistent finding schema, automatic de-duplication, and custom severity rankers as separate capabilities, which implies findings from different prompt steps are merged into one canonical set rather than reported per step. Post-scripts are the validation stage: they run after the agent work and are used to validate issues, build proofs of concept, and produce reports. Keeping validation as a distinct step is the design decision that matters most here. An agent's claim and a validated issue are different objects, and the pipeline keeps them apart.
Export packages canonical findings, structured data, post-processing output, reports, and proofs of concept into a single ZIP with a share-safe manifest. The README distinguishes complete exports from partial ones: a stopped or failed scan that still produced findings yields a clearly marked partial export. It also notes that attacker-influenced report and PoC source is kept as plain text, which is a deliberate choice to avoid rendering untrusted content during export.
Getting the stack up, and the CLI that does not need a browser
Prerequisites are Git, Docker with Docker Compose, and Node.js 20 or newer. The CLI lives in the repository, so there is no install step for it:
git clone https://github.com/Kritt-ai/open-kritt cd open-kritt ./kritt setup ./kritt start
The UI is then at http://localhost:5173. Setup walks through model access. You need exactly one option: a Codex login, or an API key for OpenAI, Anthropic, OpenRouter, or xAI. A GITHUB_TOKEN is optional and only matters for private GitHub repositories.
On a machine without a browser, the README points to ./kritt-headless, run from a second shell while the stack stays up. Its documented scope is narrow and worth reading carefully: it imports portable workflow, post-script, skill, and ranker JSON, creates scans with the same backend validation as the web form, shows scan status, stages, and failure reasons, edits non-secret runtime settings, and exports finding bundles. It does not display finding contents in the terminal. That is a real constraint for anyone planning to drive open·kritt entirely over SSH, since triage still requires the web UI or an exported bundle.
The documentation site is previewed locally with npm install -g mint, then cd docs-site and npm run dev, serving on port 3001.
The threat model is the adoption decision
This is the part most readers will skim and the part that should stop them. Tool-enabled agents run as root inside disposable job containers. Those containers get writable copies of the repository and direct internet access, so agents can install tools, compile targets, run tests, and build proofs of concept. The README instructs you to run open·kritt on a dedicated Docker host or VM and to read docs/threat-model.md before scanning untrusted code.
The combination is deliberate and it is not a defect. An agent that cannot compile the target cannot validate a memory-safety finding, and an agent that cannot reach the network cannot pull a dependency. But it means the security posture of the host is the security posture of the tool. Default ports bind to 127.0.0.1, and the backend does not include application authentication. The README's instruction is to keep the stack private. There is no user model, no role separation, and no tenancy boundary to configure, so exposing the UI on a routable interface is not a hardening exercise, it is a different product.
Treat the root-in-container detail as a scope statement rather than a warning label. It tells you open·kritt is built for a researcher's own machine or a dedicated VM, not for a shared internal service that several teams log into.
Where open·kritt is the wrong tool
If you want a scanner that takes a repository and returns a report with no input from you, open·kritt inverts that. The workflow is the analysis. Prompt quality determines output quality, and the README offers no claim that a default workflow exists or that one ships that you can simply run. The documentation link for a first scan is titled Run your first scan and sits under a workflows section, which is consistent with the idea that you build the thing you run.
Cost and latency are also on you. Parallel agents calling frontier models on a large repository is an open-ended bill, and the README does not publish token budgets, per-scan cost estimates, or runtime figures. Nothing in the supplied material lets me say how long a scan takes or what it costs, and anyone evaluating this should measure that on their own target rather than trust a number.
There is also a validation gap worth naming. Post-scripts validate issues and build proofs of concept, but a PoC generated by an agent is evidence of a hypothesis, not proof that the issue is exploitable in your deployment. The pipeline separates claims from validated findings; it does not tell you whether the validation itself is sound.
Finally, the headless CLI's inability to show finding contents in the terminal means a CI-style integration would need to consume the exported bundle rather than read stdout.
How this differs from static analysis and from hosted AI review
Semgrep and CodeQL are the obvious comparison points, and the difference is in what produces a result. Those tools evaluate code against rules or queries that a human wrote and that a machine applies deterministically. Run the same rule set twice and you get the same matches. open·kritt runs prompts through a model, so the same workflow on the same commit can produce a different set of findings, and the de-duplication and ranking stages exist precisely because the raw output is noisy and non-deterministic.
That trade cuts both ways. Rule engines are strong on patterns that someone already thought to encode and weak on anything requiring reasoning across files, which is the space open·kritt is aimed at. But a rule engine gives you a stable baseline you can diff across commits. open·kritt does not, at least not from anything documented in the supplied material.
The second comparison is hosted AI code review, where a vendor runs the model and returns comments. open·kritt's difference is control: your prompts, your workflows, your model provider (Codex, OpenAI, Anthropic, OpenRouter, or xAI), and your infrastructure. The cost of that control is everything in the threat model section above. You are operating the agent runtime's blast radius yourself.
Licence, maintenance, and what to check before committing
open·kritt is licensed under AGPL-3.0. The practical consequence for most engineers is the network clause: if you modify the software and let users interact with it over a network, the licence's source-availability obligation is the thing to read, and it is a question for your legal team rather than for this article. Running an unmodified copy internally is a different situation from building a modified version into something you host for others. I am not giving legal advice here, only pointing at the clause that tends to matter.
Maintenance signals from the supplied material: releases v1.3.0, v1.4.0, and v1.4.1 landed between 2026-08-04 and 2026-08-16, and the last push to the default branch is dated 2026-09-09. That is a project shipping on a roughly weekly cadence in the recent window. The repository is not archived. Ownership is shared between two named maintainers, Harel Rom and Gabriel Balko, documented in OWNERSHIP.md.
The upgrade cost you should plan for is not the git pull. It is the workflow and ranker JSON you author. The headless CLI imports portable workflow, post-script, skill, and ranker JSON, which suggests these artifacts are meant to be portable across instances, but the material does not state whether a schema change in a future release breaks an existing workflow file. That is the first thing to verify against the release notes for v1.3.0 through v1.4.1 before you invest in a library of playbooks.
Second thing to verify: run ./kritt setup and confirm which provider path you are on, because a Codex login and an API key have different cost and rate-limit characteristics, and the README treats them as interchangeable access options without comparing them.
Editorial conclusion
Adopt open·kritt if you already write your own security prompts and want a self-hosted place to chain them, run them in parallel, and de-duplicate the results against a fixed finding schema. Skip it if you need an authenticated, multi-tenant service or a scanner that produces a clean report from a cold repository with no prompt design on your part. Before scanning anything you did not write, read docs/threat-model.md and confirm you are on a dedicated Docker host, because tool-enabled agents run as root in disposable containers with writable repository copies and direct internet access, and the backend ships without application authentication.
Community notes