Open-Kritt: The Bug Bounty Hunter's Framework for Orchestrating AI Security Agents

Hook

A security researcher who's earned $1.5M from bug bounties just open-sourced the AI orchestration system they use to find vulnerabilities faster than manual code review—and it runs AI agents as root in Docker containers by design.

Context

If you've tried pointing GPT-4 at an entire codebase and asking it to "find security vulnerabilities," you've discovered the core problem with naive LLM security analysis: models either hallucinate issues that don't exist, miss real vulnerabilities buried in context noise, or hit token limits before completing analysis. The industry's first-wave response was wrapping traditional SAST tools with AI explanations—Snyk and SonarQube adding ChatGPT integrations to explain their existing rule engines. This helps developers understand findings but doesn't discover novel vulnerabilities.

Open-kritt takes the opposite approach, built by the team behind 'Blockian,' a bug bounty researcher collective with over $1.5M in verified payouts. Rather than starting with static analysis rules and adding AI, it starts with LLM agents and orchestrates them like a senior researcher orchestrates junior analysts: decompose the repository into focused analysis tasks, run them in parallel with explicit context passing, validate findings with executable scripts, and deduplicate results across agents. This isn't academic speculation about what AI security tools could be—it's productized tribal knowledge from researchers who've actually shipped CVEs and collected five-figure bounties. The architecture choices reflect hard-won lessons: whole-repo analysis fails, so workflows decompose into prompt chains; agents need to compile code and run tests, so containers run as root; LLM providers change rapidly, so provider abstraction is first-class; multiple agents find duplicate bugs, so content-addressed deduplication is built-in.

Technical Insight

The core innovation in open-kritt is treating security analysis as a directed graph of LLM prompts rather than a monolithic "analyze this repo" task. Workflows are defined as sequences of steps where each prompt receives structured context from previous executions, mirroring how human researchers incrementally build understanding rather than trying to grok an entire codebase at once.

Here's what a simplified workflow definition looks like:

const authBypassWorkflow = {
  steps: [
    {
      id: 'find-auth',
      prompt: 'Identify all authentication and authorization checks in {{repoPath}}',
      model: 'gpt-4-turbo',
      output: 'authMechanisms'
    },
    {
      id: 'trace-bypasses',
      prompt: 'For these auth mechanisms: {{authMechanisms}}\nFind code paths that could bypass these checks',
      model: 'claude-3-opus',
      parallel: true,
      output: 'potentialBypassPaths'
    },
    {
      id: 'validate',
      script: './scripts/test-auth-bypass.sh',
      input: '{{potentialBypassPaths}}',
      output: 'confirmedFindings'
    }
  ]
}

Each step runs in a disposable Docker container with a fresh repository clone, and critically, containers run as root with internet access. This isn't a security oversight—it's a pragmatic choice that lets agents compile code, install dependencies via npm/pip/cargo, run test suites, and build proof-of-concept exploits without containerization complexity bleeding into prompt engineering. If an agent needs to "verify this SQL injection works by running the app with a test payload," it can actually spin up the database, seed data, and execute the attack. The threat model assumes you're dedicating VMs to scanning and treating each job container as potentially compromised.

Behind the scenes, BullMQ job queues handle orchestration. When you trigger a scan, the workflow engine creates a job graph where independent steps become parallel jobs:

// Simplified job creation logic
for (const step of workflow.steps) {
  if (step.parallel && previousStep.output) {
    // Explode previous output into parallel jobs
    const items = await redis.get(previousStep.output);
    for (const item of items) {
      await queue.add('agent-execution', {
        stepId: step.id,
        context: { ...globalContext, item },
        model: step.model
      });
    }
  } else {
    await queue.add('agent-execution', {
      stepId: step.id,
      context: globalContext,
      model: step.model
    });
  }
}

The provider abstraction layer routes jobs to different LLM APIs (OpenAI, Anthropic, OpenRouter, etc.) with a normalized interface. This matters more than it seems—security researchers have discovered that Claude excels at certain vulnerability classes (logic bugs, race conditions) while GPT-4 is stronger at others (memory safety, cryptographic misuse). Workflows can route specific analysis steps to models that empirically perform better:

