PaperlayerView exact revision on arXiv

Source-linked AI summary

Securing Agent-Generated Code with Its Own Development History

Prateek Kumar Rajput, Shahzeb Khan, El-Hacen Diallo, Yewei Song, Jacques Klein, Tegawendé F. Bissyandé

arXiv:2610.34098v1cs.SEcs.CR

TL;DR

Agent-written patches can pass functional tests while omitting security conditions, and final-snapshot review does not reveal the assumptions behind those omissions. TRACER uses symbol-level change history and verifiable rationale to gate repairs and preserve checks; rationale configurations led verified repairs on SusVibes, while repair memory plus a boundary gate preserved repairs in 9 of 10 feature tasks.

  • Problem

    Reviewers must reconstruct which assumptions an agent made and which security condition it omitted, while final-snapshot scanners report locations and flows without explaining those assumptions.

    Source: §I · p. 1

  • Method

    TRACER tracks changed symbols, tests recorded rationale against current code, gates repairs on assessment and functional validation, and preserves each invariant with an executable boundary check.

    Source: §I · p. 2

  • Results

    Rationale configurations yielded 76 and 75 verified security passes versus 68 on 345 patches; repair memory plus boundary gate preserved feature and repair in 9 of 10 tasks versus 4 of 10 for functional feedback alone.

    Source: §I · p. 2

  • Takeaways & Limitations

    TRACER carries investigation evidence forward as reusable checks that later changes must satisfy.

    Source: §I · pp. 1–2

    The results do not establish effectiveness in other languages or production deployments; the scientific-software maintenance study covers ten tasks across five selected components.

    Source: §IX · p. 10

Abstract

from arXiv · show

Pull requests written by coding agents can pass a project's test suite while omitting a guard or a validation step. To find the missing condition, a reviewer currently relies on static analysis of the final code. An agent-generated change, however, is accompanied by a development history that a human commit does not provide. The agent's trajectory records each edit together with the agent's stated assumptions, and structural differencing shows how each changed function evolved. We present TRACER, a workflow that uses this development history as evidence for security review. TRACER tracks changes at the symbol level, treats the agent's recorded rationale as claims to be verified against the current code, accepts a repair only after assessment and functional validation, and attaches to each accepted repair an executable check that later changes must satisfy. On the SusVibes benchmark, symbol-level tracking places the vulnerable symbol in the review scope for 94.6% of agent patches, compared with 13.4% for the primary scanner warning. With two investigator models, the configuration that includes the agent's rationale yields the largest number of verified security repairs while preserving functionality, and adding AST history to it does not increase that number. A funnel analysis identifies where the remaining candidates are lost. In a study of structural-biology software, the combination of repair memory and a boundary check allows a subsequent feature request to succeed in nine of ten tasks without reintroducing the repaired vulnerability, whereas functional feedback alone succeeds in four and reintroduces the vulnerability in three.

I. INTRODUCTION

Agent patches can pass functional tests while omitting security conditions, and final-snapshot scanners do not explain the assumptions behind those omissions. TRACER uses development history to guide guarded repair and preserve security checks across later changes.

I. INTRODUCTION

  • 350 of 354 agent patches passed functional tests, but only 69 passed security tests, leaving reviewers to find omitted conditions despite successful tests.Final-snapshot scanner warnings identify the reference-fixed symbol in 13.4% of patches in the studied cohort.Source: §I · p. 1
  • An agent trajectory records edits, tool calls, and stated assumptions, while structural differencing shows how changed functions evolve; these statements are evidence to verify, not faithful accounts of internal reasoning.A claim that an input is already validated creates an obligation to inspect the validator and its callers.Source: §I · p. 1
  • Security repairs can be undone by later changes even when functional tests pass, so TRACER retains the invariant, its rationale, and an executable boundary check for future proposals.The introduction describes a legacy-compatibility request that re-enabled unrestricted deserialization.Source: §I · p. 1
  • TRACER tracks changed symbols, treats recorded rationale as claims to verify against current code, gates repairs on assessment and functional validation, and binds accepted invariants to executable boundary checks.The check is tied to the repaired symbol’s structural hash and must pass for later changes.Source: §I · p. 2
  • 76 and 75 verified security passes, versus 68, came from rationale configurations on 345 patches; repair memory plus a boundary gate preserved feature and repair in 9 of 10 tasks, versus 4 of 10 for functional feedback alone.The rationale result held across both investigators, with at most one functional regression; the maintenance gate accepted no contract violations.Source: §I · p. 2
  • A four-step repair funnel and failure analysis distinguish losses in diagnosis, turn scheduling, and semantic repair from operational errors.The evaluation compares four evidence configurations across seven coding generators with two investigators, and separately studies repair memory and boundary feedback during feature evolution.Source: §I · p. 2

