Constantine: Autonomous Code Vulnerability Discovery

What if you could point an AI at a source code repository and get back confirmed, exploitable vulnerabilities — with patches? Constantine does exactly that. It is an autonomous vulnerability discovery and patching engine now running inside the Praetorian Guard Platform, and it changes the economics of source code security from "hire experts and wait weeks" to "run a pipeline and get results."

Constantine connects to a repository, analyzes the code, finds vulnerabilities, proves they are exploitable, and generates validated fixes. No human intervention required between stages. The entire workflow — from clone to confirmed finding to tested patch — runs as a single command.

Inspired by DARPA's AIxCC

Constantine is built on the strategies that won the DARPA Artificial Intelligence Cyber Challenge (AIxCC), a competition where autonomous systems competed to find and fix vulnerabilities in real open-source software. The winning teams demonstrated that LLMs combined with engineering rigor — structured pipelines, adversarial validation, proof-of-exploit testing — could discover real vulnerabilities that human researchers had missed.

Three insights from AIxCC shaped Constantine's design:

  • Patching matters 3x more than discovery. Finding a bug is easy. Proving it's real and shipping a correct fix is hard. Constantine validates every patch by re-running the exploit against the patched code.

  • Accuracy multipliers punish speculation. In AIxCC, every invalid submission reduced your entire score. Constantine applies the same discipline — multiple independent verification stages filter findings so that what survives is real.

  • PoV-validated patching is the highest-leverage strategy. The winning team achieved a 0.9999 accuracy multiplier by never submitting a patch they hadn't verified. Constantine follows the same principle: never report a finding you can't prove, never propose a fix you haven't tested.

How Constantine Works

Constantine runs a six-stage pipeline. Each stage does one job, and the output of each feeds directly into the next.

1. Ingest — Understand the Target

Constantine clones the repository and builds a map of the codebase. For large repositories, it doesn't naively scan everything — it extracts function signatures, class declarations, and import statements from every file, then uses an LLM to score each file 0–100 for security relevance. Files handling authentication, cryptography, input parsing, and network protocols score high. Test fixtures and documentation score low. The highest-scoring files are selected within a character budget, so analysis time is spent where it matters most.

Constantine can also ingest at the pull request level — analyzing only the files changed between two git refs — or import existing threat model data to focus the scan on known high-risk areas.

2. Detect — Find What's Wrong

This is where the LLM scanners go to work. Constantine ships five detection modules that can run independently or in parallel:

Two-Pass Scanner (Primary). Layer 1 uses a fast model (Haiku) to aggressively flag suspicious patterns across all code chunks — ten concurrent workers scanning at speed. Layer 2 takes only the flagged areas and validates them with a more capable model (Opus or Sonnet) using deep CWE-specific analysis prompts, full surrounding context, and up to 200K characters per analysis unit. This mirrors the AIxCC winning approach: cheap models for breadth, expensive models for depth.

Actor-Skeptic Adversarial Scanner. A four-stage debate process. First, a fast model proposes findings. Then a skeptic model challenges each one — reviewing the actual source code and making a binary TRUE or FALSE verdict. Surviving findings go to a deep scanner that re-analyzes the flagged files with richer context. Finally, a strict gatekeeper skeptic reviews everything one more time. By the end, only findings that survived two independent rounds of adversarial scrutiny remain. The full elimination funnel is logged for auditability.

Additional modules include a single-pass fast scanner for quick triage, and a Go-based scanner for lower-overhead execution.

3. Review — Verify with Code Exploration

A finding from the detect stage is still a hypothesis. The review stage deploys an agentic LLM verifier — an autonomous agent equipped with code exploration tools — to confirm each one. The agent can read files, search code across the repository, trace function calls, and navigate the directory tree. It autonomously follows data flows from source to sink, checking whether the vulnerability is actually reachable.

For maximum accuracy, Constantine offers taint-aware verification. Before the LLM agent starts, a tree-sitter-based static analyzer pre-computes the call graph around each finding: the vulnerable function, its callers (traced backward up to two hops), and its callees. This taint slice is injected directly into the agent's prompt, so reachability analysis is already done — the agent focuses on confirming exploitability rather than spending tool calls tracing code paths. Tree-sitter parsing supports Python, JavaScript, TypeScript, Java, C, C++, Go, and Rust.

4. Exploit — Prove It's Real

For every verified finding, Constantine attempts to generate a proof-of-vulnerability — actual input or code that triggers the bug. This is not theoretical. The exploit module uses an agentic LLM with a full toolset: it can create files, set up build environments, install dependencies, compile code, and execute commands in a sandboxed environment.

The agent runs an internal loop: write exploit code, execute it, check the result. If it doesn't trigger, the agent reads the error output, adjusts its approach, and tries again — up to 250 tool calls per finding. The sandbox can be either Docker-in-Docker (full container isolation with browser testing support) or a local subprocess sandbox for platform-integrated deployments.

Before exploitation begins, the agent performs a trust model analysis. If a "vulnerability" requires the attacker to already control the application (self-inflicted trust), it is immediately classified as not-a-vulnerability and skipped. This prevents wasting compute on findings that look scary in source code but have no realistic attack path.

