Source-linked AI summary
When Passing Tests Hides Vulnerabilities: An Empirical Study of Silent Failures in Agentic Systems
Wenji Bai, Muhammad Waseem, Zeeshan Rasheed, Jaakko Peltonen, Pekka Abrahamsson
TL;DR
LLM-based repair agents can pass functional checks while leaving security vulnerabilities insufficiently characterized. The paper empirically studies these silent failures across agent frameworks and security-focused datasets using layered verification, manual review, and qualitative coding. It identifies recurring failure categories and finds that test-passing evaluation and LLM-based review were insufficient to expose them in confirmed cases.
Problem
Patches that pass syntactic and functional verification may still retain or introduce security vulnerabilities, but these silent failures remain insufficiently characterized.
Method
The study analyzes 1,030 valid execution traces from seven agent frameworks across two security-focused datasets using multi-level verification, manual review, and iterative qualitative coding.
Results
The confirmed cases support a three-part taxonomy of Omission, Inadequacy, and Introduction, while test-passing evaluation and LLM-based review were insufficient to detect the failures.
Takeaways & Limitations
Security assurance for agentic repair should use targeted verification that covers the full repair scope rather than relying on functional correctness alone.
Takeaways & Limitations
The taxonomy includes Partial cases with less direct exploitability evidence, and the L3 threshold and scoring choices affect candidate selection and reported exploitability patterns.
Abstract
from arXiv · showhide
LLM-based agents for automated code repair have received significant attention in recent years from both research and software engineering practice perspectives. However, limited attention has been paid to patches that pass syntactic and functional verification but still retain or introduce security vulnerabilities. The aim of this research is to systematically identify and categorize such silent failures in LLM-based agentic code repair. We conducted an empirical study using 1,030 valid execution traces produced by seven agent frameworks with GPT-4o-mini across two security-focused datasets, SecurityEval and CVEfixes. Through three iterations of qualitative coding and manual verification, 170 confirmed silent failures were identified. The key results are: (i) Three main categories of silent failures were identified: Omission, Introduction, and Inadequacy. Omission accounts for 48.2% of the confirmed failures, Introduction for 30.6%, and Inadequacy for 21.2%. (ii) Ten fine-grained failure codes were classified under these three categories, showing how agents omit required security controls, apply incomplete defenses, or introduce new vulnerabilities during repair. (iii) Current test-passing evaluation and LLM-based reviewer roles were insufficient to expose or intercept these failures in the confirmed cases. (iv) Similar insecure solutions appeared across different frameworks, suggesting possible shared model-, prompt-, or task-level influences, while single-agent and multi-agent systems showed different failure profiles. The results of this study will assist researchers and practitioners in improving the evaluation of LLM-based agentic code repair and developing targeted verification methods that go beyond functional correctness and cover all generated artifacts.
1. Introduction
LLM-based agentic repair can produce patches that pass functional checks while retaining security vulnerabilities, yet these silent failures remain insufficiently characterized. This study develops an empirical taxonomy and examines their prevalence, propagation, and vulnerability contexts across frameworks and datasets.
- Motivation: Silent failures are patches that pass functional validation but still contain security vulnerabilities, allowing them to evade standard quality gates.Such patches may compile and pass unit tests while failing later static security analysis or exploitability assessment.
- Research questions: The study analyzes how silent failures vary by vulnerability type, code context, severity, exploitability, and agent architecture.The research questions cover failure prevalence, pipeline propagation, architectural differences, and susceptibility across vulnerability contexts.
- Study scope: 1,030 execution traces from seven agent frameworks and two security-focused datasets support an empirically grounded analysis of 170 confirmed silent failures.The study uses iterative qualitative coding and related execution artifacts to construct the analysis.
- Contributions: The taxonomy classifies silent failures by failure type, originator role, injection stage, and code location, extending failure analysis beyond externally visible breakdowns.This framework explicitly models failures that evade standard detection mechanisms.
- Contributions: The study also traces failure propagation across agent roles and compares propagation patterns between multi-agent and single-agent systems.These analyses examine whether specialized roles intercept or allow security deficiencies to persist.
- Contributions: The authors publicly release execution traces, generated patches, verification results, and taxonomy codes to support replication and validation.The dataset is intended for access by researchers and practitioners.
2. Research Methodology
The methodology combines shared experimental infrastructure with iterative execution, multi-level verification, manual review, and qualitative coding across seven agent frameworks. This design supports consistent comparison while tracing silent failures through the repair pipeline.
- Research design: The study uses two phases: preparation of shared infrastructure, followed by iterative data collection and analysis across seven agent frameworks.The preparation phase covers datasets, frameworks, model configuration, verification, and review criteria.
- Infrastructure: The study standardizes datasets, frameworks, verification, manual review criteria, and execution conditions to enable cross-framework comparison.The listed infrastructure includes the selected datasets, seven frameworks, model configuration, hardware, and verification pipeline.
- Verification: The verification pipeline evaluates patches through functional validation, static security analysis, and exploitability assessment after syntactic validity.The methodology diagram organizes these stages with candidate review and coding.
- Data collection: Each iteration samples tasks, runs all frameworks, evaluates generated patches, manually reviews flagged candidates, and qualitatively codes confirmed cases.Observations from each iteration inform the sampling and analytical focus of the next.
- Iteration plan: The data collection plan samples tasks across three iterations and records review and coding outcomes for the resulting cases.The plan is summarized in the iteration-based data collection table.
2.2. Dataset Selection
The study selects two Python security-repair datasets and seven recent open-source agent frameworks under criteria designed to support uniform, security-focused comparison. SecurityEval provides benchmark prompts, while CVEfixes supplies real-world vulnerability repairs.
- Dataset criteria: The dataset pool contains 1,236 Python tasks selected for security relevance, CWE annotations, uniform execution conditions, and public availability.Python-only filtering allows all seven frameworks to run under identical conditions.
- SecurityEval: SecurityEval contributes 121 Python tasks spanning 69 CWE categories for initial pattern discovery and cross-framework comparison.Each task presents insecure code and requests a secure version.
- CVEfixes: CVEfixes contributes 1,115 filtered Python single-file fixes linked to real-world CVE records and CWE annotations.These tasks often require adding new security logic to production code.
- Framework selection: Seven agent frameworks were selected for code-repair relevance, open-source availability, recency, and distinct coordination patterns.The selected frameworks were released between 2023 and 2026.
2.4. Experimental Setup
The experimental setup standardizes model, prompts, environments, and verification while combining automated L0–L3 checks with manual review and iterative coding. Candidates pass functional checks but are flagged when later security analysis or exploitability assessment raises concerns.
- Experimental controls: All frameworks use GPT-4o-mini with temperature 0.2, standardized prompts, isolated environments, and a shared verification toolchain.Experiments run on a fixed hardware configuration with a 600-second timeout.
- Security checks: Static analysis uses Bandit and maps findings to CWE identifiers, while exploitability scoring combines input sources, dangerous sinks, target-vulnerability indicators, and risky contexts.Safe-practice indicators receive bounded discounts in the exploitability score.
- Candidate screening: A score of 15 selects candidates for manual review, so the threshold functions as a sensitivity parameter rather than a final classification boundary.All selected candidates undergo manual review before confirmation.
- Verification framework: Every generated patch is evaluated through four levels: syntactic validity, functional validation, static security analysis, and exploitability assessment.Patches failing L0 or L1 are explicit failures; patches passing those levels but flagged at L2 or L3 become silent-failure candidates.
- Review and coding: Manual review examines patches, security findings, and task descriptions using a codebook, with iterative alignment, retrospective revision, and independent recoding of 20% of the corpus.Candidates are assigned to True Positive, Partial, or False Positive categories.
2.5. Data Collection and Analysis
The study collected and analyzed agent execution traces through iterative sampling, multi-level verification, qualitative coding, and inter-rater reliability checks.
- Data Collection: Three sampling iterations executed all seven frameworks, evaluated patches through L0–L3 verification, manually reviewed candidates, and used observations to guide subsequent analysis.The iterations sampled tasks, normalized outputs, screened traces, and refined later sampling and analytical focus.
- Coding Procedure: Open coding examined generated code, L2/L3 findings, and task context, then axial coding organized cases by failure type, originator role, injection stage, and code location.Each case also received propagation-chain, severity, and candidate-detection annotations.
- Coding Procedure: Coding completeness required no new codes across two consecutive batches of 50 traces, with cases repeatedly compared for consistency.The iterative comparisons supported refinement of the coding scheme before final application.
- Coding Procedure: Table 5 includes open codes such as Missing Sanitization, Unsafe Default, Ambiguous Repair Intent, Weak Mitigation, Introduced New Vulnerability, and Hardcoded Secret.These codes capture omitted controls, incomplete defenses, indeterminate repairs, introduced vulnerabilities, and embedded cryptographic secrets.
- Reliability Measures: A random 35-case subset produced substantial inter-rater agreement: composite κ=0.71, D0 κ=0.63, and D1 κ=0.66.Disagreements were resolved through author discussion, which clarified coding rules and refined category boundaries.
3. Results
The study identifies three recurring silent-failure mechanisms in patches that pass functional verification: Omission, Introduction, and Inadequacy. These mechanisms comprise ten fine-grained codes and include failures that omit controls, retain incomplete defenses, or introduce vulnerabilities.
- 3.1. Silent Failure (RQ1): The taxonomy contains three axial categories and ten open codes, with Insecure API Preserved the most frequent code in the corpus.The taxonomy was derived through qualitative coding of 170 confirmed silent failures.
- 3.1. Silent Failure (RQ1): Omission is the largest category, accounting for 82 of 170 confirmed silent failures (48.2%), followed by Introduction (30.6%) and Inadequacy (21.2%).Each case was assigned to its dominant failure mechanism, although a silent failure could exhibit multiple security symptoms.
- 3.1. Silent Failure (RQ1): Omission includes preserving dangerous APIs, missing required mitigations, leaving deployment risks or unsafe defaults unaddressed, and making cosmetic changes without removing the vulnerability.Insecure API Preserved occurred in 42 cases (24.7%), Missing Mitigation in 22 (12.9%), Deployment Context Risk in 9 (5.3%), and Unsafe Default Retained in 4 (2.4%).
- 3.1. Silent Failure (RQ1): Inadequacy comprised 36 cases (21.2%) where defenses were present but incomplete or bypassable, and it had the highest mean L3 exploitability risk at 17.7.Examples included partial defenses against path traversal, command injection, and eval-based execution.
- 3.1. Silent Failure (RQ1): Introduction comprised 52 cases (30.6%) in which repair injected vulnerabilities, including 41 newly introduced flaws, 10 hardcoded secrets, and one vulnerable test artifact.The vulnerable test-code case had an L3 score of 29.0 and reintroduced a previously fixed vulnerability into the workspace.
- 3.1. Silent Failure (RQ1): All confirmed cases passed L0 and L1 yet failed the task’s security intent, demonstrating security-compliance decoupling; reviewers rarely intercepted deficiencies in multi-agent pipelines.Planning-stage omissions and design-originated omissions or introductions propagated when downstream reviewers did not flag them.
4. Discussion
The discussion frames silent failures as security deficiencies that can survive functional evaluation, and distinguishes recurring mechanisms across omission, inadequacy, and introduction. These patterns motivate security-aware, mode-specific verification that examines upstream pipeline stages and all generated artifacts.
- Recurring mechanisms: Insecure API Preserved and Weak Mitigation account for 78/170 cases (45.9%), representing preserved dangerous calls and attempted but incomplete defenses.Weak Mitigation had the highest mean exploitability score among recurring open codes, at L3 = 17.7.
- Failure mechanisms: The three axial categories reflect different reasoning gaps: Omission misses required controls, Inadequacy implements incomplete defenses, and Introduction neglects the security of generated artifacts.The discussion links these distinctions to different remediation strategies and argues against treating security deficiencies as one homogeneous class.
- Security-compliance decoupling: Functional benchmarks would classify every confirmed case as successful, because the patches passed tests while retaining security deficiencies.The paper argues that functional test coverage alone is unlikely to eliminate silent failures because the evaluation oracle may not assess security properties.
- Pipeline propagation: Failures often originate during planning or design and persist through later handoffs, while reviewers rarely intercepted confirmed security deficiencies.The paper therefore treats reviewer failure as part of a broader chain-level problem rather than the sole source of missed defects.
- Cross-framework and architectural patterns: 107 of 170 confirmed failures were convergent, with 26 tasks triggering comparable failures across at least three frameworks, although model-, prompt-, and task-level effects remain inseparable.Architecture was associated with different profiles: multi-agent systems showed more Introduction failures, whereas single-agent systems showed more Inadequacy failures.
- Targeted verification: CWE family and code location were associated with expected failure categories, supporting targeted checks for API-substitution, logic-intensive, and repair-introduced vulnerabilities.The observed associations linked API-substitution vulnerabilities with Omission, logic-intensive vulnerabilities with Inadequacy, and vulnerabilities introduced during repair with Introduction.
5. Threats to Validity
The study’s validity is bounded by measurement choices, qualitative attribution, verification thresholds, dataset and framework coverage, and corpus-dependent conclusions.
- Construct Validity: 170 confirmed cases included 39 Partial and 131 true positives, and the taxonomy remained structurally stable when reanalyzed using only the 131 true positives.All three axial categories and seven of ten open codes remained represented; three omitted codes occurred only among Partial cases.
- Internal Validity: Bandit false negatives and the L3 threshold mean the confirmed corpus is a conservative estimate of failures detectable by the verification framework.Manual review addressed false positives, but failures scoring below the L3 threshold could be missed.
- Conclusion Validity: Role attribution and propagation-pattern coding require qualitative judgment, while small differences in reported distributions should not be interpreted as stable rankings.The authors used trace evidence, coding rules, consensus discussions, and a shared verification pipeline to reduce these threats.
- External Validity: The study is limited to Python repair tasks and should not be generalized to other languages or repository-scale repair.Multi-file repositories, complex dependency chains, and language-specific security idioms are underrepresented.
- External Validity: Because all frameworks used GPT-4o-mini, cross-framework failure convergence cannot be separated from model, prompt, benchmark, or task effects.The study treats the source of convergence as an open question and recommends replication with additional foundation models.
- Conclusion Validity: Framework execution is stochastic even though the verification pipeline is deterministic, so exact trace reproduction is not guaranteed.This constrains direct reproducibility of framework executions under identical inputs.
6. Related Work
Prior work evaluates test-passing repairs, explicit agent failures, plausible-versus-correct patches, or artifact security, but rarely connects these perspectives within agent pipelines.
- Benchmark Evaluation: Benchmark-based repair evaluation treats test passage as success without assessing whether a patch satisfies the repair task’s security intent.This creates a gap between functional validation and security-semantic correctness.
- Agent Failure Analysis: Agent failure taxonomies mainly cover observable signals such as crashes, errors, or non-completion, leaving failures that appear correct but remain insecure largely outside scope.The present study extends failure analysis toward silent security failures.
- Conclusive Summary: Table 10 positions prior work by whether it addresses benchmarking, taxonomy, propagation, role attribution, security verification, and silent-failure coverage.The table’s encoding is Y for explicitly addressed, P for partially addressed, and – for not a primary focus.
- APR and Security Repair: APR research distinguishes plausible from correct patches, while prior LLM vulnerability-repair studies show unreliable security correction but focus on individual patches rather than pipeline roles.The present work applies this plausibility gap to security and traces how deficiencies arise and propagate.
- Security Verification: Security-oriented verification adds security tests, static analysis, or formal methods, yet fixes can still pass surface checks while leaving weaknesses in place.Artifact-level verification reduces but does not eliminate surviving security deficiencies.
- Conclusive Summary: The study targets an unaddressed intersection: how functionally passing patches preserve or introduce vulnerabilities, propagate through agent roles, and evade review.Existing lines of work are only partially connected across benchmark evaluation, failure analysis, APR, and security verification.
7. Conclusion
The study characterizes security silent failures in agentic repair through a taxonomy, pipeline analysis, and cross-framework comparisons. It concludes that test passage and LLM review alone are insufficient assurance mechanisms.
- Conclusion: 170 confirmed silent failures from 1,030 valid traces support a three-part taxonomy of Omission, Inadequacy, and Introduction.The study analyzed seven agent frameworks across two security-focused datasets and examined propagation, framework, vulnerability-family, and code-location distributions.
- Conclusion: Test passage and LLM-based review were insufficient to detect these failures, while similar insecure solutions recurred across frameworks and failure profiles differed by architecture.The recurrence is consistent with shared model, prompt, task, and vulnerability-pattern factors, alongside architectural differences.
- Conclusion: Silent failures recur across vulnerability families, code locations, and generated artifact types in the studied corpus.The findings motivate verification that covers the full repair scope rather than relying on general post hoc inspection.
- Implications: The study recommends evaluating both functional validation and security-semantic correctness, while separating base-model and orchestration effects through controlled designs.It also calls for verification beyond the primary artifact and future replication across models, languages, and tool-supported agent designs.
CRediT authorship contribution statement
The authors’ contributions span conceptualization, methodology, implementation, analysis, validation, supervision, writing, and project administration.
- Contributions: Wenji Bai led conceptualization, methodology, software, formal analysis, investigation, data curation, original drafting, and visualization.Muhammad Waseem contributed to conceptualization, methodology, validation, review, editing, supervision, and project administration.
- Contributions: Zeeshan Rasheed contributed formal analysis and investigation, while Jaakko Peltonen and Pekka Abrahamsson contributed validation, review, editing, and supervision.Pekka Abrahamsson also contributed resources.
Data availability
The paper directs readers to reference for access to the dataset.
- The dataset link is provided in reference.
- Dataset access information is given through a cited reference rather than directly in this section.
- Readers seeking the dataset should consult reference.
Declaration of AI Assistance
The authors used ChatGPT for language and formatting assistance, then reviewed and edited the resulting content themselves.
- ChatGPT was used to refine grammar, improve sentence structure, and resolve formatting issues.
- The authors thoroughly reviewed and edited the content after using ChatGPT.
- The authors retain full responsibility for the final publication.