open-kritt is a self-hosted platform that runs focused AI agents in parallel over source code to produce de-duplicated, ranked, and validated vulnerability findings for authorized security research.
| Tool | Kritt-ai/open-kritt — open-source, self-hosted AI agent orchestration platform for vulnerability research in code |
| Primary Use | Building reusable workflow playbooks of chained prompts, running parallel scans over local or remote repositories with Codex, Claude Code, or Grok Build, and validating findings via post-scripts |
| Primary Use | Running authorized vulnerability research on code you own or are contracted to assess, using chained AI agent workflows and post-script validation |
| Safe Use | Authorized engagements such as bug-bounty programs with defined scope, penetration tests, internal code reviews, and security research labs with explicit permission |
| Telemetry Note | The platform is self-hosted and local by default (127.0.0.1 binding), but agents run with direct internet access and make model-provider API calls, so defenders will observe outbound traffic to configured AI providers and heavy Docker container churn on the scanning host |
open-kritt attacks a problem most security teams have already encountered: pointing a single large model at an entire repository and asking it to find vulnerabilities produces shallow, noisy output. The project's core thesis, stated plainly in the README, is decomposition — break research into small, well-defined tasks, run them across AI agents in parallel, then combine results into findings a human can validate and prioritize. The result is a self-hosted orchestration platform that treats AI analysis as a pipeline stage rather than an oracle, which is a materially different architecture from the chat-driven review workflows most people cobble together ad hoc.
The unit of composition in open-kritt is the workflow: a chain of focused prompts assembled into reusable security research playbooks. This is where the real leverage sits, because a workflow encoding how you triage a web application — authentication flows first, then deserialization sinks, then dependency confusion — captures methodology in a form you can replay across every subsequent engagement. The README positions the tool for security researchers and security-minded developers who want control over prompts, workflows, model providers, and infrastructure, and that emphasis on control is consistent throughout: nothing is hidden behind a managed SaaS abstraction.
Execution is delegated to external coding agents — Codex, Claude Code, or Grok Build — which analyze remote or local repositories and their dependencies. Model access is bring-your-own: a Codex login, or API connectivity through OpenAI, Anthropic, DeepSeek, OpenRouter, or xAI. You only need one access option to start, and the ./kritt setup flow walks you through available logins and keys. An Accounts view with a persisted Active switch lets you keep multiple credentials saved while controlling which ones receive new assignments, which is a small but genuinely useful touch for researchers juggling provider quotas across long-running scans.
Findings move through a structured pipeline before a human ever sees them. A consistent finding schema, automatic de-duplication, and custom severity rankers turn raw agent output into a ranked queue. Post-scripts then handle verification: validating reported issues, building proofs of concept, and producing reports. Completed scans export as a single ZIP archive containing canonical findings, structured data, post-processing output, reports, and PoCs, with a share-safe manifest; stopped or failed scans that still produced findings generate clearly marked partial exports. One design decision worth noting: attacker-influenced report and PoC source is deliberately kept as plain text, a defensive choice that prevents malicious markup embedded in scanned code from executing through the reporting layer.
The operational security posture in the README is unusually candid, and operators should read it carefully before deploying. Tool-enabled agents run as root inside disposable job containers, with writable repository copies and direct internet access — necessary so agents can install tools, compile targets, run tests, and build proofs of concept, but also a significant trust grant. The default ports bind to 127.0.0.1, and the backend ships with no application authentication, so the stack must stay private. The maintainers explicitly direct you to run the platform on a dedicated Docker host or VM and to read the published threat-model.md before scanning untrusted code — sound advice, since you are effectively executing code from the target repository with high privileges and network reach.
Getting started is refreshingly minimal in terms of installation ceremony. Prerequisites are Git, Docker with Docker Compose, and Node.js 20 or newer, and the repository-local CLI needs no install step: git clone https://github.com/Kritt-ai/open-kritt, cd open-kritt, then ./kritt setup followed by ./kritt start brings the stack up at http://localhost:5173. A GITHUB_TOKEN is optional and only required for scanning private GitHub repositories, which keeps the default footprint small. For servers without a browser or desktop, ./kritt-headless provides a terminal-only path into the same backend.
The headless CLI deserves its own paragraph because it reveals how seriously the project takes automation beyond the GUI. It imports portable workflow, post-script, skill, and ranker JSON, creates scans with the same backend validation as the web form, displays scan status, stages, and failure reasons, edits non-secret runtime settings, and exports finding bundles. Notably, it does not display finding contents in the terminal — presumably to keep sensitive vulnerability data off shared screens and shell scrollback. This makes open-kritt viable as a component in a larger scheduled or CI-driven review pipeline rather than just an interactive workstation tool.
The project's credibility claim is concrete rather than vague: the Kritt team reports over $1,500,000 in bug-bounty payouts under the researcher name Blockian across Immunefi and HackenProof, and positions open-kritt as the open-source distillation of the internal project behind that work. Whether or not that provenance matters to you, it does signal that the workflow model was pressure-tested against real Web3 and application security targets rather than designed in a vacuum. The repository shows roughly 2,100 stars, JavaScript as the primary language, an AGPL-3.0 license, and joint ownership by Harel Rom and Gabriel Balko, with governance documented in OWNERSITY.md-adjacent files (OWNERSHIP.md) and contribution norms in CONTRIBUTING.md.
From a defender's perspective, open-kritt's footprint is worth understanding even if you never run it. It is self-hosted and binds locally, so it does not beacon to a vendor, but active scans generate substantial outbound traffic to configured AI provider APIs — your chosen OpenAI, Anthropic, DeepSeek, OpenRouter, or xAI endpoints — plus rapid creation and teardown of Docker job containers on the scanning host. Any finding data that leaves via the ZIP export contains proofs of concept in plain text and should be handled with the same care as any vulnerability report. Used inside its documented constraints — dedicated host, private network exposure, authorized targets only — it is a well-architected example of where AI-assisted code review is genuinely heading: focused prompts, parallel agents, and human-in-the-loop validation instead of one giant prompt and a prayer.
Kritt-ai/open-kritt.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.