Constantine: Locates Fatal Security Bugs in Software & Code Repository Security Analysis

How to use Constantine's autonomous vulnerability discovery and patching engine, and its code repository security analysis capability — including CVE benchmark coverage, LLM-driven entrypoint discovery, the agentic threat-hunting agent, proof-of-exploitation lifecycle tabs, build caching, and scored repository findings via the CLI and MCP server.

Overview

Constantine is Praetorian Guard's autonomous vulnerability discovery and patching engine, and a code repository security analysis capability. It analyzes software repositories to locate exploitable security bugs, generate proof-of-exploitation artifacts, and produce patches — all without requiring manual operator involvement at each step. Constantine also performs automated security analysis of code repositories, producing scored findings that feed directly into the Guard platform.

CVE Benchmark

Constantine's analysis pipeline is validated against a continuously maintained CVE benchmark. The current version (v3) covers:

  • 295 verified records — each CVE is mapped to its fix commit and verified against live git history.
  • 12 languages — Bash, C/C++, C#, Go, Java, JavaScript/TypeScript, Kotlin, PHP, Python, Ruby, Rust, and Swift.
  • 91 CWE classes — up from 8 CWE classes in the previous benchmark.

This benchmark is used internally to measure and improve detection quality across language and vulnerability class combinations. The breadth of coverage directly influences which findings Constantine can reliably discover and exploit in your repositories.

Entrypoint Discovery

Constantine includes an ingest module that automatically enumerates HTTP and RPC entrypoints in a repository before analysis begins. This gives the analysis pipeline a structured map of the application's attack surface without requiring manual annotation.

How it works

The module uses a hybrid detection approach:

  1. Tree-sitter route seeds — a syntax-aware parser extracts route definitions across 11 supported languages.
  2. LLM extraction pass — a batched language-model pass resolves ambiguous or dynamically constructed routes that static parsing alone cannot resolve.
  3. Handler resolution — string-referenced handlers (common in framework routing tables) are resolved to their concrete file, symbol, and line number.

Each discovered entrypoint is recorded with its handler file path, symbol name, and line number, giving Constantine precise anchors for vulnerability analysis.

Supported frameworks

The hybrid detector covers a broad set of routing frameworks, including:

  • PHP — Laravel
  • Ruby — Rails
  • Python — Django
  • Go — standard net/http and popular routers
  • Kotlin — Kotlin DSL (Ktor and similar)

All 11 languages supported by the tree-sitter pass benefit from entrypoint discovery, with LLM-assisted resolution applied where static extraction is insufficient.

Run Modes

Constantine supports four targeted run modes. Each mode performs a discrete phase of the vulnerability remediation lifecycle, allowing you to invoke only the work that is needed for a given finding.

Mode

What it does

Exploit only

Attempts to produce a working proof of exploitation for the target vulnerability. No patch is generated.

Patch only

Generates a code patch for the finding without re-running exploitation.

Validate only

Runs validation checks against an existing patch to confirm the vulnerability is resolved.

Patch and PR

Generates a patch and opens a pull request in the target repository.

Proof-of-Exploitation Lifecycle

Constantine tracks each finding through a structured lifecycle. The relevant status tabs reflect which phases have completed and what artifacts are available (exploit proof, patch diff, validation result, pull request link).

Agentic Remediation via Marcus

The Marcus agent can invoke Constantine directly, enabling fully autonomous remediation workflows on specific findings without manual operator steps.

How it works

When Marcus is tasked with remediating a finding, it uses a dedicated Constantine tool that:

  1. Resolves the correct repository by walking the HAS_VULNERABILITY graph edge from the finding.
  2. Computes the stable content-hash proof path that Constantine's report module requires.
  3. Dispatches the appropriate Constantine job — exploit, patch, validate, or patch-and-PR — based on the task.

All four run modes (exploit_only, patch_only, validate_only, patch_and_pr) are available to the agent, so Marcus can carry a finding through the full remediation lifecycle end-to-end.

When to use agentic invocation

Use Marcus to invoke Constantine when you want to:

  • Remediate a batch of findings without stepping through each one manually.
  • Integrate autonomous patching into a pipeline where Marcus is already orchestrating other actions.
  • Delegate exploit-validation cycles to the agent while you review outcomes asynchronously.

For single findings where you want direct control over each phase, invoking Constantine's run modes from the Guard UI remains the recommended approach.

Build Caching

Constantine caches build artifacts across runs for the same repository. Repeated invocations — whether triggered manually or by Marcus — reuse cached builds where possible, reducing total job time for iterative exploit-patch-validate cycles.

Code Repository Security Analysis

Constantine can perform broad, automated security analysis of a code repository, scoring it against a set of security checks and surfacing the results as findings in Guard. This capability operates independently of the exploit-patch lifecycle and is suited to situations where you need a risk-scored view of a repository's overall security posture.

How it works

Constantine resolves the target repository, then executes a declarative plan of analysis modules in a stage-ordered pipeline. Each module can consume LLM, skill, graph, and tool services during execution. Results from all modules are aggregated and surfaced as scored findings in Guard.

  • Repository targeting — a local path or remote Git URL is resolved before any scan begins, ensuring every run operates on a confirmed, identifiable target.
  • Plan-based execution — a declarative plan specifies which modules run, their ordering via dependency edges, and per-module configuration. Adding a module to a plan requires only adding a file.
  • Graph-backed analysis — an integrated code graph store enables traversal-based queries during module execution.
  • Extension support — provider, source, tool, store, and skill extension kinds are supported, with a promotion gate that keeps self-evolving extensions measurable.

Scored repository findings

The scored-repo module produces a normalized risk score for each analyzed repository, surfaced as findings in Guard. To run a scored-repository analysis:

constantine run start \
  --target git=<repo-url> \
  --plan '{"entries":{"scored-repo":{}}}' \
  --budget <n>

Replace <repo-url> with the remote Git URL or local path of the target repository, and <n> with your allocated budget for the run. A freshly built binary runs with no configuration file required for this command; defaults cover the common case.

Budget controls

Every run is bounded by a configurable budget. This applies to both CLI-initiated runs and agent-initiated runs through the MCP server — MCP sessions enforce a ceiling so no single agent-initiated scan can exceed the allocated spend.

MCP server mode

Constantine can be started as an MCP server, exposing tools that let AI agents initiate and manage repository scans programmatically. Any MCP-compatible AI agent can connect to Constantine in this mode to trigger and monitor runs.

To start the MCP server:

constantine serve

Agent-initiated scans through the MCP server are subject to the same budget ceiling as CLI-initiated runs.

  • Marcus — the Guard agentic orchestration layer that can invoke Constantine and other tools autonomously.
  • Vespasian — API discovery that surfaces endpoints Constantine can target.