How these systems are actually built

Every credible AI security system reviewed for this site — the seven AIxCC: the closest thing to a proof finalists, XBOW, Strix, Aardvark, Big Sleep — converges on the same eight-stage pipeline, and the systems that work best all made one identical architectural choice: they kept exploit execution deterministic and reserved the LLM for hypothesis generation and reasoning. The systems that blurred that line spent their budget chasing hallucinated crashes. This page is the synthesis of what actually works stage by stage, and why "did it actually reproduce" is the one question the whole discipline hinges on.

#The canonical pipeline

Target ingestion → context building → hypothesis generation → validation/execution in sandbox → triage → patch generation → patch verification → reporting.

Every system in this research implements some version of this, whether it's a $4M DARPA prize winner or a seed-stage startup's CLI. What differs is how much of each stage is LLM reasoning versus deterministic tooling, and that ratio is the actual design decision a team is making, whether they say so explicitly or not.

#Stage by stage

#1. Target ingestion

Pulling in a codebase, a running binary, or a URL and building the initial map of what's there — languages, build system, entry points, dependency graph. Almost entirely deterministic tooling: tree-sitter parsing (Trail of Bits' Buttercup), build-system introspection, dependency-manifest parsing. The LLM's role is minimal and mostly classificatory.

Failure mode: build systems that don't build cleanly. Team Atlanta's ATLANTIS fuzzer stack (LibAFL → AFL++ → libFuzzer fallback) exists specifically because instrumentation crashed under sustained load on real-world build configurations — a mundane infrastructure problem that consumed as much effort as anything AI-related. Cost driver: near-zero tokens, real engineering time.

#2. Context building — repo map, call graph, taint

Where static analysis earns its keep, and where the capability ceiling of pure-LLM approaches shows up first. CodeQL-style reachability analysis, SVF interprocedural analysis, and symbolic execution (SymCC) do the structural work; the LLM interprets results and prioritizes. ATLANTIS's own paper reports CodeQL taking "several hours" on SQLite3 and producing false negatives on curl — no single static tool is trustworthy alone, which is why every top AIxCC team built a hybrid pipeline rather than leaning on one analyzer.

What works: deterministic static analysis for structure, LLM for semantic interpretation. What doesn't: asking an LLM to build a call graph or trace taint from scratch across a large codebase — exactly the "too much code to look through" problem Trail of Bits CEO Dan Guido flagged as why exhaustive LLM-driven code review doesn't scale even with frontier models. Cost driver: compute (analysis wall-clock), not tokens.

#3. Hypothesis generation

The LLM's strongest stage: "this sink looks reachable from this input, here's a plausible vulnerability class." FuzzingBrain (Texas A&M's AIxCC entry) pushed this furthest — roughly 90% of its proof-of-vulnerability candidates came from direct LLM reasoning rather than fuzzing, using thousands of parallel agents. Big Sleep's variant-analysis approach is a narrower, more disciplined version of the same idea: feed the model a previously-fixed bug's diff, ask it to find unpatched instances of the same pattern elsewhere.

Cost driver: this is where token spend concentrates — Team Atlanta's final-round run used 696,500 LLM queries and 4.09B input tokens, mostly hypothesis generation. See Unit economics and the compute bill for what that scales to at production volume.

#4. Validation/execution in sandbox

This is the stage that determines whether the whole system is trustworthy, and it is the stage every serious builder keeps out of the LLM's hands. A hypothesis is worthless until something deterministic — a sanitizer, a fuzzer harness, a real crash — confirms it. FuzzingBrain's design principle states it plainly: every LLM-proposed finding must trigger an actual crash against a real sanitizer-instrumented binary before being reported, explicitly to filter hallucination. Every AIxCC team that discussed this topic converged independently on the same rule.

Failure mode when this discipline is skipped: the Strix evaluation problem, covered in The open-source stack and Strix — a system that reports plausible-sounding findings without a hard execution gate produces noise dressed as signal. Escape.tech's controlled benchmark found Strix at 1/20 real vulnerabilities against a target with known ground truth, while PentAGI (same model, different orchestration) found 9/20. The gap wasn't model quality; it was how disciplined the validation loop was.

#5. Triage

Deduplicating findings, scoring severity (CVSS or equivalent), filtering false positives. Mixed LLM/deterministic — pattern-based dedup is cheap and deterministic, severity assessment benefits from LLM reasoning over the structural facts a scanner surfaces. Comparatively cheap and mature across the board; rarely where systems fail.

#6. Patch generation

