open·kritt: Self-Hosted AI Agent Orchestration for Vulnerability Research

open·kritt is an open-source, self-hosted platform that breaks a codebase into small security research tasks and runs AI agents against them in parallel.

The engine uses Codex or Claude Code as the execution harness, then collects agent output into ranked, de-duplicated findings you can validate with post-run scripts.

Pointing a large language model at an entire repository and asking it to find vulnerabilities produces noisy, shallow output, because the context window forces the model to skim instead of reason.

open·kritt splits that single broad request into a tree of narrow, typed prompt steps, sends each one to an agent, and feeds the results forward into the next stage.

The team behind it, ControlZ Security Research, built the project as a public version of the internal workflow it uses for its own bug-bounty work.

Under the researcher handle Blockian, that team has logged over $1.5 million in bounty payouts across Immunefi and HackenProof, with 44 critical or high-severity reports on record.

open·kritt packages the orchestration layer from that workflow: task decomposition, parallel agent execution, and a scoring system for the results.

Visit open·kritt

How open·kritt Differs from Running Codex or Claude Code Directly

	Raw Codex / Claude Code session	open·kritt
Task scope	One conversation, one context window	A workflow tree of narrow, typed steps
Parallelism	Manual, one thread at a time	Agents fan out across functions, files, and hypotheses automatically
Output format	Free-form chat response	Fixed finding schema with severity, confidence, and de-duplication
Verification	Left to the researcher	Post-scripts validate exploitability and build proofs of concept
Reuse	Prompts live in chat history	Workflows save as reusable blueprints across scans and repositories

Key Features

Builds workflows as a tree of prompt steps organized into depths, where depth 0 runs once (for example, enumerating every HTTP route) and each deeper depth runs once per result from the level above it.
Generates a first workflow draft from a plain-language description of the research process, then opens it in the visual builder for review before saving.
Ships built-in starter workflows that a scan can use immediately without any configuration.
Scans local repositories or remote GitHub repositories, including their dependencies.
Runs the analysis harness through a Codex login, an OpenAI API key, an Anthropic API key with Claude Code, or an OpenRouter key.
Enforces a fixed finding schema at the terminal step of every workflow, so every result carries the same required keys regardless of which workflow produced it.
Runs post-scripts against individual findings to validate exploitability, generate a proof of concept, or draft a report section.
Applies custom severity rankers and automatic de-duplication so overlapping findings from parallel agent runs collapse into one entry.
Executes tool-enabled scan agents inside disposable, isolated job containers with their own writable copy of the target repository.

Use Cases

Map a Large Attack Surface

Start with a step that inventories HTTP routes, RPC handlers, contract entry points, command parsers, or other externally reachable interfaces. The next depth assigns each result to a separate agent with a smaller context and a precise inspection target.

Investigate a Specific Vulnerability Class

Encode a known bug pattern into a reusable workflow. A researcher might trace authorization checks, unsafe deserialization paths, signature verification, privilege transitions, or cross-contract assumptions. The same playbook then runs against different repositories.

Validate Candidate Findings

Attach a post-script that asks a new agent to reproduce the reported behavior, inspect the claimed configuration, run a test case, or build a proof of concept. Reports that fail the evidence requirements can be rejected before triage.

Analyze Cross-Repository Behavior

Add dependencies and related repositories to a scan when security depends on assumptions between components. Agents inspect the supporting code only when the active task requires it, which avoids placing every repository into every model context.

Standardize Security Research Across a Team

Store research methods as workflows with named steps, typed output, shared ranker rules, and consistent findings. Researchers can revise individual prompts or post-processing logic while preserving the overall process.

How to Install and Run open·kritt

1. Install Git, Docker with Docker Compose, and Node.js 20 or newer. Linux users should run the open·kritt CLI under a regular user account. Docker access must work without prefixing every command with sudo.

git --version
docker info
docker compose version
node --version

2. Clone the Repository

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

3. Configure Model Access. API keys are stored in the project .env file. Codex and Claude login data live under the project’s .data directories. Keep these locations out of commits, issue reports, screenshots, and shared archives.

./kritt setup

Option	Use case
Codex login	Guided device-flow login using an eligible ChatGPT or Codex subscription
`OPENAI_API_KEY`	OpenAI Platform API key through the Codex harness
`CODEX_API_KEY`	Direct Codex execution override using the same key type
`ANTHROPIC_API_KEY`	Claude Code harness, billed through the Anthropic API
`OPENROUTER_API_KEY`	Routes a compatible model through OpenRouter

4. Start the Docker Stack.

./kritt start

The command builds and starts the Compose services in the foreground. Open the interface at:

http://localhost:5173

The backend health endpoint runs at:

http://localhost:3002/api/health

5. Select or Build a Workflow. Open Workflows → New workflow and choose one of three starting routes:

Start with a blank workflow.
Duplicate an existing workflow.
Generate a workflow draft from a research description.

6. Create the Scan. Select the workflow and configure:

The main repository
Related repositories or dependencies
Model provider and harness
Repeat count
Post-script
Severity ranker
Target-specific instructions

7. Inspect the structured results, evidence, affected files, trigger flow, and malicious input examples. Apply the post-script and ranker before investing manual review time.

Anchored deduplication currently works within one scan. Separate scans do not share a global deduplication index.

Kritt Managed Scans

Alongside the free self-hosted engine, ControlZ Security Research sells managed scans run by its own team:

Single scan — $5,000, covering up to 200,000 lines of code, delivered as a written findings report with email support during the engagement and a scope and authorization review before work starts.
Enterprise — custom pricing for CI/CD integration, release-by-release scanning, and dedicated support with SLAs.

Pros

Focused multi-agent research workflows
Reusable security playbooks
Structured vulnerability findings
Per-finding validation scripts
Automatic deduplication and ranking
Cross-repository analysis
Multiple provider options
Full self-hosted infrastructure control

Cons

Requires Docker administration
Requires external model access
Workflow quality controls result quality
Repository code reaches model endpoints
No built-in application authentication

Alternatives & Related Resources

FAQs

Q: Can open·kritt scan a private GitHub repository?
A: Yes. Add a GITHUB_TOKEN when the main repository or a dependency is private. Use a read-only, short-lived token limited to the required repositories. Public repositories require no GitHub token.

Q: Does open·kritt deduplicate findings across separate scans?
A: No. Anchored deduplication currently operates inside an individual scan. Separate scans maintain independent finding sets.

Q: Does a failed scan restart automatically?
A: A scan that reaches the failed state requires the manual Resume action. Temporary provider rate-limit states retry automatically under the engine’s scheduling controls.