II. BACKGROUND AND MOTIVATION

Security review of a working agent-generated change requires reconstructing its assumptions and deciding which conditions must survive maintenance. Trajectories provide structural edits and recorded explanations that can be checked against current code.

A. Code Archaeology in Agent-Generated Pull Requests

  • Final-snapshot scanners report locations and flows, but connecting findings to the submitted change, its callers, and the intended contract remains the reviewer’s work.The review problem includes deciding which implementation assumptions deserve scrutiny and which security conditions must survive maintenance.Source: A. Code Archaeology in Agent-Generated… · p. 2, §II · p. 2
  • In the RFdiffusion checkpoint case, functional feedback alone restored unrestricted deserialization while ordinary and feature tests passed; a repair note and boundary check preserved restricted loading during compatibility work.The repair used weights_only=True with a scoped safe_globals allowlist; the later feature extended that allowlist to argparse.Namespace.Source: A. Code Archaeology in Agent-Generated… · p. 3

B. Evidence Available in an Agent Trajectory

  • Trajectories add structural edit history and recorded reasoning to the final snapshot, but neither supplies the requested behavior or domain assumptions, and explanations remain auditable claims rather than guaranteed reasoning accounts.Structural descriptions show function-level changes despite line shifts or refactoring; stated assumptions can be read alongside observed edits.Source: B. Evidence Available in an Agent… · p. 3

III. TRACER WORKFLOW AND ARCHITECTURE

TRACER organizes security investigation around changed symbols, scanner evidence, and two history channels, then gates repairs and carries their checks into later maintenance.

III. TRACER WORKFLOW AND ARCHITECTURE

  • The workflow attaches scanner evidence and history channels to a symbol-level view, uses a decision ledger and repair gate, and emits a persistent note and boundary check for later maintenance.Figure 1 summarizes this path from change evidence through guarded repair to checks on subsequent feature evolution.Source: §III · p. 3

A. Symbol-Level Change Tracking and Static Analysis

  • TRACER maps modified lines to enclosing functions, methods, and classes, attaches Semgrep and CodeQL evidence, and collects guard conditions and possible callers as context.Symbols are indexed by repository path, qualified name, line span, and structural hash; test and documentation files are excluded from modified-symbol mapping.Source: A. Symbol-Level Change Tracking and… · p. 3

B. Temporal AST Evolution via GumTree

  • Typed AST edit scripts highlight added, modified, or removed guards and calls, while the current code—not historical fragments—determines whether a suspected boundary is enforced.If a fragment cannot be parsed or a symbol cannot be linked across versions, TRACER records the gap rather than assuming continuity through a rename or refactor.Source: B. Temporal AST Evolution via GumTree · p. 3

C. Symbol-Linked Reasoning Traces

  • TRACER links original agent explanations to symbols and tests assumptions about inputs or callers against current source, retaining each quotation with its assessment.Because stated rationale may not match code behavior, each explanation is treated as a hypothesis to test.Source: C. Symbol-Linked Reasoning Traces · p. 3

D. Decision Ledger, Repair Gate, and Post-Repair Maintenance

  • The decision ledger records each hypothesis, target symbol, input boundary, and suspected flaw; a repair is accepted only after supported assessment, downstream-consumer review, and public functional validation.After repair, a persistent note binds the invariant to the symbol hash and an independently owned executable check; later proposals face ordinary, feature, and saved boundary tests, with one bounded retry on failure.Source: D. Decision Ledger, Repair Gate, and… · p. 3

IV. EXPERIMENTAL SETUP

The study tests localization, verified repair, provenance channels, repair-funnel losses, and preservation of repairs during feature evolution. It evaluates four evidence configurations on an admitted SusVibes cohort using two investigator models.

A. Research Questions

  • The five research questions cover vulnerable-symbol localization, verified repair without functional degradation, the effects of AST and rationale evidence, repair-funnel bottlenecks, and repair preservation during feature evolution.Source: A. Research Questions · p. 4

B. The SusVibes Benchmark and Study Dataset

  • The study admits 387 patches across 118 tasks from 1,302 archived patches; among 354 completed original evaluations, 350 passed functional tests and 69 passed security tests.The benchmark release contains 186 tasks; the original paper reports 200 tasks, repositories averaging 162K lines across 867 files, and 108 projects.Source: B. The SusVibes Benchmark and Study… · p. 4