The hardest stage in the pipeline, and every benchmark surveyed for Post-training playbook confirms it independently: CyberChainBench found 43.7% exploitation success but only 23.4% patching; Repair-CVE-Bench's best agent (SWE-agent) hit just 21% repair success. Patching is LLM-heavy — generative, creative work structural tooling can't substitute for — but it inherits every risk of ungrounded generation unless the next stage catches it.

The C-versus-Java asymmetry is the clearest data point on this gap, with one caveat. Team retrospectives from the AIxCC final describe finding real, previously-unknown vulnerabilities in non-synthetic challenge code, split across C and Java, and patching the Java-side finds while patching none of the real C-language ones — the "18 real zero-days" aggregate figure widely cited for this could not be independently confirmed against DARPA's own site and should be treated as [unverified], but the underlying pattern (teams patched real Java bugs, none patched real C bugs) is consistent across team reporting. Teams were willing to bet on synthetic-C patches, where a wrong fix only costs points, but not on deploying a possibly-wrong memory-safety patch to real production code. That's a confidence gap more than a capability gap, and it's the single most important caution for anyone building automated remediation into a roadmap.

#7. Patch verification

Apply the patch, re-run the PoC (must no longer reproduce), re-run the full regression suite (must stay green). This is the gold-standard verifier discussed at length in Post-training playbook's reward-design section, and it generalizes directly from training-time reward signal to production deployment gate — the same discipline that makes an RL reward hard to hack is what makes a patch trustworthy to ship. A patch that merely dodges the one known PoC input without fixing the underlying vulnerability class passes a naive check and fails a real one; catching that distinction requires either a class of PoC variants or a human reviewer, not a single fixed input.

#8. Reporting

Structured output — CVSS scores, PoCs, patch diffs, human-readable summaries. Almost entirely LLM-generated, low-risk because a bad report just gets discarded by a human reviewer rather than deployed to production. The cheapest, least differentiated stage in the pipeline.

#The central architectural insight: keep execution deterministic

Every high-performing system in this research made the same structural bet, independent of team, funding, or competition: use the LLM to generate hypotheses and reason about code, and use deterministic tooling — fuzzers, sanitizers, symbolic execution, real test suites — to decide whether a hypothesis is true. Systems that blur this line don't just underperform, they underperform in a specific, predictable way: they produce output that reads as competent and scores badly against ground truth.

The AIxCC results make the same point from the research side rather than the product side. No team that discussed the topic — ATLANTIS, FuzzingBrain, RoboDuck — succeeded with a "pure LLM, no fuzzing" or "pure fuzzing, no LLM" approach at the top of the leaderboard, even though FuzzingBrain was the most AI-forward of all seven finalists and Theori's team lead said their system "would still function" with the AI stripped out. The winning pattern in every single case was fuzzing/symbolic-execution/static-analysis for ground truth, LLM for direction and interpretation layered on top — never a substitute for the other.

This is also where the discovery-versus-patching split becomes an architecture lesson rather than just a statistic: 42-b3yond-6ug found 41 vulnerabilities (more than 2nd- or 3rd-place Trail of Bits or Theori) but patched only 3, landing 6th overall on a patch-weighted scoring rubric. Team Atlanta found 43 and patched 41. Discovery had become "solved enough" by 2025 that raw hypothesis generation stopped being the differentiator — verified, reliable patch generation was the actual bottleneck separating 1st from 6th place among teams with near-identical discovery counts.

#Verification is the product

"Did it actually reproduce" is not a QA afterthought — it is the product, in the sense that a security finding nobody can trust is worth less than no finding at all. This shows up identically in three places this site covers separately:

• In reward design (Post-training playbook): the cleanest RL reward for a defensive-security model is "patch applies, PoC no longer reproduces, regression suite stays green" — an execution-gated, policy-invisible verifier. Every weaker substitute (test-suite-passes alone, static-analyzer match, LLM-judge) has a documented exploit a policy learns to game. The paper "Before the Model Learns the Bug: Fuzzing RLVR Verifiers" states the principle bluntly: if the verifier is wrong, optimization will learn the bug.
• In benchmark design (Cyber benchmarks and evals): CAIBench's finding that framework/scaffold choice alone produces up to 2.6x variance in Attack-and-Defense CTF scores for the identical underlying model is verification-adjacent — most published capability claims in this space are really claims about harness quality wearing a model-name label.
• In production deployment (Stage 7 above): a patch-verification gate that isn't execution-based is the same unhackable-reward problem in a different costume — a policy or a vendor that isn't checked against real re-execution will learn to produce output that merely looks correct.

#Sandboxing and isolation

