How I Use AI To Open New Paths In Vulnerability Research

I see a lot of people using AI in security work now. That part is not surprising. What stands out more is the gap between using AI and using it effectively.

The difference usually comes down to direction.

If I ask a model to “find vulnerabilities,” I might get useful leads. I might also get paths that look interesting but are not reachable, assumptions that are not true, or recommendations that need a lot more context before they mean anything.

That does not make the recommendations useless. It means they are starting points.

AI can open doors I might not have checked on my own. It can read fast, summarize patterns, compare code paths, suggest overlooked angles, and help turn a vague concern into a smaller question. It can also be wrong in ways that sound convincing, so I still have to own the judgment.

For vulnerability research, the useful pattern is not “ask once and trust the answer.” The useful pattern is:

1. Start with a narrow surface area.
2. Give it the source context and what I already know.
3. Ask for paths, controls, and assumptions.
4. Turn the best assumption into a small, safe check.
5. Validate the evidence myself.
6. Record what was confirmed, rejected, or still unknown.

That sounds slower than the marketing version of AI, but it is faster in practice because it turns recommendations into a research loop.

Start Narrow

Broad prompts create broad output. That can be useful for brainstorming, but it also creates triage work.

If I am reviewing a feature, I usually get more value when the model is focused on a specific path. I want it to help me answer a question, not just throw every possible category at the wall. For example:

Trace how this untrusted field reaches sensitive operations.
Return the call chain, the controls in between, and the assumptions that must hold for this to be safe.
Do not make a finding yet.

That last sentence matters. Early in the process, I do not want a final finding. I want a map.

The map should tell me where the input starts, where it goes, what transforms it, what validates it, and what decision point matters. If the model cannot explain the path, I am not ready to trust its conclusion.

Ask For Controls, Not Just Risk

I still want AI to recommend what can go wrong. That is one of the useful parts. I just get better results when I pair that with what is supposed to go right.

I like asking questions like:

List the controls between input and sink.
Separate schema checks, authorization checks, normalization, allowlists, and implicit assumptions.
Call out any field that appears to bypass those controls.

That kind of prompt changes the shape of the answer. Instead of only getting a list of possible bugs, I get something closer to review notes.

The most interesting issue is often not “this feature is dangerous.” It is usually more specific. One entry point validates a field and another does not. One helper escapes output and a neighboring path skips it. One object is checked for ownership and a related object is assumed to be safe.

AI can help find those inconsistencies because it is good at comparing patterns across files. Those recommendations can be genuinely useful. I still need to verify the comparison because similar code is not always equivalent code.

Treat Output As A Hypothesis

The most useful mental shift is simple: AI recommendations are hypotheses, not evidence.

If the model says a path is exploitable, I translate that into a question:

What evidence would prove this path is reachable and security-relevant?
Give me the next smallest safe check.
Separate confirmed evidence from speculation.

That keeps the work grounded. A good next step should be small enough that I can understand the result. If the check fails, I should know whether the hypothesis was wrong, the path was blocked, or the observation was inconclusive.

This is where AI can save time. It can help reason through failed assumptions. It can suggest why a result did not match what I expected. It can remind me to check a neighboring path. Sometimes that neighboring path is the one that matters. But the final call still belongs to the human doing the work.

Validation Is The Work

I do not consider something real because a model described it well. I consider it real when the evidence is clear enough that I can explain it without the model.

My threshold is pretty straightforward:

• Can I explain the path from input to impact?
• Can I identify the control that failed or was missing?
• Can I reproduce the behavior in an authorized environment?
• Can I separate confirmed impact from speculation?
• Can I describe a fix that matches the root cause?

If I cannot do those things, I am not done. I might have an interesting lead, but I do not have a finding.

This is also where AI-assisted security work can get ahead of itself. The model can make the write-up look polished before the research is finished. That matters because polished language can hide weak evidence.

I try to avoid asking for a final write-up too early. Instead, I ask for state:

Summarize what is confirmed, what is rejected, and what remains unknown.
Do not upgrade uncertainty into certainty.

That keeps the notes honest.

Use AI To Keep State Clean

One underrated use of AI is not only finding the bug. It is keeping the research organized while I move.

After a few rounds, I might have code notes, assumptions, failed checks, and partial evidence spread across a session. That is exactly where models can help:

Turn these notes into a research log.
Group them by confirmed facts, rejected assumptions, open questions, and next safe checks.

That is valuable because vulnerability research is easy to lose in the weeds. A clean research log makes it easier to pause, hand off, or decide that a path is not worth continuing.

It also helps prevent a common failure mode: chasing the exciting version of the bug instead of documenting the real one. Sometimes the confirmed issue is smaller than the original theory. That is fine. A smaller real finding is better than a bigger imagined one.

The Part AI Does Not Own

AI does not own scope. It does not own authorization. It does not own impact. It does not own whether a test is appropriate. It does not own the decision to escalate.

That is the human part of the work.

Used well, AI can make vulnerability research faster and broader. It can help me read more code, compare more paths, notice angles I might have missed, and turn vague ideas into testable questions. Used poorly, it can still make weak evidence look better than it is.

The difference is leadership.

I do ask AI to recommend vulnerability paths. I just do it with context, direction, and a validation loop. Lead the research, let AI open more doors, and validate the evidence before calling anything real.

That is the same idea behind my earlier notes on AI-assisted validation and the longer Offensive Security With AI playbook. The tool can accelerate the loop, but it does not replace the judgment.