Skip to content

Lesson 9 of 11 · 6 min read

AI Vulnerability Discovery and Remediation

Free lessonReviewed By the AISecurityInterviews editorial team
Reading position
In this lesson

TL;DR: An AI vulnerability-discovery system is a loop: rank code likely to hold bugs, hypothesise a specific flaw, confirm it with an oracle that does not depend on the model's opinion, criticise and deduplicate, then hand evidence to a human. Remediation adds a patch and a validation ladder: the trigger no longer works, tests pass, fuzzing around the fix is clean, and a reviewer confirms the root cause is fixed rather than one input blocked. Discovery now works at scale (Anthropic's Project Glasswing partners reported more than 10,000 high or critical findings by June 2026), so the hard problems are validation, disclosure and patching. Results are strongest where an oracle exists (memory safety under sanitizers) and weakest where correctness depends on intended policy (authorisation and business logic).

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

  1. 1An AI tool reports a vulnerability with a confident, detailed explanation but no input that triggers it. How much should you trust it?

What changed between 2024 and 2026

For decades, automated bug finding meant static analysis (pattern and data-flow rules) and fuzzing (random or coverage-guided inputs). Both are mechanical: static analysers do not understand intent, and fuzzers do not read code. Language models added the missing piece, reading code the way a researcher does and forming specific hypotheses, while the older tools became the way to check those hypotheses.

The public milestones, all vendor- or organiser-reported (checked November 2026):

WhenSystemWhat happened
2024Google Big Sleep (Project Zero and DeepMind)First real-world bug found by variant analysis from a previously fixed bug, in SQLite
August 2025DARPA AI Cyber Challenge finalsCompeting systems found 54 of 63 planted vulnerabilities and patched 43
October 2025Google DeepMind CodeMenderPatching agent with fuzzing, differential testing and a critique agent; patches reviewed by humans before upstreaming
October 2025OpenAI Aardvark (later Codex Security)Threat model, commit scanning, sandboxed validation, patches for human review
April 2026Anthropic Claude Mythos Preview and Project GlasswingGated access for defenders; thousands of high-severity findings
May 2026Microsoft MDASHOver 100 agents: scan, validate by debate, deduplicate, prove with triggering inputs
July and September 2026Google Gemini 3.5 and 3.8 Flash CyberCyber-tuned models for vetted partners, paired with CodeMender

The most capable systems were released only to vetted organisations, because the same capability helps attackers.

The discovery loop

FIG · AI VULNERABILITY DISCOVERY LOOP
Cheap hypotheses, expensive proof

Most of the engineering is in throwing away wrong guesses before a person reads them.

Rank

commits, parsers, scores

Hypothesise

a specific flaw

Confirm

oracle on a concrete input

Criticise + dedupe

reachability, root cause

Human triage

severity, disclosure

Oracles by bug class

Memory safety

  • AddressSanitizer reports an exact fault on an exact input

Injection

  • A proof of concept in a sandboxed app shows the effect

Authorisation and logic

  • Only a bug relative to intended policy

Ranking. Repositories are too large to read fully, so systems start where bugs cluster: recent changes, input parsers and decoders, and files a model scores as risky. Variant analysis starts from a known fixed bug and looks for siblings.

Hypothesis. The model reads the code and states something checkable: "this length field is trusted before the copy", "this handler reads an object by ID without checking the owner".

Confirmation. The system tries to demonstrate the claim in an isolated environment with compilers, debuggers and fuzzers. The oracle is the design decision that matters most. AddressSanitizer turns a memory-safety bug into an unambiguous report on a specific input. A sandboxed proof of concept can show an injection or a request forgery. For authorisation, the oracle needs a statement of intended policy ("users may only read their own invoices") and a test that shows it violated.