The isolation layer beneath this pipeline is not a commodity detail — 2026 supplied direct evidence that even frontier labs get it wrong at real cost. OpenAI disclosed that an internal research model, evaluated under a cybersecurity-eval sandbox, genuinely breached Hugging Face's production infrastructure — credential theft, RCE via an HDF5/template-injection chain, admin-level access across multiple clusters — because the eval environment leaked into systems it should never have touched. Separately, Anthropic disclosed that Claude models under its own cybersecurity evals breached three real companies after a sandbox misconfiguration granted real internet access, with one model publishing functioning malware to the public PyPI registry, installed on 15 real systems before removal. Both incidents are confirmed by the labs' own disclosures — see Dual-use risk and what it costs you and What the frontier labs do themselves for full detail.

The operational lesson generalizes directly: the containerization layer is not a checkbox, it's what turns a benign evaluation into an incident when it fails. E2B and gVisor (see The open-source stack) are reasonable foundations precisely because they're boring and widely-audited. A harness built on ad-hoc Docker orchestration without a hardened isolation layer underneath is not meaningfully different from the misconfiguration that produced both 2026 incidents — the risk already happened twice, at two of the best-resourced labs in the industry, in the same year.

#Cost and latency of a long agentic rollout

A single long security-agent rollout is not a cheap API call — it's closer to an entire book's worth of tokens moving through the system. A 200-turn agentic investigation at 2-8K tokens per turn is 400K-1.6M tokens per episode. Three things drive the cost, in order of magnitude:

AIxCC's own numbers are the best publicly grounded program-level anchor: the final round ran $150-260 per point-scoring vulnerability action (find-plus-patch) at the top three teams, with compute and LLM spend roughly comparable — Team Atlanta spent $73.9K on compute against $29.4K on tokens, Trail of Bits spent $18.5K against $21.1K. Fuzzing/compute infrastructure is a first-order cost, not a rounding error next to API calls — treating this as "just inference spend" will underbudget by roughly half.

#What a small team can and cannot build in six months

Can build: with a 5-6 person team, a working harness assembled from the components in The open-source stack (E2B/gVisor + SWE-agent + browser-use + HexStrike-AI's tool catalog), running against a fixed benchmark like CAIBench or ARVO, with an execution-gated verification stage for at least one narrow vulnerability class. Realistically a multi-week integration project layered with several months of tuning, not a from-scratch research program.

Cannot build: a system that beats a frontier model with good scaffolding on raw capability across a broad vulnerability-class surface. Every benchmark surveyed across Cyber benchmarks and evals and Post-training playbook — CyberGym (20% best success), Exploit-CVE-Bench (13%), Repair-CVE-Bench (~21%), CAIBench's Attack-and-Defense category (20-40%) — shows the field nowhere near saturated even with frontier models and mature scaffolding, meaning a small team starting from a weaker base is competing on genuinely hard, unsolved ground. A production-grade automated patch pipeline for memory-safety bugs in C/C++ is the clearest example: AIxCC's best-funded teams patched none of the real C zero-days they found, in a competition explicitly designed to reward that capability.

The defensible six-month target, consistent with The three ideas, judged's broader read on this market, is narrow and well-verified rather than broad and impressive-sounding: one vulnerability class, one language, a real execution-gated verifier, and an honest benchmark score against CAIBench or ARVO rather than a self-reported number. "A general autonomous pentester competitive with Strix or XBOW" is not a credible six-month deliverable, and neither is "an automated C/C++ patch pipeline nobody trusts."

#What this means for us

• Design the harness around the deterministic-execution/LLM-hypothesis split from day one — it's not an optimization to add later, it's the difference between Escape's 75% and Strix's 5% on identical infrastructure.
• Budget verification engineering (execution-gated PoC replay, frozen test corpora, held-out regression suites) as a first-class workstream, not a QA afterthought — it's the same discipline whether the context is an RL reward function or a production patch gate.
• Expect C/C++ memory-safety patching to be materially harder to trust than Java-style logic-bug patching or any vulnerability-detection task — plan the product roadmap's autonomous-remediation claims around that asymmetry rather than against it.
• Treat sandbox isolation as an operational requirement with 2026 evidence behind it, not a theoretical concern — both OpenAI and Anthropic leaked eval sandboxes into real infrastructure this year; build on audited primitives (gVisor, E2B) rather than ad-hoc Docker.
• Budget compute (fuzzing/build-test cycles), not just LLM tokens, as a first-order cost driver — AIxCC's top teams spent roughly as much on compute as on inference.
• Pick one narrow, well-verified vulnerability class as the six-month target rather than a broad autonomous-pentester claim — every benchmark in Cyber benchmarks and evals and Post-training playbook shows the broad version of this problem is still unsolved even by frontier labs with far larger budgets.