The project just hit 628 stars in under two weeks (created July 20, sitting at v1.2.0 when I pulled it). Yet it’s not another “AI code scanner” toy. It’s a self-hosted security research platform that turns a single vague instruction into dozens of small, well-defined agent tasks running in parallel — then de-duplicates, ranks, and validates what comes back. And because it ships as Docker Compose, you run it on infrastructure you own. That last part is why it earned a full review here.

Quick verdict

If you do security research — bug bounty, CI security gates, auditing your own dependencies — and you’re tired of either hand-rolling prompt scripts or trusting a black-box SAAS scanner, open·kritt is worth a serious look. It gives you full control over prompts, workflows, model providers, and infra, all self-hosted.

The short version: this is the first open-source tool I’ve seen that treats “orchestrate multiple AI agents to find real vulnerabilities” as an actual engineering problem — with job isolation, automatic de-duplication, severity ranking, and PoC validation — instead of a single mega-prompt. It’s not turnkey, the backend has no app authentication by default, and the model bill scales with scan size. But if you want a security research workbench on your own VPS, it’s a standout option on GitHub right now.

Why “scan the whole repo” fails

Every “AI finds vulnerabilities” demo you’ve seen works the same way: drop the codebase into a context window, ask for vulnerabilities, wait. What actually comes back is a wall of near-duplicates — the same missing input check flagged across thirty functions, no severity, no proof, no way to verify.

open·kritt’s whole design inverts that. But instead of one big question, you build a workflow: a chain of focused prompts that each target one narrow question. The engine then checks out the target repo plus its dependency tree, spins up parallel job containers, and runs each step through an AI harness (Codex or Claude Code). Yet the results don’t pile into one giant dump — they flow into a consistent finding schema that deduplicates, ranks by severity, and runs post-scripts to verify.

That’s the difference from a scanner: it’s a research platform, not a single pass. You decide the questions, the ordering, and the validation. Because the workflow is a saved playbook, you rerun it against any repo and tune the prompts that underperform.

What’s actually in the box

Let me walk through what I verified when I pulled it down.

The repo is a Node.js 20+ monorepo with five moving parts: a React/Vite frontend, an Express/Prisma backend holding Postgres (workflows, scans, findings), an engine that claims scans and runs the harnesses, and an executor view. Everything runs through docker-compose.yml. And the CLI is repository-local — no global install:

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

./kritt setup walks you through model access — a Codex login, or an OpenAI / Anthropic / OpenRouter API key. You only need one. A GITHUB_TOKEN is optional and only matters for private repos. The stack comes up on http://localhost:5173.

Here’s the honest deployment reality check from actually poking at it: on my Windows box the ./kritt sh wrapper choked on path resolution (it handed node a C:\tmp\... style path that failed to load scripts/kritt.mjs). Running node scripts/kritt.mjs directly worked fine and printed clean CLI help:

open-kritt CLI

Usage:
  ./kritt setup              Configure model access and optional GitHub access
  ./kritt start              Start the Docker Compose stack
  ./kritt help [subcommand]  Show command help

On a Linux VPS — the intended host — the wrapper is fine. That said, on a dev workstation expect to call node scripts/kritt.mjs directly or fix the sh path. Minor, but real.

The core capabilities, verified against the repo and docs:

• Workflow builder — chain focused prompts into reusable security research playbooks.
• Job containers — each tool-enabled agent runs as root in a disposable container with a writable repo copy and direct internet, so it can install tools, compile targets, run tests, and build PoCs.
• Finding schema — consistent output shape with automatic de-duplication and a custom severity ranker.
• Post-script validation — verify a finding, build a proof of concept, produce a report.
• Bring your own model — Codex login, OpenAI, Anthropic, or OpenRouter. No vendor lock-in.

The security model matters here

Since this tool runs agents over untrusted code, I read the threat model carefully. It’s a candid security doc — a full component table with trust levels and explicit mitigations. Even so, the practical takeaways are what matter if you’re deploying it.

The headline facts: the API and UI are unauthenticated by default and bind to 127.0.0.1. The README is blunt about it — “keep the stack private.” Scan agents run as root inside disposable nested containers with writable checkouts and direct outbound internet. A job container is not a security boundary against a kernel exploit. The docs explicitly tell you to run the whole stack on a dedicated VM or Docker host like a DigitalOcean Droplet ($200 credit for new users, and $12/mo gets you the 2GB tier I used), not colocated with other sensitive workloads. (affiliate link)

That’s not a bug — it’s an honest threat model. But it’s the single biggest thing to understand before deploying: this is a single-operator research tool, not a multi-tenant service. Expose it publicly and you’ve handed whoever reaches it the keys to run arbitrary scans and read findings.

A workflow, end to end

A typical workflow I’d build for a dependency audit looks like this — each step is a focused prompt, not one mega-question:

That’s the reuse story: save this as a playbook, run it against any repo, iterate on the prompts that underperform. Honestly, it’s a playbook, not a one-shot script.

How it stacks up against what I’ve covered

T3MP3ST probes the offensive side — simulating attacks to find where you’re weak. Numbat watches what agents do on your endpoints. open·kritt sits in a different lane entirely: it’s the active research workbench that tells agents what to hunt for and validates what they find. They complement rather than compete.

Who should use this

• Bug bounty hunters building reusable research playbooks across many targets.
• Security-minded developers who want a self-hosted AI security scan before CI merges.
• DevOps/SRE teams that want a security gate on their own infrastructure, with prompts they control.
• Self-hosters who refuse to ship their codebase to a SAAS scanner.

It’s not for you if you need a managed, zero-ops experience, or if you want to share one deployment across a team — the missing app auth makes that a liability, not a feature. But if you’re scanning only to satisfy a checkbox, a commercial SAST like Snyk or Veracode is the lower-effort path. Still, open·kritt is for when you want full control of prompts, workflows, and infrastructure.

Honest limitations

• License: AGPL-3.0 — fine for self-hosting, but if you offer it as a service to others you must open-source your modifications. Fact, not advice.
• Scope: it surfaces candidates you validate — it won’t “find all vulnerabilities,” and no tool honestly can.
• Model costs scale linearly with scan size. Large repos mean many parallel agent calls, and that adds up.
• Not multi-user by default. No app auth means keep it private or front it with a reverse proxy and your own auth.
• Docker infrastructure required. This is not a single binary; you’re owning a Compose stack.

The bottom line

open·kritt is the first open-source project I’ve found that treats AI vulnerability discovery as a real orchestration problem — parallel agents, job isolation, de-duplication, severity ranking, PoC validation — and ships it self-hosted on Docker. The $1.5M in bug bounty payouts behind it is the credibility detail that separates it from every generic AI scanner out there.

My verdict: if you do security research on code you own or targets you’re authorized to test, deploy it to a dedicated VPS and build your first playbook this week. Start small — a single dependency you care about — and iterate on the prompts. The install is three commands; the real work is learning to write good research workflows, and that’s exactly the control you get here.