AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair, by Michael Fu, Qiyue Mei, Patanamon Thongtanunam, and Kla Tantithamthavorn, was published on arXiv, operated by Cornell University, on July 30, 2026. It is a preprint, not a final peer-reviewed publication. The paper presents an automated vulnerability-repair framework that gives a patching agent structured knowledge about code relationships, observed execution, and repository history. By the end, you should understand how that context is assembled, how the system was tested, what its reported success means, and why sanitizer-verified patches still should not be treated as production-ready without review.

The starting problem is that ordinary bug-repair agents can search files, edit code, run tests, and refine a patch, but security failures may depend on interactions that are easy to miss: cross-file data flow, low-level memory behavior, and the history that introduced a fragile pattern. Earlier learning-based repair methods commonly operated at function or single-file scope. General-purpose agents gained repository access, yet the paper argues that they still lacked an explicit mechanism for assembling security-relevant context. AgenticRepair therefore treats context construction as part of the repair process, rather than expecting one language-model agent to discover, retain, and reconcile every relevant signal while patching.

The central research question is whether deliberately engineering several kinds of program context improves automated vulnerability repair. The authors also ask how much the context facets, multi-agent scaffold, and base-model capacity each contribute. This matters because a patch can remove a visible crash while misunderstanding the underlying ownership, data-flow, or historical invariant. The intended output is not merely plausible code: under the benchmark criteria, the patch must compile, stop the proof of concept from triggering the sanitizer error, and avoid new sanitizer-detectable problems.

AgenticRepair uses a staged multi-agent architecture. Specialized subagents independently derive code-structure, runtime-execution, and commit-history context. Structural analysis covers data flow, taint propagation, control dependencies, and memory-operation patterns. Runtime analysis executes the reproduction harness under instrumentation and condenses crash signatures, backtraces, memory observations, and likely root causes. History analysis mines changes preceding the vulnerable commit for relevant modifications and origin clues. These summaries are combined in persistent episodic memory for a repair subagent, which repeatedly proposes a minimal patch, rebuilds the project, and reruns the harness. The implementation used a fixed temperature of 1.0, up to 20 steps for each analysis subagent, and up to 75 steps for repair.

The full evaluation used 300 reconstructed SEC-Bench vulnerabilities drawn from 34 repositories, 32 projects, and 242 historical commits. Of these, 200 were Common Vulnerabilities and Exposures, or CVE, cases and 100 came from OSS-Fuzz. Each agent received an AddressSanitizer report and a human-written description, then worked with the vulnerable codebase and a reproduction environment. Under the paper’s strict evaluation, AgenticRepair repaired 220/300 cases for a 73% success rate. It exceeded the strongest Smolagents baseline using GPT-5.2 by 29% and repaired 86 additional vulnerabilities. On the subsets, it reported 75% for the 200 CVE cases and 70% for the 100 OSS-Fuzz cases. These are benchmark outcomes, not evidence of safe unattended deployment.

The architecture diagram is best understood as a funnel: several specialist investigations feed one persistent context, and a separate repair agent turns that context into a tested patch. The ablation table shows that removing any single context facet reduced strict success by only −0.5% to −2.0%, suggesting overlap and complementarity. Replacing the scaffold with a single agent caused a −44.5% drop even though the insights remained available. Using GPT-5-Mini reduced performance by 25%, while GPT-5-Nano reached only 10% success. The failure analysis is equally important: among 80 failures, improper-format patches accounted for 53, while 25 patches compiled but remained vulnerable. Successful patches were narrower, with a median of 32 edited lines across one file, versus 47.5 lines across two files for failed submissions.

Several cautions constrain the headline result. Success was defined through compilation, the supplied proof of concept, exit behavior, and sanitizer checks; that does not establish broad functional correctness or absence of other vulnerabilities. The authors identify possible training-data contamination because the base model may have encountered SEC-Bench material. Their low patch similarity analysis argues against simple memorization, but cannot eliminate that concern. Large language models are also nondeterministic, so a single reported run may not reproduce exactly. Most importantly, the study focuses on SEC-Bench and real-world C/C++ cases represented there. The paper explicitly calls for evaluation on other languages and vulnerability types. Results also varied substantially by repository and weakness category, so the aggregate rate should not be generalized uniformly.

For practitioners, the defensible takeaway is architectural: feed repair systems explicit structural, dynamic, and historical evidence, and keep diagnosis separate from final patch synthesis. The paper’s failures also point to concrete controls. Validate generated diffs before applying them, because malformed or truncated patches dominated the failures. Verification should include functional acceptance conditions and resource constraints alongside sanitizer outcomes. Treat patch breadth as a warning signal: failed submissions tended to touch more lines and files, suggesting that broad edits deserve extra scrutiny. This is practitioner interpretation based on the reported patterns, not a demonstrated production policy. A sanitizer-clean proof of concept is useful evidence, but the generated change still needs code review, broader regression testing, and security validation.

The enduring contribution is a concrete design for making an automated repair agent reason over the kinds of evidence security engineers already assemble: program structure, live execution, and change history. On SEC-Bench, that design produced stronger results than the evaluated agent baselines, while the ablations indicate that orchestration and model capacity mattered at least as much as any isolated context source. Security teams should consider richer context engineering and stricter patch-validation gates when evaluating repair automation. They should not infer that the reported benchmark rate transfers to other languages, repositories, or vulnerability classes, or that a passing sanitizer run makes a patch safe to merge autonomously.