**open·kritt** is a self-hosted platform that orchestrates AI agents across a codebase to find security vulnerabilities, then de-duplicates, validates and ranks what they return. It is built for security researchers and security-minded developers who want control over their prompts, workflows, model providers and infrastructure. The repository was created on **20 July 2026** and has reached roughly **1,368 stars and 235 forks** in under three weeks, with three releases in that span — **v1.1.0** on 20 July, v1.2.0 on 23 July and **v1.3.0** on 4 August. It is AGPL-3.0 licensed with 7 contributors and 35 open issues. ## The Premise The README opens with the failure mode it exists to correct: pointing a model at an entire repository and asking it to find vulnerabilities rarely works well. Context gets diluted, findings arrive unranked and unverified, and the same issue comes back under three different descriptions. open·kritt breaks the research into small, well-defined tasks, runs them across agents in parallel, and combines the output into findings that can be validated and prioritized. The unit of work is a focused prompt, not a repository dump. ## Architecture | Layer | What it does | |---|---| | Workflows | Chain focused prompts into reusable security research playbooks, built in a visual workflow editor | | Scans | Analyze remote or local repositories and their dependencies using Codex or Claude Code as the agent runtime | | Post-scripts | Validate issues, build proofs of concept and produce reports after a finding lands | | Ranking | Custom severity rankers over a consistent finding schema, with automatic de-duplication | | Providers | Bring your own model access — a Codex login, or OpenAI, Anthropic or OpenRouter keys | The post-script stage is the part that separates this from a prompt collection. A finding that an agent asserts is not yet a finding; open·kritt gives the workflow a place to run verification and attempt an actual proof of concept, which is the same discipline a human researcher applies before filing a report. The project describes itself as the open-source distillation of the internal tooling behind the Kritt team's bug-bounty work, claiming over **$1.5 million in payouts** under the researcher name Blockian across Immunefi and HackenProof. That provenance is checkable — the profiles are linked — and it explains why the schema is shaped around triage rather than around scanning. ## Running It Setup is Git, Docker with Docker Compose, and Node.js 20 or newer, then a three-command bootstrap: `git clone`, `./kritt setup`, `./kritt start`, with the UI on `localhost:5173`. The repository-local CLI has no install step. Only one model-access option is required, and `GITHUB_TOKEN` is optional — needed only for private repositories. ## Security Posture The README is unusually direct about its own threat model, and the details matter before anyone deploys it. **The backend has no application authentication.** Default ports bind to `127.0.0.1`, and the instruction is to keep the stack private. There is no user model to lean on. **Tool-enabled agents run as root inside disposable job containers**, with writable repository copies and direct internet access, so they can install tools, compile targets, run tests and build proofs of concept. That capability is what makes real PoC generation possible, and it is also a large amount of trust to hand an LLM. The project's own guidance is to run it on a dedicated Docker host or VM and to read `docs/threat-model.md` before scanning untrusted code. Stating that plainly is the right call. A tool that gives agents root and network access to analyze code an attacker may have authored is a tool whose deployment boundary is part of its design, and burying that would have been worse than the risk itself. ## Caveats **AGPL-3.0 is a deliberate constraint.** Anyone planning to run a modified open·kritt as a network service owes source to its users. Given that the maintainers also sell a hosted product at kritt.ai, the license choice is doing exactly what it is designed to do, and commercial evaluators should read it first. **Cost is unbounded by design.** Parallel agents across a repository and its dependencies, plus validation post-scripts and PoC attempts, means token spend scales with how thorough the playbook is. The project brings your own key, so the meter is yours and there is no built-in budget ceiling described. **Findings still need a human.** De-duplication and severity ranking narrow the pile; they do not establish that a finding is real. LLM-driven vulnerability research produces confident false positives, and the post-script and PoC stages exist precisely because the raw agent output cannot be trusted as-is. **It is three weeks old and moving fast.** Three minor releases and 35 open issues in under a month signal both momentum and churn. Workflow formats and the finding schema are the kind of thing that shifts early. ## Verdict What is interesting here is the shape rather than the subject: open·kritt is a well-argued case that agent work on hard analysis problems needs decomposition, verification and de-duplication as first-class stages, not as things you bolt on after the model answers. The security domain just makes the cost of skipping them obvious. Security researchers already running manual LLM-assisted review are the clear audience — the workflow builder and post-script validation are what a hand-rolled setup usually lacks. Teams should treat the no-authentication backend and root-capable job containers as deployment requirements rather than footnotes, and read the AGPL terms before building anything on top of it.