open·kritt: a self-hosted orchestrator for AI vulnerability research

Who open·kritt is for, and the failure it is built around

The README states the problem plainly: pointing a model at an entire repository and asking it to find vulnerabilities rarely works well. The alternative open·kritt implements is to break research into small, well-defined tasks, run them across agents in parallel, and combine the output into findings that can be validated and prioritized. That framing matters because it defines the audience. This is not a scanner you point at a checkout and forget. It is a workflow builder for people who already know what a prompt should ask and want that prompt to run the same way every time.

The stated audience is security researchers and security-minded developers who want control over prompts, workflows, model providers and infrastructure. The repository carries topics such as bug-bounty, hackerone, immunefi and security-research, and the README describes the project as the open-source distillation of the internal work behind the Kritt team's bug-bounty payouts under the researcher name Blockian. Treat that as positioning rather than evidence: the payout figure is the team's own claim, and it says nothing about how well the tool performs on your codebase.

How the workflow, engine and disposable job containers fit together

The pieces are visible in the top-level layout. A frontend and a backend run as separate services, PostgreSQL stores state, and an engine directory sits alongside them. The docker-compose.yml file shows the frontend proxying relative /api requests to the backend at http://backend:3002, with VITE_PROXY_TARGET defaulting to that address. The backend receives DATABASE_URL and a set of presence flags rather than raw keys: OPEN_KRITT_CODEX_API_KEY_CONFIGURED, OPEN_KRITT_OPENAI_API_KEY_CONFIGURED, OPEN_KRITT_ANTHROPIC_API_KEY_CONFIGURED, OPEN_KRITT_OPENROUTER_API_KEY_CONFIGURED and OPEN_KRITT_XAI_API_KEY_CONFIGURED. The compose file comments explain the split: raw environment keys stay in the engine, while the backend gets non-secret presence flags and manages the shared login and key stores used by Accounts.

Scanning happens in disposable job containers. The README states that tool-enabled agents run as root inside those containers, with writable repository copies and direct internet access, so they can install tools, compile targets, run tests and build proofs of concept. That design is what makes the tool useful for real research and also what makes it dangerous: an agent that can install packages and reach the network is executing untrusted code paths against untrusted code. The README points to docs/threat-model.md and tells you to run the stack on a dedicated Docker host or VM.

De-duplication and ranking sit above the agent output. The README lists custom severity rankers, a consistent finding schema and automatic de-duplication, which is the part that turns parallel agent noise into something a human can triage. Export packages canonical findings, structured data, post-processing output, reports and proofs of concept into one ZIP with a share-safe manifest. Completed scans produce complete exports; stopped or failed scans that still have findings produce clearly marked partial exports, and attacker-influenced report and PoC source is kept as plain text.

Installing open·kritt and running a first scan

The README lists the prerequisites as Git, Docker with Docker Compose, and Node.js 20 or newer. The repository-local CLI has no install step, so the commands below are the documented path from clone to a running stack. The setup command walks through the available logins and API keys; you only need one model-access option.

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt
./kritt setup
./kritt start

Once the stack is running, the README says to open http://localhost:5173. On a server without a browser or desktop, leave the stack running and open another shell. The headless CLI 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.

./kritt-headless

Configuration lives in .env.example. The defaults bind frontend and backend to 127.0.0.1 on ports 5173 and 3002, with PostgreSQL on 5432 and the executor view on 8090. Local repositories are bind-mounted: LOCAL_REPOS_PATH defaults to ./local_repos and appears inside the containers at /local_repos, so dropping a repo folder on the host makes it visible live. A GITHUB_TOKEN is optional and only needed for private GitHub repositories.

The security posture you are accepting

Two statements in the README should decide where you deploy this. The default ports bind to 127.0.0.1, and the backend does not include application authentication. The README's own instruction is to keep the stack private. There is no login screen to hide behind, so exposing the frontend port to a network is equivalent to handing over the scan engine and its provider credentials.

