3.6 How to apply processes for using AI to find and fix vulnerabilities
So while AI systems can, with a good model, sometimes find and fix some vulnerabilities, we usually want to be more thorough. How can we apply those processes, though?
These added processes for finding and fixing vulnerabilities can be human-guided, automation-guided, or a mix:
Human-guided processes. These can be as simple as carefully walking an AI through a step-by-step process. For example, a human could demand that the AI report all potential vulnerabilities as findings, completely separating the validation of those findings into a separate step. Doing this can reduce the risk of an AI model discounting a finding that was exploitable because the AI was doing both steps at once.
Fully-automation-guided systems. Fully automated systems are the cyber reasoning systems (CRSs) we discussed earlier, discussed in materials such as [Wolff2026].
Mixed systems. Systems may be partly automated but have mechanisms for humans to provide information and guidance as they go.
Unsurprisingly, many different organizations and projects have developed processes to improve finding and fixing vulnerabilities using AI. As noted by Cycode, “AI-driven vulnerability discovery is no longer a single-vendor story. It is an industry capability, and it has arrived faster than most security programs are prepared for.” [Cycode2026]
Here are a few examples of processes people have used (beyond the list from [Bourzikas2026] and [Yan2026] we showed earlier):
[Wolff2026] emphasizes that AI is most effective when combined with existing analytical techniques. This paper describes the following components of a typical CRS:
Microsoft’s MDASH system uses a set of specialized AI agents working through a staged pipeline, rather than a single, highly capable model running in an agent framework [Bishop2026]. Their harness orchestrates more than 100 specialized AI agents across an ensemble. It’s essentially a “structured pipeline that takes a codebase and emits validated, proven findings” through these stages:
Prepare stage: Ingests the source and target, builds language-aware indices, and then derives the attack surface and threat models by analyzing past commits.
Scan stage: Runs specialized auditor agents over candidate code paths, emitting candidate findings with hypotheses and evidence.
Validate stage: Runs a second cohort of agents—debaters—that argue for and against each finding’s reachability and exploitability.
Dedupe stage: Collapses semantically equivalent findings (for example, patch-based grouping).
Prove stage: Constructs and executes triggering inputs that the bug class admits. The prove stage validates the pre-condition dynamically and formulates the bug-triggering inputs to prove [the existence of a] vulnerability (for example, ASan in C/C++). [Kim2026]
Most of these systems can be used with three types of scanning actions:
Full scans, where the full codebase is scanned all at once,
Branch scans, where a new branch (or each new branch) is scanned
Pull Request (PR)/Merge Request (MR) scans, like branch scans but findings are reported in the PR/MR which concern the branch (similar to how many humans perform review) [Rogers2025]
Finding and Fixing Vulnerabilities Using AI