5. Patch — Fix It and Prove the Fix Works

Constantine generates patches for confirmed, exploitable vulnerabilities using a tiered strategy. First, try the cheapest fix: can you bump a dependency version? If not, apply a targeted fix — a bounds check, a null guard, input validation. If the issue is structural, generate a refactor.

Every patch is validated. Constantine re-runs the proof-of-vulnerability against the patched code. Only patches that provably fix the bug get reported. This is the PoV-validated patching discipline from AIxCC — never ship a fix you haven't tested.

6. Report — Deliver the Evidence

The final stage reads every artifact from the entire run and produces structured output: machine-readable JSON for platform integration and human-readable Markdown for review. Each finding includes the complete evidence chain — from detection through verification through exploitation through patching — along with CVSS scores, CWE classifications, code snippets, and cost breakdowns.

Proven Against Real-World CVEs

Constantine is benchmarked against 28 of the most consequential vulnerabilities in modern software:

  • Log4Shell (CVE-2021-44228) — Remote code execution via JNDI lookup in Apache Log4j

  • Heartbleed (CVE-2014-0160) — Missing bounds check in OpenSSL TLS heartbeat

  • Dirty Pipe (CVE-2022-0847) — Linux kernel privilege escalation via pipe buffer flags

  • Baron Samedit (CVE-2021-3156) — Heap overflow in sudo's shell escape handling

  • regreSSHion (CVE-2024-6387) — Signal handler race condition in OpenSSH

  • Psychic Signatures (CVE-2022-21449) — ECDSA verification bypass in Java (r=0, s=0 accepted)

  • Looney Tunables (CVE-2023-4911) — Buffer overflow in glibc's GLIBC_TUNABLES parser

  • runc Container Escape (CVE-2024-21626) — File descriptor leak enabling host filesystem access

The full benchmark suite spans memory safety, authentication bypass, path traversal, cryptographic flaws, container escapes, web application vulnerabilities, and denial of service across C, Java, Python, Go, Rust, and JavaScript codebases.

Language and Repository Support

Constantine's LLM scanners work on any language — they analyze raw source text. The semantic file scorer that prioritizes security-relevant files supports 18 languages: Python, JavaScript, TypeScript, Java, C, C++, Go, Rust, Ruby, PHP, C#, Kotlin, Swift, Scala, SQL, shell scripts, and configuration formats (JSON, XML, TOML, INI). For languages not in the built-in list, Haiku automatically generates extraction patterns on first encounter.

Targets can be any git repository — public or private, GitHub or GitLab, monorepo or single-service. Constantine can analyze an entire repository at a single ref, a specific pull request or commit range, or focus on files identified by an imported threat model.

Two Operating Modes

Constantine runs as a Guard capability in two modes:

  • Customer engagement. Connect to a client's private repository. Constantine analyzes their code and reports findings as Risks in Guard, fully integrated into existing triage and remediation workflows. Every finding includes the evidence chain — detection reasoning, reviewer verdict, exploit proof, and validated patch.

  • Zero-day hunting. Point at any public repository — OpenSSL, nginx, Node.js, curl. Constantine finds vulnerabilities. A human reviews the results and coordinates responsible disclosure or submits to bug bounty platforms.

Cost Control

Three standardized pipeline configurations balance thoroughness against spend:

  • Premium — Up to 8M characters analyzed, 250 findings reviewed. Best for thorough scans of critical repositories.

  • Medium — Same analysis depth, 150 findings reviewed. Balanced cost and coverage.

  • Basic — Fast, low-cost scans reviewing up to 75 findings. Ideal for quick triage or continuous monitoring.

All tiers include real-time budget tracking with warnings at 50%, 80%, and 100% of spend. Budget enforcement can be set to warn-only (never lose a partially completed run) or hard-cap (halt when the budget is exhausted). Per-module, per-stage cost breakdowns are included in every report.

The Module System

Constantine's framework is deliberately thin — it contains zero security knowledge. All intelligence lives in 18 interchangeable modules organized across six pipeline stages. The framework handles orchestration: config loading, module discovery, subprocess execution, and inter-stage translation. Modules handle everything else.

A module is a directory with a descriptor file and an entrypoint. It can be written in Python, Go, Rust, or shell — the framework doesn't care. Modules within a stage run in parallel, and multiple modules can compete: a two-pass LLM scanner and an actor-skeptic scanner can both analyze the same code, and the framework merges their outputs.

Between each pair of stages, a single LLM call reads all module outputs and produces a coherent handoff document for the next stage. This translation layer means modules don't need to agree on a schema — a fuzzer that dumps crash files coexists with an LLM scanner that writes structured JSON, and the transition handles the translation. Modules declare what data format they need via entry prompts, and the framework reshapes the handoff accordingly.

How It Fits Into Guard

Constantine runs natively inside the Praetorian Guard Platform as a security capability. Findings flow directly into your Guard dashboard as Risks — complete with severity ratings, evidence chains, and validated patches. No separate tools to manage. No context switching. Just confirmed vulnerabilities with proof and fixes, delivered where you already work.