open·kritt audits source code with specialized security agents

What this is about

open·kritt is an open-source, self-hostable workspace for automated vulnerability research in source code. Instead of giving one language model an entire repository and a broad request, it splits a review into smaller tasks, assigns them to agents and combines the output into prioritized findings. The project is maintained by Kritt and licensed under AGPL-3.0.

The current version 1.4.1 was released on August 16, 2026. For users, the significant point is not the date but the combination of a graphical interface, reusable review workflows, multiple model providers and structured exports. That makes open·kritt a usable security tool rather than only a research demonstration.

What open·kritt actually does

A team builds a review workflow from focused prompts. Those steps can run in parallel with Codex, Claude Code or Grok Build. The tool analyzes local or remote repositories and their dependencies, normalizes findings, removes duplicates and supports custom severity rankers. Post-processing scripts can validate a suspected issue, build a proof of concept or prepare a report.

Completed runs can be exported as a ZIP archive containing structured data, reports and proofs of concept. A command-line interface is available for servers without a graphical interface. Operators can sign in with Codex or connect their own access to OpenAI, Anthropic, DeepSeek, OpenRouter or xAI. The tool itself runs through Docker Compose and also requires Git and Node.js 20 or newer.

Why it matters

Broad model prompts often produce long, repetitive or poorly verifiable lists for large codebases. open·kritt treats that problem as a workflow: one task might look for broken authorization, another might trace data flows and a third might practically test only the most promising findings. This can help security specialists spend scarce review time on better supported candidates.

Self-hosting also matters. Source code, review logic and results can remain in an organization's own environment. That does not mean every piece of data stays local: selected model providers receive the content needed for their tasks. What leaves the environment therefore depends on the configuration and the agreements with those providers.

The open AGPL license permits technical inspection and generally requires corresponding source to be offered when modified software is provided over a network. Organizations planning internal modifications should assess how that obligation fits their deployment.

In plain language

A security review driven by one broad prompt is like asking one tradesperson to inspect an entire house in a single walk-through. open·kritt organizes several specialists instead: one checks the wiring, one checks the doors and another checks the plumbing. Duplicate notes are removed and the most important defects are tested again. A human still remains the site manager because even a neatly organized report can be wrong.

A practical example

A team wants to review an 80,000-line repository before a release. It creates four steps: inspect access control, trace inputs to the database, review dependencies and validate the ten highest-ranked suspicions. open·kritt runs the focused tasks in parallel, merges similar reports and exports the remaining findings.

Suppose 34 raw reports become 15 distinct candidates after deduplication. Validation confirms three, rejects seven and leaves five unresolved. This example is deliberately fictional and not a performance claim. It illustrates the workflow: the team receives an auditable queue, but specialists still have to assess every confirmed issue and test each remediation separately.

Scope and limits

First, the open stack has no built-in application authentication according to the project documentation and binds to 127.0.0.1 by default. It belongs on a private network, not unchanged on the public internet.

Second, tool-enabled agents run as root in disposable job containers with writable repository copies and direct internet access. For unknown or hostile code, the project therefore recommends a dedicated Docker host or isolated virtual machine.

Third, the output does not replace manual security review or a reproducible proof of concept. Agents can miss vulnerabilities, misclassify harmless code or run risky commands during validation. Cost and privacy also depend on the selected model provider.

The sensible next test is therefore small: scan a non-confidential test repository in an isolated environment, reproduce the findings manually and only then consider real product code.

SEO & GEO keywords

open·kritt, Kritt, AI security tool, source code review, vulnerability research, self-hosted AI, coding agents, Codex, Claude Code, DevSecOps, AGPL-3.0, Docker Compose