PatchPilot: Diff-Gated Dependency Vulnerability Remediation with Deterministic Planning and Bounded Model-Assisted Source Repair
PatchPilot is a Visual Studio Code extension that improves dependency vulnerability remediation by strictly separating deterministic version selection and build adjudication from bounded, consent-gated LLM-assisted source repair, thereby ensuring safety through verifiable invariants and rollback capabilities.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Modern software is rarely built from scratch. Instead, it is assembled like a complex machine made of parts manufactured by thousands of different people. A typical application relies on hundreds of pre-made components, called dependencies, which in turn rely on thousands more. This creates a vast, invisible network where a single weak link can compromise the entire system. When a flaw is discovered in one of these parts, developers face a difficult choice: they must upgrade the part to a safer version, but that new version might not fit with the rest of the machine, causing it to break. Current tools are good at finding the flaw and pointing to a new part, but they are often terrible at ensuring the new part actually works with the existing code. They frequently suggest upgrades that introduce new vulnerabilities or break the software entirely, leaving developers to fix the mess.
This is the problem that Sivaprakash J and their team at the Anand Institute of Higher Technology set out to solve with a new tool called PatchPilot. Rather than trying to automate the entire repair process, which has proven risky and unreliable in previous attempts, the researchers designed a system that acts as a strict, transparent guide. The tool separates the job of fixing software into three distinct tasks: choosing the new part, fixing the code that connects the parts, and testing if the machine still runs. In most existing systems, an artificial intelligence agent tries to do all three at once, often guessing the wrong version or making changes that cannot be undone. PatchPilot refuses to let the computer make the most critical decision: which version of a dependency to install.
The researchers built PatchPilot as an extension for a popular code editor, allowing it to work directly within the environment where developers write their code. It supports three major software ecosystems, which are the standard ways developers manage their parts: npm for web development, Maven for Java, and PyPI for Python. When the tool scans a project, it looks for known security flaws in the installed parts. If it finds a problem, it does not guess a solution. Instead, it consults public safety databases and the official lists of available versions to find the newest, safest version that is guaranteed to be free of known flaws. This selection process is completely deterministic, meaning it follows a fixed set of rules and will always produce the same answer given the same information. It never relies on the unpredictable guesses of an artificial intelligence model.
Once the tool has identified the correct version, it prepares a detailed report showing exactly what will change. It displays a side-by-side comparison of the old code and the new code, highlighting the specific lines that will be altered. The developer must review this report and give explicit permission before any changes are made. If the developer approves, the tool makes a secure backup of the original files, applies the changes, and then immediately runs the project's own tests to see if the software still works. This step is crucial because it uses the project's own safety checks to decide if the upgrade was successful, rather than relying on the tool to guess.
If the tests fail, the tool does not give up, but it does not take over either. It offers a limited, controlled way to ask an artificial intelligence for help in fixing the broken code. This is the only time the AI is allowed to speak, and its power is heavily restricted. The AI is forbidden from changing the list of parts or the version numbers; it can only suggest edits to the source code files that are causing the test to fail. Furthermore, the AI cannot edit files that were not specifically selected for it, and it cannot make sweeping changes that affect the whole project. Before the AI sends its suggestions, the developer is shown exactly which files will be sent to the AI, what the AI is allowed to see, and which files are off-limits. The developer must consent to this specific exchange every single time.
The researchers tested this system rigorously to ensure it behaves exactly as designed. They created a series of unit tests that run without any internet connection or human intervention, verifying that the tool follows its rules in every possible scenario. They also ran the tool on four sample projects to watch the entire process from start to finish. The results showed that the tool successfully separates the decision-making powers. It never lets the AI choose a version, never edits a file without a clear backup, and never runs a command that could be hijacked by a malicious script. The tool explicitly admits when it cannot find a safe version or when a test fails, rather than hiding the problem or pretending the issue is solved.
The study concludes that while artificial intelligence is powerful, it is not yet reliable enough to make high-stakes decisions about software security on its own. The author found that previous attempts to let AI agents choose versions often resulted in selecting parts that were already known to be dangerous. By keeping the version choice in the hands of a fixed, auditable process and limiting the AI to a narrow, supervised role, PatchPilot offers a safer path forward. The tool does not claim to solve every problem; it admits that it cannot verify if a new version will work perfectly with every piece of code, and it does not try to fix projects that are too complex or use unsupported systems. Instead, it focuses on making the repair process transparent, reversible, and under human control. The researchers view this not as a final solution, but as a necessary step toward a future where automation can be trusted, by ensuring that the most dangerous decisions are never left to chance.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.