C. Evaluated Configurations and Investigator Models

  • Two investigators review outputs from seven coding generators in four configurations: snapshot plus SAST, with temporal AST, with recorded rationale, or with both history channels.The investigators are DeepSeek-V3.2 and Gemini-3.8-Flash; all configurations receive the functional request, modified symbols, scanner findings, and the same repair protocol.Source: C. Evaluated Configurations and… · p. 4
  • Comparisons against C0 evaluate complete evidence bundles, while comparisons among C1, C2, and C3 isolate history-channel contributions; the benchmark hides prior repository Git history.The study uses Semgrep CE 1.101.0 and CodeQL 2.20.0 with specified Python rules and queries.Source: C. Evaluated Configurations and… · p. 4

D. Evaluation Protocol

The protocol evaluates repairs using official functional and security tests, while keeping hidden security tests and reference patches out of investigator feedback. The results section then addresses localization coverage, verified repair, and provenance-channel contributions.

D. Evaluation Protocol

  • Investigators receive public functional feedback, while hidden security tests and reference patches are reserved for retrospective evaluation.FuncPass and SecPass require recognized terminal test summaries, including expected-failure allowances.Source: D. Evaluation Protocol · p. 4
  • The shared comparison covers 345 patches completed in all eight configurations, with conditional repair outcomes and unresolved evaluations excluded from failed-security counts.A security conversion is an originally failing security outcome that becomes a verified pass after repair; preservation of an original pass is recorded separately.Source: D. Evaluation Protocol · p. 5

V. BENCHMARK REPAIR RESULTS (RQ1–RQ3)

  • The benchmark results address review coverage, end-to-end verified repair, and the contribution of each provenance channel.Source: §V · p. 5

A. RQ1. Symbol Localization Coverage

Symbol-level tracking brings reference symbols into review scope far more often than primary scanner warnings. Across paired patches, rationale-inclusive C2 produces the most verified security passes with both investigators, while combining rationale and AST history does not improve that count.

A. RQ1. Symbol Localization Coverage

  • 94.6% of 387 patches have a reference symbol in tracking’s review scope, versus 13.4% with a primary warning on that symbol.The scanner figures describe attention to the relevant symbol, not vulnerability-detection recall.Source: A. RQ1. Symbol Localization Coverage · p. 5

B. RQ2. End-to-End Verified Security Repair

  • On 345 shared patches, C2 reaches 76 security passes for DeepSeek and 75 for Gemini, from 68 originals, with at most one functional regression.C2 adds five net security passes over C0 for each investigator; the larger DeepSeek comparison preserves the same ranking, with 77 passes from 69 originals across 354 patches.Source: B. RQ2. End-to-End Verified Security… · p. 5

C. RQ3. Impact of Provenance Channels

  • C2 records eight conversions across six tasks for DeepSeek and seven across four tasks for Gemini.Several conversions concern the same task implemented by different generators.Source: C. RQ3. Impact of Provenance Channels · p. 5
  • Rationale alone yields more verified repairs than combining rationale with AST history: C2 records 76 passes for DeepSeek and 75 for Gemini, versus C3’s 74 and 73.Task-cluster intervals for C2’s gain over C0 include zero for both investigators, and the data do not support a claim of large improvement.Source: C. RQ3. Impact of Provenance Channels · p. 5

VI. REPAIR FUNNEL AND FAILURE ANALYSIS (RQ4)

The repair funnel follows candidates from a target-symbol hypothesis through assessment, editing, and retention, separating protocol completion from security outcomes. Most losses arise during diagnosis, before investigators support their hypotheses.

A. The Four-Step Repair Funnel

  • The funnel’s four nested steps are target-symbol hypothesis, supported assessment, reference-file edit, and nonempty retained patch; retention itself carries no functional or security verdict.A reference-file edit need not address the same symbol or hypothesis, and each step counts only cases reaching the preceding step.Source: A. The Four-Step Repair Funnel · pp. 5–6, Table III · p. 6

B. Drop-off 1. False Refutations During Diagnosis

  • The largest candidate loss occurs between forming a hypothesis and recording support for it, with premature refutations, wrong-property hypotheses, inconclusive assessments, and turn exhaustion among the observed reasons.A present guard may enforce a different property from the one required at the security boundary.Source: B. Drop-off 1. False Refutations… · p. 6