const modelRouter = {
  'memory-safety': 'gpt-4-turbo',
  'logic-bugs': 'claude-3-opus', 
  'crypto-analysis': 'gpt-4-turbo',
  'race-conditions': 'claude-3-opus'
};

Finding de-duplication happens through content-addressed hashing of normalized vulnerability patterns. When multiple agents identify "SQL injection in user login," the system hashes the vulnerability type, affected code location, and attack vector into a canonical identifier. This prevents the N-agents-finding-the-same-bug problem that naive parallelization creates. The implementation likely uses fuzzy matching on code locations since line numbers shift, but the exact algorithm isn't documented—it's a black box that works well enough in practice based on the Blockian team's production usage.

Post-execution validation scripts separate discovery from verification. After agents identify potential vulnerabilities, custom bash/Python scripts can attempt actual exploitation:

#!/bin/bash
# scripts/test-auth-bypass.sh
VULN_PATH=$1
BYPASS_PAYLOAD=$2

# Spin up the app in the container
npm install && npm start &
sleep 5

# Attempt the bypass
RESPONSE=$(curl -X POST http://localhost:3000$VULN_PATH \
  -H "Authorization: $BYPASS_PAYLOAD")

if echo $RESPONSE | grep -q "admin_panel"; then
  echo "CONFIRMED: Auth bypass successful"
  exit 0
else
  echo "FALSE_POSITIVE: Bypass failed"
  exit 1
fi

This architectural separation means you can build domain-specific validators without polluting core analysis prompts. The LLM's job is hypothesis generation; the script's job is ground truth verification.

Gotcha

The most immediate limitation is authentication—there isn't any. Open-kritt binds to localhost by default and assumes you're either running it locally, SSH tunneling to a remote instance, or deploying behind a reverse proxy with your own auth layer. There's no user management, no API tokens, no session handling. For solo researchers or small teams comfortable with infrastructure, this is fine. For anyone wanting to expose this as a web service to a team, you're building authentication from scratch or fronting it with Nginx + OAuth.

The root container model with internet access is a deliberate threat model choice that makes multi-tenant deployment essentially impossible without dedicated VM-per-scan isolation. If you're scanning untrusted repositories—say, accepting GitHub URLs from users as a SaaS service—you're trusting that Docker isolation is sufficient when a potentially malicious repository gets cloned and executed with root privileges. The Blockian team's use case is scanning their own targets or bug bounty programs where the codebase itself isn't adversarial, but container escape vulnerabilities are real. You need dedicated VMs or accept the risk.

The finding schema and de-duplication algorithm are entirely opaque. There's no extension point for custom similarity metrics, no documented normalization process, and no way to tune how aggressively the system clusters findings. If you're analyzing a codebase where the same vulnerability pattern appears in 50 endpoints (think IDOR in every API route), you can't easily configure whether that's one finding with 50 instances or 50 deduplicated findings. The black-box implementation works for the creators' use cases but limits customization for teams with specific reporting requirements or compliance needs around vulnerability tracking.

Verdict

Use if: You're doing active security research, running bug bounties, or performing manual code review where AI triage could 10x your throughput and you need granular control over how analysis decomposes into parallel LLM calls. The $1.5M bounty pedigree means workflow patterns reflect actual vulnerability hunting, not demo-ware, and the orchestration layer solves real problems around agent coordination that you'd otherwise spend months building with LangChain. Also use if you're comfortable operating infrastructure—deploying behind VPNs, managing Docker security, and treating scan VMs as potentially compromised. Skip if: You need turnkey multi-tenant deployment, can't dedicate isolated VMs to scanning, or want push-button security without infrastructure expertise. The localhost-only, no-auth design and root container model assume operator sophistication. Also skip if you're looking for integration with traditional SAST tools, pre-built CVE databases, or compliance reporting—this is pure LLM orchestration without the hybrid static analysis that enterprise security tools provide. And definitely skip if you're scanning adversarial codebases without VM-level isolation; the root container threat model isn't suitable for untrusted input without serious infrastructure hardening.