Constantine: Locates Fatal Security Bugs in Software

Overview

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.

Why Now

On April 7, 2026, Anthropic announced Claude Mythos Preview — a frontier model that autonomously discovered thousands of previously unknown zero-day vulnerabilities across major operating systems and browsers, including bugs as old as 27 years. Anthropic is releasing Mythos only to roughly forty Project Glasswing members while they help harden the world's most critical infrastructure. Everyone else is on their own timeline — and so are the adversaries.

Constantine exists for everyone else. The same defensive strategies proven in the DARPA AI Cyber Challenge — structured pipelines, adversarial validation, proof-of-exploit testing, validated patching — are production-deployable today, running against your own codebases, on frontier models you already have access to. You don't need a Glasswing invitation to get ahead of this curve. You need the pipeline, your source, and a budget.

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. If you already have a threat model, Constantine imports it and focuses the scan on the declared attack surface. If you don't, Constantine generates one from your source — business context, architecture map, trust boundaries, entry points, and data flows — and threads it through the rest of the pipeline.

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. Because the call graph is pre-computed, per-finding verification runs in about 40 tool calls instead of 120 — three times the precision at a third of the cost.

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 a human-readable Markdown report alongside the structured findings JSON, manifests, and cost records each module writes to the run directory — giving platform integrations a machine-readable evidence trail and reviewers a single narrative to open. 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.

Recent Public Disclosures

Beyond benchmark validation, Praetorian researchers have publicly disclosed real-world vulnerabilities in production open-source software through coordinated disclosure. These fall into three categories, based on how disclosure resolved.

Assigned CVEs

Each of the following has an assigned CVE and a vendor-released fix:

Responsibly Disclosed (No CVE Assigned)

Vulnerabilities that were resolved through coordinated disclosure without a CVE being issued, but with public attribution and a vendor-shipped fix:

Independently Identified

Vulnerabilities Praetorian researchers identified whose public CVE credit went to other reporters — typically because project maintainers (or other researchers) disclosed first. Listed here for transparency; Praetorian does not claim discovery credit for these.

These disclosures reflect the broader Praetorian research program; Constantine codifies the same analysis patterns the team applies against open-source targets at scale.

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 ships built-in patterns for 15 programming languages (Python, JavaScript, TypeScript, Java, C, C++, Go, Rust, Ruby, PHP, C#, Kotlin, Swift, Scala, shell) and 11 data and configuration formats (SQL, YAML, JSON, XML, TOML, INI, HTML, and common templating formats). For anything unrecognized, Haiku generates extraction patterns on first encounter and caches them for the rest of the run.

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 Private Repositories 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.

• Public-Research Mode 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.

Deployment and Data

Constantine is designed for the customer boundary, not a vendor's black box.

Where your source goes. The only thing Constantine sends externally is the source it analyzes and the intermediate artifacts the LLM reasons over. That traffic goes to whichever model provider you configure — Anthropic directly, or AWS Bedrock via LiteLLM. When you point Constantine at Bedrock models inside your own AWS account, source code never leaves your AWS boundary. Nothing is sent anywhere else — no telemetry, no third-party cloud, no data broker.

Mixed providers for compliance boundaries. The pipeline can default to one provider and override individual modules to another — e.g. run on Anthropic by default but route a specific scanner to Bedrock DeepSeek to keep that module's traffic inside a compliance-approved region. Credentials for every model the pipeline references are validated before the run starts, so an auth mismatch surfaces at launch rather than mid-scan.

Docker is required for the full exploit stage. The default agentic exploiter runs inside a Docker-in-Docker sandbox so exploit code executes in isolation. For environments that block DinD (locked-down CI, some enterprise laptops), a no-dind variant runs exploit scripts in a local subprocess with timeouts and resource limits instead. Detection, verification, patching, and reporting all work without Docker — only the agentic exploiter needs it.

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 three standard tiers run ingest → detect → review → report. The exploit and patch stages are available as opt-in extensions for engagements that require proof-of-vulnerability and validated fixes — they add significant compute cost per finding, so they are not enabled by default.

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, 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.