C. Drop-off 2. Turn Exhaustion Before Validation

  • Late edits can exhaust the turn budget before public validation, while validation slots and required probe reruns can also prevent retention.Source: C. Drop-off 2. Turn Exhaustion Before… · p. 6
  • In a recovery check of 70 candidates discarded for protocol-completion reasons, 39 passed functional tests and nine passed security tests.Eight security passes preserved successes and one was a new conversion; these recovery results are separate from campaign scores and do not establish that every loss was scheduling-related.Source: C. Drop-off 2. Turn Exhaustion Before… · pp. 6–7

D. Drop-off 3. Incomplete Fixes and Contract Mismatches

Functional success does not ensure that a retained repair satisfies the security contract: inspected cases include incomplete fixes, mismatched properties, and incorrect failure behavior. The study also describes operational errors and evaluates repair memory with boundary feedback in a structural-biology setting.

D. Drop-off 3. Incomplete Fixes and Contract Mismatches

  • Nine of 15 inspected functional-pass patches were incomplete repairs of the correct vulnerability class; four addressed another security property, and two enforced the right condition with the wrong failure behavior.The selected diagnostic cases show why assessment must check the full input and error contract, not merely the presence of a guard.Source: D. Drop-off 3. Incomplete Fixes and… · p. 7

E. Operational and Provider Failures

  • Gemini records 205 repair errors and DeepSeek 107, with labels spanning provider responses, parsing failures, and run interruptions.The study does not attribute causes beyond the recorded labels, and final candidate evaluations are reported separately from investigation errors.Source: E. Operational and Provider Failures · p. 7
  • The funnel separates candidate losses during diagnosis, validation scheduling, and semantic repair from operational errors and final test outcomes.Source: E. Operational and Provider Failures · p. 7

VII. INDUSTRIAL CASE STUDY. STRUCTURAL BIOLOGY PIPELINES (RQ5)

  • The industrial case study repairs five structural-biology components and tests ten subsequent feature requests in a 2 × 2 factorial of repair memory and boundary feedback.Source: §VII · p. 7

A. Repair Contracts and Independent Scope

TRACER’s biology maintenance study pairs repair contracts with controlled feature-evolution tasks to test whether later changes preserve repaired boundaries. Joint success is highest when repair memory and boundary feedback are combined.

A. Repair Contracts and Independent Scope

  • Five Python repair targets across five tools received boundary assertions that fail before repair and pass afterward, while ordinary-input controls pass in both states.Two targets are reliability contracts rather than exploitable vulnerabilities; four repairs were model-written, while the RFdiffusion remedy was developer-specified after two failed model attempts.Source: A. Repair Contracts and Independent… · pp. 7–8

B. Equal-Budget Feature Evolution

  • The ten feature tasks comprise two per repository and test compatibility, archive aliases, hierarchical names, in-memory pose output, and lazy parsing.Each repaired starting point passes its checks; evaluator-written references validate the checks, and the references are withheld from the model.Source: B. Equal-Budget Feature Evolution · p. 8
  • The factorial gives all four conditions the same token budget, functional feedback, and at most one retry; boundary checks influence retries only in conditions with boundary feedback.In B0 and B1, checks run after generation and do not affect the retry.Source: B. Equal-Budget Feature Evolution · p. 8
  • With functional feedback alone, 4/10 tasks succeed jointly and three contract-violating proposals are accepted; a boundary gate alone accepts none but reaches 3/10 joint successes.Memory alone reaches 8/10 joint successes but accepts one proposal that relaxes ProteinMPNN’s naming contract.Source: B. Equal-Budget Feature Evolution · p. 8
  • 9/10 tasks succeed jointly with memory and boundary feedback, versus 4/10 with functional feedback alone; the combined condition accepts no contract violation.The gate rejects the remaining naming violation and retains the repaired starting code.Source: B. Equal-Budget Feature Evolution · pp. 8–9

VIII. INDUSTRIAL RELEVANCE AND PRACTICAL TAKEAWAYS

The industrial discussion argues that functional success alone does not establish security and describes TRACER as a complement to static analysis. It recommends linking modified symbols and agent assumptions to review, and pairing repair guidance with executable checks for later changes.

A. Relevance to Industrial Software Engineering

  • In the SusVibes cohort, 350 of 354 patches pass functional tests, while 69 pass associated security tests; the primary scanner location matches the reference-fix symbol in 13.4% of admitted patches.The five repaired structural-biology components also contained defects in code that passed existing tests.Source: A. Relevance to Industrial Software… · p. 9