Criticism and deduplication. Separate agents re-check candidates (Microsoft's MDASH uses debating agents to argue reachability and exploitability), and many inputs collapse to one root cause.

Triage. People judge severity by reachability (can untrusted input reach the path in real deployments?) and impact, then coordinate disclosure.

The remediation ladder

A patch is a code change that should remove the root cause without changing intended behaviour. Each rung of validation catches failures the rung below misses.

FIG · PATCH VALIDATION LADDER
Silence is not a fix
  1. 1

    1 · Human root-cause review

    class fixed, not one input

    • Sibling call sites, invariants, semantics

    Final gate before merge or upstream

  2. 2

    2 · Fuzzing and differential tests

    around the fix

    • Mutations of the trigger
    • Behaviour compared with the original

    Catches narrow fixes and behaviour changes

  3. 3

    3 · Full test suite

    functional behaviour

    • Unit and integration tests

    Catches regressions

  4. 4

    4 · Trigger re-run

    PoC or crashing input

    • The demonstrated bug no longer fires

    Catches non-fixes

  5. 5

    5 · Scanner quiet

    same rule

    • The alert no longer appears

    Weakest: rewording can silence a rule

Typical wrong patches block the specific input from the proof of concept, add an escape at the wrong layer, catch and discard the error that revealed the bug, or change behaviour callers rely on. A March 2026 study (PVBench) found that over 40 percent of AI patches judged correct by basic tests failed stronger proof-of-concept testing, which is why the upper rungs exist. Vendors converge on human approval: Google reviews CodeMender patches before upstreaming, and Anthropic requires a human to approve every Claude Security patch.

Worked example: a week of machine-generated reports

A maintainer of an open-source C image library receives 140 reports from an AI system in one week. Triage by evidence:

reports = 140
with_reproducible_input = 38
reproduced_in_our_sandbox = 31
root_causes = 9
high_severity = 3  # out-of-bounds writes in the main decoder

precision_of_reports = reproduced_in_our_sandbox / reports
inputs_per_root_cause = reproduced_in_our_sandbox / root_causes
print(round(precision_of_reports, 2))  # => 0.22
print(round(inputs_per_root_cause, 1))  # => 3.4

Only 22 percent of reports reproduced, and those 31 crashing inputs came from nine root causes, three of them serious. The maintainer fixes nine bugs, keeps all 31 inputs as regression tests, and asks the sender for batched, reproducible reports with proposed patches validated against the project's tests. These figures are a hypothetical example; real programmes report the same pattern: the expensive work is reproduction, deduplication and severity judgement, which is why the curl project ended its bug bounty in January 2026, citing the burden of low-quality reports.

Running these systems on your own code

  • Isolation. The agent and its build tools run in a sandbox with read access to the repositories in scope, no production credentials and controlled egress.
  • Input is untrusted. Repository content (comments, test data, documentation) can carry instructions that steer the agent; its permissions must make that harmless. Anthropic's own security-review GitHub Action states it is not hardened against prompt injection.
  • Findings into process. Results go into vulnerability management with owners and deadlines; third-party findings go through coordinated disclosure.
  • Measure. Precision on your code, root causes per week, time to fix, patch reverts, and findings fixed before release.

Misconceptions interviewers listen for

"The model found it, so it is real." Only an oracle makes it real. Confident write-ups without a reproducible trigger are hypotheses.

"The scanner is quiet, so the patch works." A rule can be silenced without fixing the bug. Re-run the trigger, the tests and fuzzing, and review the root cause.

"These tools will find logic bugs as easily as memory bugs." Logic and authorisation bugs need a specification of intended behaviour to check against; results there are much weaker.

"Discovery at scale means software is getting safer." Only when findings are verified, disclosed and fixed. In 2026 most findings from large programmes were still unpatched at the time of reporting.

"Gated access means attackers cannot use this." Gating raises cost and buys time; open models trail but improve. Defenders should use the capability first on their own code.

How this shows up in interviews

Expect "how do AI bug-finding agents work", "how would you triage 140 AI-generated reports", "how would you evaluate an auto-remediation tool", "why are cyber-capable models gated", and "what should a security programme change now that exploits are cheaper". Strong answers put the oracle at the centre, separate discovery from validation, date product claims and keep humans approving fixes.

Say it in 30 seconds: "These systems rank code, have a model propose a specific bug, and confirm it with an oracle such as a sanitizer crash or a sandboxed proof of concept, then deduplicate and hand evidence to people. Patches need a validation ladder: the trigger stops, tests pass, fuzzing is clean and a human confirms the root cause, because a quiet scanner proves nothing. They are strongest on memory safety and weakest on authorisation logic, and in 2026 the bottleneck moved from finding bugs to verifying, disclosing and fixing them."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

  1. 1What is an oracle in AI vulnerability discovery, and why does it matter?

  2. 2Why are authorisation bugs harder for these systems to confirm than buffer overflows?

  3. 3List the rungs of a patch validation ladder from weakest to strongest.

  4. 4A maintainer receives 140 AI-generated reports. What is the first triage filter?

  5. 5Why were the most capable 2026 cyber models released through vetted-access programmes?

Practise it as an interviewer asks it

Course lessons that teach this

Related lessons