Open-Kritt and Governing the Security Agents You Deploy

A self-hostable tool called open-kritt has been circulating among security teams, and it is genuinely interesting. According to the project's documentation, it is an open-source platform (AGPL-3.0) that orchestrates AI agents to find real vulnerabilities in code. Instead of pointing one model at an entire repository and hoping, it breaks vulnerability research into small, well-defined tasks, runs them in parallel across AI agents, and then synthesizes the outputs into ranked findings. It was built by an experienced bug-bounty team, and the documentation reports a few hundred GitHub stars of community traction.

This post is not a security review of open-kritt. The tool does what it says, and the approach is sound. The point is different, and it applies to any homegrown agent stack you deploy for defense: the moment you run open-kritt inside your organization, you have introduced a dense bundle of exactly the artifacts that quietly become shadow IT. The security agents you deploy are agents too.

What open-kritt is, in the project's own terms

The project's documentation describes a workflow-driven platform. Users build security-research workflows, run scans against repositories, verify candidate findings with custom validation scripts, and prioritize results with automatic de-duplication and severity ranking. The design principle is focused analysis: rather than scanning a whole codebase at once, open-kritt decomposes the work into narrow tasks that individual agents can reason about well, then reassembles their conclusions into something a human can triage.

It is model-agnostic. Per the documentation, it supports multiple providers - including OpenAI, Anthropic, and OpenRouter, along with Codex-style tooling - and gives operators control over the prompts and workflows each agent uses. Operationally it runs on Docker and Docker Compose with Node.js 20 or newer, exposes a web UI at localhost:5173, runs backend services, and executes tools inside disposable job containers so untrusted code is handled in isolation. That container discipline is a good sign: the authors clearly thought about running analysis safely.

The tool works. That is not the governance question.

Here is the reframe. From a fleet-visibility standpoint, a running open-kritt instance is not one thing. It is several of the artifact classes that AI governance is supposed to track, assembled on an endpoint or server your inventory very likely does not know about. Its orchestrated agents have both code execution and network reach. It holds API keys for one or more model providers. It shells out to provider tooling. And, depending on how a team wires their workflows, it may pull in MCP servers to give agents extra capabilities.

None of that is a criticism of the project. It is the nature of any capable agent stack. But it means a defensive tool inherits the same governance obligations as any other agent - the ones we argue for in autonomous security agents are agents too, and, for offensive-style research tooling specifically, in the agent-layer visibility a hackbot demands.

One deployment, several fleet artifacts

Map a single open-kritt deployment onto the eight AI artifact types an inventory should cover, and the density becomes obvious:

That is four of the eight classes from a single install, before anyone has logged in. The agents also read proprietary source code and, unless a self-hosted model is used, pass it out to a provider. Now multiply by every engineer who tried the tool after seeing the GitHub stars, on laptops your security team never provisioned, and the shadow-IT shape is complete. The provider credentials are the sharpest edge: they are the kind of long-lived secret we treat as a first-class risk in secrets management for AI agents.

Applying the discipline you would demand of any agent

The controls do not change because the tool is defensive. A security agent that reads your source and calls external APIs deserves the same treatment as a coding assistant, which we lay out in securing AI coding agents and CLIs. Concretely:

• Discovery first. You cannot govern what you cannot see. Find every open-kritt instance and every provider CLI it installed, not just the one blessed by the platform team.
• Least privilege. Scope what the agents can read and reach. A research agent rarely needs standing access to every repository or the open internet - the principle we develop in least privilege for AI agents.
• Secret hygiene. Provider API keys should be inventoried, rotated, and never sitting in plaintext env files a scan or a stray command could exfiltrate.
• Per-call governance. The high-value control is the ability to allow, deny, or log a specific action before it runs, at the agent's hook, rather than reconstructing damage afterward.
• An audit trail. When a research agent reads a sensitive repository or calls a provider, that should be a queryable record, not a guess. Pair it with runtime baselines as in runtime monitoring and anomaly detection for AI agents.

And because open-kritt pulls models and, optionally, MCP servers from outside your walls, it sits squarely inside the AI supply chain. The provenance questions we raise in AI supply-chain attacks: a defender's guide and the trust-boundary questions in model context protocol security, explained apply directly to the workflows a team builds on top of it.

How Anomity governs the security agents you deploy

Anomity treats a defensive agent stack like open-kritt the way it treats any other AI artifact - as something to discover, scope, and record. An unprivileged Endpoint Sensor for Windows, macOS, and Linux inventories eight AI artifact types across the fleet: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. So the moment an engineer spins up open-kritt, its agents, its provider CLIs, and its API keys show up in your inventory instead of hiding on a laptop. See what the platform covers and how it deploys.

From there, Anomity can allow, deny, or log an action at the agent hook - for example a Claude Code PreToolUse call - before it runs, so a research workflow reaching somewhere it should not is stopped rather than merely noticed. Events route to your SIEM, Slack, email, or Jira, and every action lands in a queryable 90-day audit trail. Inventory stays metadata-only, with secret values redacted on the endpoint, so governing the tool never means hoarding the credentials it holds. Anomity is SOC 2 Type II and is built to complement your existing Network, EDR, DLP, and GRC stack, not replace it. See runtime governance and the outcomes it targets.

Running open-kritt to find vulnerabilities is a smart move. Running it without knowing where it lives, what it can reach, or which keys it holds is how a defensive tool quietly becomes the blind spot it was meant to close. If you want the security agents you deploy to be as visible as the ones you are hunting, request early access or read the docs.