B. Actionable Takeaways for Practitioner Pipelines

  • C2 yields 76 verified security passes for DeepSeek and 75 for Gemini, versus 74 and 73 in C3; the experiment does not identify why.Context dilution is offered as a plausible, unestablished explanation; the stated rationale can provide a specific assumption to verify against code.Source: B. Actionable Takeaways for… · p. 9
  • Symbol-level tracking places the reference-fix symbol in review scope for 94.6% of admitted patches, versus 13.4% for the primary scanner location.Among 335 patches where the scanner missed that symbol, tracking supplied its complete body in 282 cases; coverage is an opportunity for diagnosis, not evidence that a condition is missing.Source: B. Actionable Takeaways for… · p. 9
  • For agent-generated changes, the proposed review scope is modified symbols and their callers, with scanner warnings and recorded assumptions used as evidence within that scope.The discussion also recommends linking stored reasoning excerpts to modified symbols and retrieving relevant excerpts at review time.Source: B. Actionable Takeaways for… · p. 9
  • Across ten maintenance tasks, repair memory plus a boundary gate yields 9/10 joint successes with no accepted violation, compared with 8/10 for memory, 3/10 for the gate, and 4/10 for functional feedback alone.Checks should cover newly introduced modes as well as defaults; a fallback retaining repaired code counts as failure to deliver the feature.Source: B. Actionable Takeaways for… · p. 9

IX. THREATS TO VALIDITY

The paper’s validity discussion limits what its benchmark tests, studies, and settings establish. Its related-work review situates TRACER among agent-code benchmarks, analysis-guided detection, and code-evolution and repair methods.

IX. THREATS TO VALIDITY

  • SusVibes tests verify specified contracts, not the absence of other vulnerabilities, and recorded rationale is not guaranteed to reflect a model’s internal reasoning.These boundaries constrain what benchmark outcomes and rationale evidence establish.Source: §IX · pp. 9–10
  • The maintenance factorial uses one investigator and one continuation per cell, while its feature tasks are a purposive stress sample designed with knowledge of the repairs.The fifteen semantic reviews were also purposively sampled and inspected by a single reviewer, so they do not support a population estimate.Source: §IX · p. 10
  • The studies cover ten tasks in five selected components and do not establish effectiveness in other languages or production deployments.The SusVibes sample also favors Python outputs with publisher-reported functional success, and 42 admitted patches lack complete shared outcomes.Source: §IX · p. 10

A. Benchmarks and Security of Agent-Generated Code

  • SusVibes separates functional from security outcomes for agent-generated changes, while the paper evaluates existing generated patches against its security oracle rather than generating new patches.The review places this work alongside SWE-bench, vulnerability-fix datasets, SWE-agent, and ReAct.Source: A. Benchmarks and Security of… · p. 10

B. Static Analysis and LLM-Assisted Vulnerability Detection

  • Prior analysis-guided approaches connect model judgments to dataflow, validation, or program behavior, but do not use the producing agent’s trajectory and rationale as evidence.The review also relates TRACER to function-level change representations, automated repair, persistent memory, and executable checks for benign feature evolution.Source: B. Static Analysis and LLM-Assisted… · p. 10

C. Code Evolution, Silent Fixes, and Automated Program Repair

The related-work discussion distinguishes TRACER’s function-level change analysis and persistent repair checks from prior approaches. The conclusion reports benchmark and maintenance results, and the paper identifies archived study materials.

C. Code Evolution, Silent Fixes, and Automated Program Repair

  • TRACER adopts CoLeFunDa’s function-level change representation and analyzes where candidate repairs are lost between diagnosis, retention, and verified repair.The review also discusses structural edit scripts, warning tracking, repair-pattern mining, and automated repair systems.Source: C. Code Evolution, Silent Fixes, and… · p. 10

D. Persistent Memory and Continuous Software Evolution

  • TRACER pairs each repair note with an independently owned executable check and evaluates benign feature evolution against the saved contract, rather than adversarial regression.The cited related work includes episodic feedback, iterative refinement, security-posture graphs, and deliberately elicited regressions.Source: D. Persistent Memory and Continuous… · p. 10

XI. CONCLUSION

  • On SusVibes, symbol tracking places the vulnerable symbol in review scope for 94.6% of patches versus 13.4% for the primary SAST location; rationale-inclusive review yields the most verified passes with both investigators.In structural-biology maintenance, memory with boundary feedback preserves the repair while delivering the feature in 9/10 tasks, versus 4/10 with functional feedback alone.Source: §XI · p. 10

DATA AVAILABILITY

  • The archive includes the skill, analysis helpers, derived outcome records, supporting tables, and RQ5 prompts, responses, candidates, and checks; raw transcripts, evaluator logs, and container exports are excluded.Benchmark inputs originate from SusVibes.Source: DATA AVAILABILITY · p. 10

Related papers

Loading 2610.34098v1…