The second statement is about the job containers. Agents run as root, with writable repository copies and direct internet access. That is a deliberate capability, not an oversight: compiling a target and building a proof of concept requires it. But it means a scan of hostile code is a scan of hostile code inside your Docker host, and the README's answer is isolation at the host level. The compose file also encodes a storage guard. ENGINE_MIN_FREE_STORAGE_GB defaults to 20 and the comment says no new per-job scan container starts below that amount of free storage; ENGINE_IGNORE_LOW_STORAGE can disable the safeguard, and the comment warns this can allow the host disk to fill. Builds and scan containers accumulate, so that threshold is the only thing standing between a long research session and a full disk.

Where open·kritt is the wrong tool

If you want a scanner that runs in CI on every pull request with a stable rule set, this is not it. open·kritt is organized around workflows and prompts you author, and its output depends on the model access you configure. Two teams with different prompts and different providers will not get the same findings from the same repository, which is a poor fit for a gate that has to be reproducible and explainable to whoever is blocked by it.

It is also a poor fit for anyone who cannot dedicate a host. The README asks for a dedicated Docker host or VM, the backend has no application authentication, and agents run as root with network access. Running it on a shared development machine or a laptop that also holds credentials is the scenario the threat model is written against. And if your constraint is that source code must never reach a third-party model provider, the provider list is the whole story: Codex, OpenAI, Anthropic, OpenRouter and xAI are the documented options, so the decision is about which of those you trust rather than whether to use one.

How it differs from Semgrep and CodeQL

Semgrep and CodeQL are the obvious comparison points, and the difference is in what produces a finding. Those tools evaluate rules or queries against code and return matches that a human then interprets. Their results are deterministic given the same rule set and the same revision, and the work of writing the rules is the work of encoding what you already know about a class of bug.

open·kritt inverts that. The unit of work is a prompt step, chained into a workflow, executed by an agent that can install tools, compile the target and run tests while it reasons. That lets it pursue hypotheses a static rule cannot express, and the README's de-duplication and severity ranking exist precisely because parallel agents produce overlapping, uneven output. The cost is that you are now maintaining prompts and choosing providers, and the correctness of a finding depends on the validation step you configure. A rule engine tells you why it matched. An agent tells you what it concluded, and open·kritt's answer to that is the post-script stage that validates issues and builds proofs of concept.

Licence, releases and what upgrades cost

open·kritt is licensed under AGPL-3.0, and the LICENSE file sits at the repository root. The practical consequence for a self-hosted tool is the network clause: if you modify the software and let users interact with it over a network, the AGPL's source-availability obligation is the question your legal team will want to answer, not something this article can settle. Running it unmodified for internal research is the straightforward case.

Release cadence is visible in the repository. v1.4.1 was tagged on 2026-08-16, v1.4.0 on 2026-08-12, and v1.3.0 on 2026-08-04, and the last push to the default branch was on 2026-09-09. The presence of .release-please-manifest.json and release-please-config.json indicates releases are automated from Conventional Commits, and CONTRIBUTING.md documents those commit requirements. The compose file builds the frontend and backend from local Dockerfiles rather than pulling published images, so an upgrade is a git pull followed by a rebuild, and the frontend service bind-mounts ./frontend over /app with a separate /app/node_modules volume. Expect to rebuild images and re-run migrations on each upgrade, and check CHANGELOG.md before pulling.

Editorial conclusion

Adopt open·kritt if you already write your own security prompts and want them versioned as workflows, with de-duplicated findings and a ZIP export you can hand to a triage process. Skip it if you need application authentication in front of the UI or you cannot give the stack an isolated Docker host, because the README states the backend has no application authentication and tool-enabled agents run as root with direct internet access. Before pointing it at anything, read docs/threat-model.md, confirm the free-storage threshold in ENGINE_MIN_FREE_STORAGE_GB, and check whether AGPL-3.0 fits how you intend to distribute any modified version.

Frequently asked questions

Official sources

1. Kritt-ai/open-kritt on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases