--- title: "Open-Kritt and Governing the Security Agents You Deploy | Anomity Blog" description: "open-kritt is a smart multi-agent vulnerability-research tool. It is also a dense bundle of fleet artifacts - the security agents you deploy need governing too." url: "https://anomity.ai/blog/open-kritt-agent-vuln-research-governance/" source: html --- On this page - What open-kritt is, in the project's own terms - The tool works. That is not the governance question. - One deployment, several fleet artifacts - Applying the discipline you would demand of any agent - How Anomity governs the security agents you deploy - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Open-Kritt and Governing the Security Agents You Deploy ![Anomity robot illustrating Open-Kritt and Governing the Security Agents You Deploy] Insights # Open-Kritt and Governing the Security Agents You Deploy Anomity Research Anomity Research · Jul 24, 2026 · 6 min read Share: Copied TL;DR - open-kritt is an open-source (AGPL-3.0) platform that orchestrates AI agents to find real vulnerabilities in code by splitting research into small parallel tasks, then synthesizing the results, per the project's documentation. - It is a capable, well-designed tool built by a bug-bounty team. The governance question is not whether it is safe, but that deploying it introduces a bundle of AI artifacts your inventory probably misses. - A single instance brings orchestrated AI agents, provider CLIs, multi-provider API keys, and often MCP servers - four of the eight artifact classes an AI inventory should track. - The security agents you deploy for defense need the same discipline as any agent: discovery, least privilege, secret hygiene, per-call governance at the hook, and an audit trail. - Anomity discovers and governs these stacks: an unprivileged Endpoint Sensor inventories eight artifact types, allow/deny/log runs at the agent hook, and events land in a queryable 90-day audit trail. 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. Provider choice also decides which safeguards apply to the research itself: Claude's Opus and Sonnet models run real-time cyber safeguards that block high-risk cyber requests by default, and organizations doing legitimate dual-use work apply to [Anthropic's Cyber Verification Program](https://anomity.ai/blog/anomity-anthropic-cyber-verification-program/) to lift them. Point the same workflow at a self-hosted model and no such gate exists. ## 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](https://anomity.ai/blog/autonomous-security-agents-are-agents-too/), and, for offensive-style research tooling specifically, in [the agent-layer visibility a hackbot demands](https://anomity.ai/blog/autonomous-hackbots-agent-layer-visibility/). ## 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: What open-kritt brings Fleet artifact it becomes Why it needs governance Orchestrated research agents AI agents Hold code execution and outbound network access while reasoning over your source Provider tooling (OpenAI, Anthropic, OpenRouter, Codex-style) CLIs Provider clients on the host that can reach external model APIs API keys for each model provider Secrets Long-lived credentials that, if leaked, bill to you and reach production model accounts Workflow-wired capabilities MCP servers Often added to extend agents, each one a new tool surface and trust boundary 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](https://anomity.ai/blog/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](https://anomity.ai/blog/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](https://anomity.ai/blog/ai-supply-chain-attacks-defenders-guide/) and the trust-boundary questions in [model context protocol security, explained](https://anomity.ai/blog/model-context-protocol-mcp-security-explained/) apply directly to the workflows a team builds on top of it. The commercial equivalent arrived with [OpenAI Daybreak](https://anomity.ai/blog/openai-daybreak-defensive-agent-governance/), which gates vulnerability research and exploit validation behind a separate Red-tier approval. ## 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](https://anomity.ai/#features) and [how it deploys](https://anomity.ai/#how-it-works). 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](https://anomity.ai/#runtime-governance) and [the outcomes](https://anomity.ai/#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, [book a demo](https://anomity.ai/#early-access) or read [the docs](https://anomity.ai/docs/). Share: Copied ## Frequently asked questions What is open-kritt? According to the project's documentation, open-kritt is an open-source (AGPL-3.0) platform that orchestrates AI agents to find real vulnerabilities in code. Rather than scanning a whole repository at once, it breaks research into small, well-defined tasks run in parallel across agents, then synthesizes the outputs into de-duplicated, severity-ranked findings. It was built by an experienced bug-bounty team and runs on Docker and Docker Compose with Node.js 20 or newer, exposing a web UI at localhost:5173. Is open-kritt safe to run internally? The project shows good hygiene: the documentation describes disposable job containers that isolate tool execution so untrusted code is not run directly on the host. The governance issue is not the tool's safety in the abstract. It is that running it adds AI agents, provider CLIs, provider API keys, and possibly MCP servers to your environment, all of which need to be inventoried and scoped like any other agent. Why should a defensive security tool be governed like any other agent? Because risk comes from properties, not intent. A research agent has code execution, network reach, holds provider credentials, and reads your source code. Those properties define exposure whether the tool is offensive, defensive, or neither. A stack deployed for defense is still a fleet artifact and belongs in the same inventory and controls as everything else. What AI artifacts does an open-kritt deployment add to my fleet? At minimum: orchestrated AI agents, provider CLIs (the documentation lists OpenAI, Anthropic, and OpenRouter support, plus Codex-style tooling), API keys or secrets for each provider, and often MCP servers wired into workflows. That is four of the eight AI artifact classes an inventory should cover, from a single install. Does open-kritt send my source code to external model providers? Per its documentation, open-kritt supports multiple model providers, so unless you point it at a self-hosted model, the source under analysis is passed to an external provider and the provider API keys plus outbound calls are part of the deployment. That is exactly why secret hygiene and egress awareness matter when a team runs it. How does Anomity help govern homegrown agent stacks like open-kritt? Anomity runs an unprivileged Endpoint Sensor on Windows, macOS, and Linux that inventories eight AI artifact types (AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs). It can allow, deny, or log an action at the agent hook before the call runs, keeps inventory metadata-only with secret values redacted on the endpoint, routes events to SIEM, Slack, email, or Jira, and retains a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tools. ## Related [Insights ### Claude Fable 5.1 and Mythos 5.1: One Model, Two Safeguard Tiers, and a Fallback Your Security Team Will Hit Fable 5.1 and Mythos 5.1 are one model with two safeguard tiers. Flagged cyber requests in Claude Code fall back to Opus 4.8. What it means for you. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/claude-fable-5-1-mythos-5-1-model-fallback-governance/) [Insights ### NVIDIA's Open Agent Safety Platform Puts Controls Outside the Agent. Now Count the Agents Outside It. OpenShell sandboxes agents with policy outside their reach, and Sentry watches from the DPU. Both cover the agents you enroll. The rest need a list first. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-open-agent-safety-platform-openshell-sentry/) [Insights ### OpenAI Astra Crossed the Critical Cyber Threshold. Its Safeguards Stop at the Model. Astra is OpenAI's first model rated Critical for cyber. OpenAI built safeguards for the model. The agents running it on your endpoints are still yours. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/openai-astra-critical-cyber-capability-enterprise/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Open-Kritt and Governing the Security Agents You Deploy", "description": "open-kritt is a smart multi-agent vulnerability-research tool. It is also a dense bundle of fleet artifacts - the security agents you deploy need governing too.", "datePublished": "2026-07-24", "dateModified": "2026-07-24", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/open-kritt-agent-vuln-research-governance/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/posts/open-kritt-agent-vuln-research-governance.jpg", "width": 1200, "height": 630 }, "articleSection": "Insights", "url": "https://anomity.ai/blog/open-kritt-agent-vuln-research-governance/" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is open-kritt?", "acceptedAnswer": { "@type": "Answer", "text": "According to the project's documentation, open-kritt is an open-source (AGPL-3.0) platform that orchestrates AI agents to find real vulnerabilities in code. Rather than scanning a whole repository at once, it breaks research into small, well-defined tasks run in parallel across agents, then synthesizes the outputs into de-duplicated, severity-ranked findings. It was built by an experienced bug-bounty team and runs on Docker and Docker Compose with Node.js 20 or newer, exposing a web UI at localhost:5173." } }, { "@type": "Question", "name": "Is open-kritt safe to run internally?", "acceptedAnswer": { "@type": "Answer", "text": "The project shows good hygiene: the documentation describes disposable job containers that isolate tool execution so untrusted code is not run directly on the host. The governance issue is not the tool's safety in the abstract. It is that running it adds AI agents, provider CLIs, provider API keys, and possibly MCP servers to your environment, all of which need to be inventoried and scoped like any other agent." } }, { "@type": "Question", "name": "Why should a defensive security tool be governed like any other agent?", "acceptedAnswer": { "@type": "Answer", "text": "Because risk comes from properties, not intent. A research agent has code execution, network reach, holds provider credentials, and reads your source code. Those properties define exposure whether the tool is offensive, defensive, or neither. A stack deployed for defense is still a fleet artifact and belongs in the same inventory and controls as everything else." } }, { "@type": "Question", "name": "What AI artifacts does an open-kritt deployment add to my fleet?", "acceptedAnswer": { "@type": "Answer", "text": "At minimum: orchestrated AI agents, provider CLIs (the documentation lists OpenAI, Anthropic, and OpenRouter support, plus Codex-style tooling), API keys or secrets for each provider, and often MCP servers wired into workflows. That is four of the eight AI artifact classes an inventory should cover, from a single install." } }, { "@type": "Question", "name": "Does open-kritt send my source code to external model providers?", "acceptedAnswer": { "@type": "Answer", "text": "Per its documentation, open-kritt supports multiple model providers, so unless you point it at a self-hosted model, the source under analysis is passed to an external provider and the provider API keys plus outbound calls are part of the deployment. That is exactly why secret hygiene and egress awareness matter when a team runs it." } }, { "@type": "Question", "name": "How does Anomity help govern homegrown agent stacks like open-kritt?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity runs an unprivileged Endpoint Sensor on Windows, macOS, and Linux that inventories eight AI artifact types (AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs). It can allow, deny, or log an action at the agent hook before the call runs, keeps inventory metadata-only with secret values redacted on the endpoint, routes events to SIEM, Slack, email, or Jira, and retains a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tools." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Open-Kritt and Governing the Security Agents You Deploy", "item": "https://anomity.ai/blog/open-kritt-agent-vuln-research-governance/" } ] } ```